Hi everyone. Thanks for being here. We're very lucky and fortunate to have my friend and ex colleague Don Matthews here to speak to you on topics of security. Don and I as I probably mentioned in a past lecture we worked together at Seagate for many years, and I knew a little bit about security before coming to work at Seagate. And one of the first projects that I worked on was to work with Don on implementing some of the ASL algorithm logic in the hardware controllers at Seagate. So, with that introduction we get Don hooked up with the microphone here and I'll turn it over to Don. So, first thing I want to go over is something that corporate lawyers like to do to people. Basically everything in this talk, everything tonight it's all my opinion, it's all my own thoughts and so on and so forth. It has nothing to do with my company and like I said. This is one of the things that happens when you get out in the work world. The lawyers are worried about everything you're going to say and do. Just so you know I work for Advanced Micro Devices for AMD. You can ask me some questions but there's a lot of stuff I cannot get into specific with AMD products and everything. And then secondly, let's make this interactive. Some of what I want to talk about tonight is how things break more than just cryptography but security in general. And oh, yes and we've got sugar cubes too. Matter fact on the way over here as I was talking to your professor about I went to a hockey game a few weeks ago, and I went through the security and they've got the metal detecting devices so on so forth until I set it off. And they said, ''Do you have a belt on?'' I showed him my belt buckle and the guy with the wand wand's over it and he says, ''Yup, it's your belt buckle.'' See, I could've had a gun on me. If I was limping I could had a machete on me. All they did was verified that my belt buckle was made of metal. He didn't verify that that was the only thing that could have set it off. So, this is actually a security failure even though it's not necessarily IoT or cryptographic security. So, ask questions, bring up things. If you know of some security failures let's talk about them. So, what algorithms do you want to use? What protocols do you want to use? Anti tamper which is, how do we stop people from tampering with devices that we've designed or make it harder? Threat models, attacks. Talk a little bit about hard drives and then some stuff with password tables. Now, most of this material on the slides, they're points for me to just jog my memory to say talk about this, okay. I'm willing to go any place you guys want to talking about security. Like I said ask questions, bring it up. So, here's a key thing and I know your professor went over AAS, RSA, Prior elliptic curve, shot to and some the hash algorithm so on and so forth. Always use standard algorithms. Standard algorithms have millions of combined hours people researching. So, as Bruce Schneier says and I know you've got a quote from him also, ''Anyone can design an algorithm that they can't break.'' One of the key things with security and we did this many a times, many a meetings, I can design something that works in my head because you all know that we've all got blind spots. Every time we design things we've got blind spots. It's the same reason you don't architect, it design it and test it because your blind spot in architecture and your blind spot in the design is also going to be a blind spot in the testing. Definitely goes with security, the more people you have looking at it the better it's going to be. So, go with the standard algorithm. The secret is actually the key, not the algorithm. If it's a good algorithm you can publish it which is what they've done with AAS, RSA, so on and so forth. And there's tons of algorithms out there, all right? Same thing with protocols SSL, so on and so forth. Bunch of protocols out there to do anything you want. More and more now everyone's using the standard ones. You've got standards bodies whether it's a nist or other government standard bodies. Use those. Those are the algorithms. They've had people look at them. Yeah, there still could be problems with them once in a while. But, it's going to be found by someone who's going to announce it, all right? Use proven code. You can implement all this stuff, its just an algorithm everyone can implement it right? Did you do it correctly? Did your verification find at all? What about some of the little bugs out there especially when we get to some of the side-channel stuff here in a minute. All right. Use code that's already out there known good. Open SSL. Why implement your own SSL? You're just asking for trouble because you've written programs, little bugs become huge security holes. Any questions?