 Good? All right, perfect. All right, folks, let's keep on going. There'll be a brief red split in homework assignments. So you'll have a new homework assignment on Thursday. It will be breaking crypto. It should be very fun going in a different direction. So, yeah, I don't know. Submit your assignment, too, if you're late, please. Yeah, I don't know. I guess I could tell stories about how six hours beforehand a hundred of people hadn't even submitted a secure house. I was a little concerning. It got much more, and I think the closer and closer it got to the deadline. But I would highly recommend in the future for future assignments and future classes, including this one, do not wait till six hours before the deadline to submit for the first time. But I don't know. I can say that until I'm blue in the face, so. You will just go on. Cool, OK. So we've been talking about more classical encryption systems, and now we're going to shift and see what modern crypto systems are like. And essentially under the hood, they're product ciphers. So what was a product cipher? Combinations of substitution and transposition ciphers. So we talked about these before. There is a long and very complicated history into symmetric encryption. We won't go into all the details. We'll try to hit some of the interesting highlights. It's also a very active area of development, so it's not like the cryptographic schemes and properties are kind of set in stone. They're evolving over time, and new cryptographic algorithms are created, particularly when old ones are seen as undiscovered to be broken. So what properties do we want from a modern symmetric encryption algorithm? Really, really hard to brute force. So you'd be more slightly like, what is really hard to do? I'm on board, but I just want more details. I worked with RSA stuff, research projects, so that's like a digit number to a 10 digit power. Yeah, so looking through maybe thinking through some of the key sizes that we looked at of brute breaking a, so do we want, let's say, brute force for a Caesar cipher? 25 keys? Is that very large? No, very easy to test, right? 10,000, what would be a good, so how long would you want maybe one machine to have to take to brute force your key? Years? How many years? Well, it was just one year, is that enough? Are there active adversaries on their types of communication that would still be worth to devote the resources to break it in one year? Like what, let's not give you an example. What was that? Google? What about Google? I know they have all your information. OK, cool, although all of your, yeah, have you ever, I already said this, right? You've checked your Google Maps app. You can go to Location History and it shows you literally every location you've been using Google Maps, right? So, in fact, if it took them a year to break that data, maybe that would be worth it if you're a high value target. Yeah? I got a capture of credit card numbers from a credit card number. Yeah, credit card numbers would, and the thing on that creation date would likely be valuable in a year, so maybe spend a long time to do that. So if it takes one machine a year, how long would it take 365 machines to brute force? A day? It could still take a year. If you have one year-long computation, you can't make it parallel. So for the keys that we're looking at and we've been looking at, if we assume that we know when we've broken the algorithm, is it a parallel algorithm that we can just distribute and say, you look at E's, what they see with that. I'll look at A through F, and you look at whatever the rest of that is, so we can split up the work into two. Or similar with the visionary cycle, we could say. I'll go A, A, A to C, C, C, D, and you'll go from there to D, D, D, D, and we can split up the key sizes into tight-year cards. So as long as we're equally searching the search base for a lot of these algorithms, I think, I won't say most of them, but I don't like making any hard and fast claims on crypto algorithms, would be the case that you could split that up and you just buy 365 machines on Amazon. And we know how much an Amazon machine costs. On AWS, EC2, now like 10 cents an hour. So for 24 hours, what's that, 250? I'm just 300 roughly, what is that, I don't know, 600, 6,000, if all my units are right or not. So somebody should check this. Right, so let's say rough out of order of $1,000, we could break some encryption algorithm that should take one machine a year to break. And then what's our target then? So is that secure enough, let's say? How secure is secure enough? Yeah, longer than the heat death of the universe. So you're talking, I don't know what exactly that number is, if somebody's in physics currently, if they can give us an estimate. But you can think of, I don't know, 100 million years. Right, it's gonna be very difficult to parallelize that enough to where it's going to actually be feasible to compute. Okay, so we want it to be that the key size is gonna be so large or configurable maybe or something that it would take a very long time to brute force. What else, what other properties do we want? I mean, that's actually an interesting question. Would it be easier to parallelize if you're talking about brute force? It's a question would be, maybe an inverse question would be, would you want to parallelize the encryption process? If I gave you 50 gigs of data, we'd have to start at the beginning and encrypt all of it until the end or could you split it up into chunks and encrypt those? Any possible, any possible requirement like that? If you want that. So I guess that's another question to talk about. So the question is, do I want, let's say I make an encryption algorithm that requires you to have a gigabyte of memory to do this encryption operation. And that means that in terms of brute forcing, you can slow down the attacker because they can't make FPGAs or something like that because it's hard to get any of your memory there so you're slowing down the attacker in some way. But now, I don't know, what kind of computing devices don't have a gigabrain? We have a watch. Our watches don't have a gigabrain, what else? Credit card processors probably don't have a gigabrain, although they could, yeah, calculators. Calculators, yeah. Your phone charger? Your phone charger, yeah, which has a lot of weird stuff in it. Or IoT devices, maybe have a smart home, like my friends in San Francisco have this Alexa thing that I was going to say Alexa turned on the lights and the lights go on, kind of weird. So they have three different lexas and they're all different things in different rooms. Sorry. Yeah, so the question would be if you made this kind of encryption system that required a massive amount of memory to either encrypt or decrypt, now you're limiting the applications where you can use encryption, right? So you're using encryption and now, well now my watch can no longer securely communicate with my phone because it can encrypt or decrypt anything. Right, so actually it's kind of unintuitive, but for a lot of these algorithms, we want them to be as fast as possible so that they use the least amount of resources so that people start using them everywhere. It's actually a big complaint against using HTTPS, so in securing websites so that the website communication was secure, people said, well, I don't want to spend all the CPU cycles on this encryption operation, I'm going to waste CPU, so, and it's going to delay, increase the latency from my client to the server and eventually what Intel did is they added support for encryption algorithms in the chip set, so now the chip itself does encryption very quickly, power efficient, everything like that. And so yeah, so we want something that's a very large key size that is fast and so we'll look at some of the algorithms here. So the, and we'll kind of, we're not going to, I don't know, I guess, I should never say never, but I probably won't have you implement one of these things, but I want you to understand how they work and how they relate to the classic cryptographic algorithms that we've used so far. So DES was one of these first encryption standards and it was proposed by IBM as a standard for encrypting sensitive or unclassified government information, or something like that. Yeah, okay, so sensitive, unclassified government information, so not something that was required for top secret information, but that was sensitive and unclassified and super interesting things. So this is 1976, right? So this is the dawn kind of of, well, way closer to the beginning of computers than we are now. So you're talking about machines that have less power than your iPhone or Google phone or whatever you have in your pocket. It's only about this is weird, so they proposed this, so they had this, they wrote up the standard. So why is a standard important for a cryptographic system or algorithm? It makes it so that other people can use it? Yeah, so it makes it so that other people can use it and implement it, and you can have, at least if nobody knows how to decrypt that information, the point is you have to have the key to decrypt it, so you want as many things as possible to support this system. So this is really weird, there were tweaks to it from the submission after consultation with the NSA. Seems kind of sketchy, right? So you're seeing the rest of that in there? Yeah, it's not that. The natural kind of response to this would be probably somebody at the NSA make the algorithm to give them essentially a backdoor, so that you can think of that there was, so you encrypt it with one key, and you can think of there's two keys that decrypt it, that same key and then the NSA's key could always decrypt that. So yeah, we'll talk about that later, we'll leave that lingering in the air. It also, okay, so looking more at the specs, it has a 64-bit data block size, so the idea is this is an algorithm that takes in 64 bits of data along with a 56-bit key. So how many possibilities are there in 56 bits for the key size? What was that? Yeah, two to the 56, what is that number roughly? Somebody? 100 trillion trillion. 100 trillion trillion? Yeah, so this would be a, so this is, again, so this is, again, you can see this is a better, gives us much more in terms of increasing our key space size than we had with necessarily a vision air cipher, right? We've increased it to two to the 56. 100 trillion trillion. Yeah, I guess we can scope that out, but I think that's not even fast enough by today's standards, and I think we'll see some breaks later. But essentially, so important thing is you can think of these crypto systems at a, essentially it's a black box. So what gets put into them is 64 bits, and this one and a 56-bit key and out comes garbled encrypted 56, 64 bits. So what are some of the issues there? Let's go draw this picture, I like drawing. Oh no, okay, just like. All right, so one way to conceptualize and to think about this is you have this VES box that does crypto stuff, and what you put in is 64 bits of data, and you put in the 56-bit key, and then out comes, so we can think of as we thought of in our model, so this is the message, this is the key, and then here we have the cipher text. So 64 bits, cipher text. What's the problem here? Trust it. All right, let's assume we'll get into how it works. We've been working into it with the algorithm, but if I want to send you the message again, well you can't, so that's interesting, so maybe you don't know which to which. What about, so I want to send you the message hello, can I encrypt that with this, but how would I do that? All right, I have the message hello, but this takes in bits, so how do I deal with that? Yeah. Yeah, just pad it. So I may need to pad it, but first I got translated to bits, so how do I do that? Yeah, right, there's ASCII values for each of these. Let's see, we can look at the ASCII table, hexadecimal. Can I put these side by side? I can, nice. Okay, so I have, I'm gonna go all lowercase here, because I can, 68. So why am I doing zero x before this? Because that is such a distance. Yeah, so it's representing it in hex, right? So these represent bits. L is 6C, C and O is 6F. Okay, do I have a 64 bit number? Or 64 bits, where? Five times eight, 40, I have 40 bits here, but I don't have 64 bits. I'm still, I still can't use this yet. What do I need to do? Yeah, I need to have some, I need to have some way to deal with the fact that I'm trying to send less than 64 bits, right? So I need, anyway, so let's at least ignore the padding problem for now, because that is actually a real difficult problem. Let's say I want to put zeroes at the start. We'll put it up zero bits, and then the rest is H-E-L-L-O. But now we have 64 bits. We generate a random 56 bit key, and then we encrypt it. We have some ciphertexts. It's great, the only thing that I can decrypt that is now the person with the key. Awesome. What if I want to send the message, hello, space, c-s-e, space, three, 65. What if I want to send this message? Can I do the same thing I had to do before? All right, I can turn it into ASCII, six-a, six-f, sorry, five, six-c, six-c, six-f, space is 20. I don't know what this is, so we'll just do three there. 20, whatever, one, two, three, four. So can I put this in my DES algorithm now? What's the problem? What's the problem? Yeah. Somebody. You have to jump in. Oh, not everyone. Yeah, it's more than 64 bits, right? So we have this building block that does encrypt it only on 64 bits, so we have some way to figure out what to do. What do we do with this message? Do we chop it up into pieces? We'll see different ways of doing this that have actually different security properties, but this is, I want you to start thinking about when we look at these cryptographic algorithms, they're essentially designed to analyze at this level of 64 bits, can I'm inputting here 64 bits, I have a 56-bit key, so it's all around this here and these other notions of, okay, how do I actually send a real message so that's much larger become interesting factors. But now let's kind of zoom in to the DES and break apart that a little bit and just see what kind of crazy stuff gets up to here. Okay, so essentially plain text comes in, so we have the very top of the 64 bits, there is the IP is the initial permutation, so that's a transposition step you can think about. And at the end, so looking at there, there's a final permutation and then the plain text, where's the key? Yeah, okay, there we go, okay. So then parts of the key come into this F function that has been encrypted with the previous step and essentially the 64 bit key comes in and the key has 16 different rounds where the bits are shifted and different parts of the key are used in different steps of this algorithm. So there's basically 16 steps of this process starting from this permutation. We'll see this F is basically a substitution cipher, each of those different Fs do different things and do different substitutions, basically swapping bits for other bits. We could actually see it's really cool, you can see this mapping, so this is a PC1 that takes the 64 bits of the key and permutes them, so that's, remember when we were drawing the transposition ciphers, so we had the original one and we drew arrows of where they would go, this is the same thing, but on 64 bits to 48 bits. Oh, the key isn't different, no, the key is 65 bits, that's wrong. And then in these other steps, you have other permutations that go on, so you can actually look at all of these things, implement all of them, then digging even further into the F function. So 48 bits of the key are taken with half of the block of the plain text. Then they're XORed, so this circle with the cross in it kind of is, this is the XOR operation, and then each of those bits is spread out and passed to a different, what they call an S box, and each of these S box stands for substitution, so it's just each of them have different substitution tables for what substitutes were, and they each have different output, and if you see it's kind of crazy, there's one, two, three, four, five, six bits in and four bits out, so you put in six bits and four bits come out, and then that is subject to another permutation where things are all mixed around. And then digging into the S boxes, you can basically use this table to look at and figure out for every S box, and this is, so the crazy thing to go into the NSA scheme. What the NSA changed is one, I think, one or two values in one of these S boxes, to kind of use as part of this algorithm, as part of this substitution, so the goal here is to show you that this is essentially very complicated, and that's why we're not gonna go into the details. But at the end of the day, it's all just transitions and substitutions, so there's nothing fancy than, from what we've previously seen, it's just different, and so let's go back. Let's go back here and let's talk a little bit before we talk about how it got broken. Let's talk about what we want from it. So we talked about properties a little bit, right? We talked about wanting it to be difficult to do for, which is good. We wanted it to be fast, which is good. Low memory, which is good. Want to be able to encrypt all the things. What are some other properties that we want to be true, and maybe from a tax that we saw on visionare and Caesar ciphers? Difficult to figure out that's a ciphertext. Let's say, no, let's say we tell people it's a ciphertext and we still want them to break it, or we assume that they know that it's a ciphertext. Maybe that's a better way of putting it. Yeah. There go patterns and frequencies. Yeah, patterns and frequencies, right? Essentially, if you think about it, the problem with all those previous algorithms was patterns, frequencies, statistics from the input data would manifest still in our ciphertext. So essentially what we, kind of what we want is essentially no relation between the message and the ciphertext, right? We want it to be, essentially, you can think of as random. We want every bit of the ciphertext to be equally likely to be flipped. Another way to say that is, what if I send, let's say the message hello, right? What if I change one bit of this message and I change this to e? So I had the original hello message. I have some ciphertext c. I encrypt this with the same key. I have some ciphertext c-prime. What should the relationship be between c and c-prime? Should they vary by one bit? No. Why? You could try and brute force messages and get there a lot quicker by knowing how quick a message is. Yeah, what was it? Or maybe that would tell me either information about the ciphertext. I could compare different messages and I could see which ones were different by one bit. It's leaking significant information from there. So what do I want to be true about, in this case, c and c-prime? C-prime is completely different from c? Yeah, completely different, right? Every bit has an equal probability of being flipped just from one thing having changed, right? So this is kind of why we're coming back here is to tie that to everything you saw with all those permutations and everything is essentially the idea being that one bit flip will diffuse throughout all of the ciphertext and change with equal probability all the resulting ciphertexts. So the attacker has no way of knowing that c1 and c are related by only one bit. Questions on this? We're talking about breaking for the fall, I guess. Mm-hmm. Ah, yes. So just like it's a similar exact same problem we have with Caesar ciphers and Vision air ciphers. So you needed to have shared the key with somebody privately first. Yeah, this is the classic. We'll get into another crypto system maybe today. We'll talk about that, yeah. Maybe, you may have to go again. If you have to break up your message, it's actually the blocks of the size of the union crypto. Let's talk about that in a bit. We'll get to that. Okay, so DES has several problems. So believe it or not, the key size is actually too small. So just doing two to the 56 or 72, what do we say, trillion and trillions? Is actually too small, which is kind of insane to think about because that's such a large number. When we think about how fast computers are and that we can do this calculation in parallel, it turns out way back in 1998, the EFF, so the Electronic Freedom Foundation. I think that sounds right. Building a custom DES cracker for roughly $250,000 that can break a key in roughly two days. Now that price has basically significantly dropped. So now in 2009, there's a company that built a machine out of 120 FPGAs, so programmable hardware machines, for about $10,000 building off the shelf components that can break a DES key in about that time. So we're breaking the price of breakage now way down. Actually, interesting, I don't know if maybe you can use a GPU for this better. And one of the really interesting things, okay, so if we go back when DES was proposed in 76, 77, then basically the field of crypto analysts advance and discover this technique called differential crypto analysts, which was discovered in the late 1980s. So roughly a decade after DES was proposed, and it turns out that the first version of DES that was submitted for standardization was vulnerable to differential crypto analysis. But after the NSA put their changes in, it was not vulnerable to differential crypto analysis. So what does that tell you about what capabilities the NSA had? Yeah, they had the ability to crack it in 1976, which the public didn't have until the late 80s. So this shows you how far ahead the NSA was in terms of crypto analysts than the general, I mean, not general public, but you're talking like smart mathematicians who were not working for the NSA. It was a super cool instance. So despite what we would think that they actually, so why, so now if we say, okay, our initial instinct was the NSA put in a backdoor there, but we have evidence here that they actually did it. They strengthened this algorithm. Why did they do that? Yeah, or it was for sensitive and unclassified, it's for sensitive, unclassified documents. So they knew the government was going to use this and they didn't want it to be trivially breakable like techniques they already had, right? So they actually had an incentive to fix it. And the other interesting thing is they fixed it in a way that nobody can actually reverse engineer and figure out why. So nobody knew why they made these changes. So they didn't release their technique of how to break it. And basically the unclassified research space had to discover these techniques before realizing that's what actually happened. So I think this is a fascinating example of, nope, not you. This is like a fascinating example of a case where the NSA fixed something based and we have documented evidence that they were basically a decade ahead of public research. Which is super cool. And then there was a new area called linear crypt analysts that, or a new technique that was created in 1993 that's even more effective. And it was basically withdrawn as a standard, it's no longer a standard now. So now to do symmetric encryption. And oh, this is getting into, okay, what we talked about. So to actually do this in practice, right? So with DES or any type of algorithm, yeah, okay, cool. We'll do this and then we'll talk about DES. So we looked at that, right? The basic algorithm, DES only encrypts with 64 bits. But we wanna be able to send messages of arbitrary sizes. We wanna be able to send as much and encrypt as much data we want with the same lick. So you're tasked with this. How do you do it? So now let's go back here. So I give you this magic DES box. It takes in 64 bits as a key. What did we say? 56, 56 bits and output 64 bits. So now you have a message M that's much larger. What do you do? Pretend you're in an interview, what do you do? Think of it. Yeah. See four bit output as the input. Okay, let's think about what's the easiest thing you could do. Yeah. 64 bit chunks. Yeah, take the message, break it up into 64 bit chunks. So abusing Python syntax a little bit. You could have the first 64 bits in one message. You could have then 64 to, what's it, 128 and so on. So split the message up into 64 bit chunks. So take the message, split it up and then pass in each of those to DES with the key and then out comes maybe like C1. So we'll call this message one, message two, message three, so on. That's input here, this is input to DES here. C2, C3 and the key goes into all of these. So it's the same key. And then you combine all of these into the cyber text. So just append them to get the cyber text. Pretty simple. So what's one of the benefits of this? Yeah, okay, so all the pieces of the message are inside one thing, so now I don't have to, well the other side's got to do the same thing, so the decrypt, they have to take the cyber text, split it up into chunks, but at least we can just send them everything, assuming they have to heave you the way to decrypt the message. It's easily parallelizable. Yeah, so you can run each of these DESs, right? They have no dependencies on each other. You can run each of them in parallel on the same machine, different machines, whatever. So you can encrypt a file, 50 gigs, if you're running five of these, you can do a five x fact. However much processing you have, you can just encrypt it super fast. And I guess the other benefit is it's pretty simple, right? It's not crazy complicated. Are there any downsides to this approach? There's only one key than a downside. Or I guess then what does that mean? What is the implication there? Decrypt the entire message if they find it different. They have more keys than- Yeah, okay, so the strength of the message, let's see the possibility of brute force is limited by the size of the key. So here is 56 bits, which is bad. But we can replace this with AES or whatever standard currently is and then we'll get whatever 256 bit key or whatever size key we want. We can do that to get rid of that. But yeah, so in some sense it's nice because we're relying on the algorithm. Yeah. Why does that matter? But I encrypted it, right? So all of this cyber attacks is all random, right? So C1, C2, C3 are essentially both random if you don't know the key. Okay, so yeah, it's kind of maybe the key argument. So the key side is I can break any of these chunks and maybe that gives me an accurate advantage. It's more, it's not as good against the statistical analysis of any particular 64 bits that were committed. Yeah, but why would that be true? Because I'm encrypting each of these as the key so it should be randomly, like essentially random. Yeah, okay, so this is the important point. So here, so what if, so in this example, what if M1 is equal to M3, right? You're sending a message. It just so happens that the first 64 bits and the last 64 bits of your message are exactly the same. What does that then say about the cyber attacks here? It's all been encrypted by the same key. Yep, which means what? Which means it's vulnerable at one point. Not quite, we're almost there. Yeah, in the back. Does this just become the E-derivatory counter to this cyber attack? Not quite. Okay, let's think about it like this, okay. So I have my, I'm gonna think like this. I have DES, I pass in M1 and key. What does that give me back? C1. C1, great. I have DES, M2, key. What does that give me? C2. C2. Now if I have DES, M3, M3 key is equal to what? If M3 is equal to M1. C1. It has to be C1, right? It can't be any other value because those two things are the same. The DES is a function. If you give it the exact same inputs, it will always give you the same outputs. So now I here have C1, C2, and C1. So now if the attacker has essentially this, so if the attacker has this cyber attack, but to C1, C2, C1, what does that tell them about the original message? Yeah, the first and the third parts are the same, which I think is where some of you were going, if you're, yeah, so you could maybe try to do visionare or something, or figure out something based on similarity here, and we'll actually see how that essentially crumbles in a second, but yeah, the key problem is, and it's likely with messages that you have, you will have repeating chunks, right? You could have a bunch of zeros that repeats, you could have all kinds of different things. Actually, let's go look at the Penguin. So this is kind of a famous picture. Oh, and so you just invented a thing called electronic code book. So this is a way to encrypt a plain text message, split it up into the block sizes, pass each one to your encryption algorithm DES with the key, get cyber text, and append it all together. So this is exactly what you just did. I don't want to do this. The problem goes in, so this is a great example of this is an original encryption of, I think it's Tux, the Linux Penguin, and this, a little bit, you have to massage this a little bit to get it to work exactly right, but if this is saved as a raw image file, so the pixels are not JPEG compressed or anything, it's all raw pixel data, when you encrypt it with ECB encryption and view it, it looks like this. So why is that? A lot of the data is the same. Yeah, a lot of the data is the same, and essentially in this case, every white pixel is essentially encrypting to something that looks like a gray pixel, but all the white pixels essentially do this, and similarly the black pixels encrypt to something that looks blackish for whatever reason. So all these pixels are getting encrypted to the same value and they're the same thing. So you can clearly see, even though we've encrypted this with, I think this is a AES encryption, we'll talk about it in a second. Even though we've encrypted this with this nice encryption algorithm, we still, these massive patterns from the plain text are showing through in our cipher text, which seems insanely counterintuitive, I don't know about for you, but for me it's kind of crazy, you're using this cryptographically secure building block that it's not due to the fact that there's a problem with necessarily DES here, the problem is how we're using that in order to send a message. So you can go check us out here, there's a good blog post that talks about this if you want to look at this, tucks more. Okay, so can we design a better algorithm then? Let's go over here. One of you mentioned something? Yeah. Yeah, so fundamentally we need some way of doing different keys for different blocks, but at the same time we don't want to have more than one key, right? So I don't want to have to share with you 10 keys because what if I send you a message that has more than 10 blocks? Or, so we need some way without actually using more keys, but we want, the key thing is we need to encrypt each of the blocks with a different key. Maybe we can change the key every time? Yeah, I'd go. Actually, maybe a thing, but let's ignore that for now. Yeah, you could use part of the previous ciphertext as a key for the next. Yeah, so we know this ciphertext is essentially random and depends on this key. Or I could maybe, if I can't use it exactly, maybe I can use it in combination with the key, like X or part of it in with the key. I think my diagram here will be my diagram. Okay, so we can do something like, so we have our message, I'm gonna say M1, M2, M3. Okay, so something's gonna happen here. We're gonna get some ciphertext C1. And, well, another thing we could do rather than messing with the key, we could actually use the same key and change the message itself. So kind of similar property. We could take the ciphertext, bring it up, X or the second message with it, then pass it to DES, which we'll now get some ciphertext two. So remember we talked about X or, especially encryption, so we can X or, if we X or M2 with C1, we'll get something. And then if we take that something, we'll call it X, and we X or ciphertext one with it, we'll get the message. If we X or the message with it, we can get the ciphertext so we can recover that back. And then we can keep doing this, so we can do this up here. So now if we have some kind of design like this, if I have, if M3 and M1 are the same, what does that tell you about the ciphertext? Yeah, okay, so let's see, M1 and M3, okay. So M1, in this current, in this design, so we have M1 with the key, we get C1, cool. We take ciphertext one, X or it with M2, pass that to DES, encrypt it with the key. So let's think about this, what if they're all the same? What if our message is just repeating A's, right? So this is basically, everything is M1. So we have M1 with the key into DES, and let's draw our little, let's do it like this. So we have DES, M1 key equals C1, right, everyone agree? Got that, cool. Now in this next one though, we have DES, we'll still use M1, so they're all M1. So but it's not M1 getting passed in a DES, what is it? M1 X or C1. Yeah, M1, I think I should probably draw it like this. Ah, no, I'm gonna use the carrot, that's easier. M1 X or with C1, okay. And so now will that give me C1? No, likely not. Likely not, I mean it's possible there's a one, where's it, one in two to the 64 chance? Wait, is it possible? No, it shouldn't be possible, because it gave me C1 and that means M1, can I actually prove this? Okay, M1 X or with C1 is equal to M1. Okay, so perfect, okay, so if, oh that's good. Okay, I wonder if it deals with that somehow. Anyways, okay, so I guess that is technically possible, but so yeah, okay, it does make sense. So there's a one in two to the 64 chance that the cybertext happens to be all zeros. But we can, let's just ignore that case for now. So we can think, okay, so DES M1 X or C1 is equal to K, so that's gonna give us some cybertext C2. And then so in the next block, now I have DES of M1 encrypt X or with C2, C2 with a key. So similar argument, this is gonna give me something like C3, so even though the every message is the same, all of the cybertext will be different because we are X oring them with the message. All right, so did we solve our original problem? Yeah, okay, let's think of a different scenario. So I have, let's say I have two messages now. So before we have one message, right, that we said was basically M1, M1, M1, and now I have a new message, I'm just gonna use M prime. So we have a new message M prime that happens to be, let's say M1, M2, M3. So we know from this message the very first block will always be, is C1, M1, okay? We'll look for M prime, so for M prime we're gonna do the DES of M prime, or no, not M prime, yeah, M1, K, which is what? C1, and then we have all the rest so we're gonna mix that in there, it's gonna be different cybertext. So if I get these two different cybertexts, what do I know about these two messages? M and M prime, let's go with this. So okay, so I encrypted this, so C, the encrypted of M is gonna be C1, C2, C3, and then actually let's go and do this, okay? So we have, so DES of M2, Exord with C1, okay? So what's this gonna be equal to? Is it gonna be C2? Or, you know, different? Yeah, so it's different, so we have M2 here whereas before we had M1, so it must be different if we're saying that M1 and M2 are not the same, and this must be this thing, it must be something like C4, and then we'll have DES of M3, Exord with C4, okay? And this will be C5, so now C prime, so my next message is going to be C1, C4, C5. So if I just have access to the psychrotex, what can I tell you about those two messages? Yeah, they start with the same characters, or they start with the same block, right? The first block of each message is the same. Why is that? Yeah, our first block is different from all the other blocks, right? Our first encryption block doesn't have anything that Exord into the first part of M1, and therefore M, it's consistent, if the M1 block and the first block is the same, and we interpret the key that psychrotex will always be the same. So we can actually solve this by essentially creating a fake random first block. So they call it an IV for initialization vector. So the idea is I generate as part of my message, so I have my message and my initialization vector, which is randomly generated. That goes in Exords with M1, passes it to DES. So now I have, in this case, so I will have not just the mess, so I'll have the message and the IV. And now here my equation changes, it's not M1, it's M1, Exord with IV, comma K, which will give me some psychrotex one, good. M1, there, everything else is good. So now my message becomes clear. So now I have my psychrotex, my initialization vector, and I have C1, C2, C3. Now I will need to generate a new initialization vector, so I need the M prime, IV prime. And the question is, what does my psychrotex look like? So now in this equation, I got M1, Exord with IV prime, comma K, and what's that gonna give me? Yeah, C6, let's re-number these, I don't like this. All right, so this will give me C6, where, so it's not going to be the same thing because the two initialization vectors are different, so it's gonna give me something different. And then now I have that in here, C6 will give me, wait, why did I do C6? I should do C4, getting in my head. So C4 will give me C5, C5 will give me C6, and now I have C prime, IV prime will give me C4, C5, C6. So absolutely no relation between those messages, right? So now I've gotten rid of that property even, and the great thing here, even if I encrypt the same message multiple times with different initialization vectors, the resulting psychrotex will always be completely different. But what did I have to give up, did that come for free? So we've increased, let's say, the security of our scheme, but did that come for free? Wouldn't you then have to communicate the initialization vector somehow? So you have to change your communication style, you have to pass the initialization vector and the psychrotex, but that's okay, that's, you know, we can figure that out, that's just protocols. Maybe it's slightly more complicated, but we're willing to do that for security here. What else do we give up? Yeah, why? Yeah, we can no longer execute each of these steps in parallel, right, at the same time as currently, because now we've created an implicit dependency on each one. So we have, yeah, we have the message, we have the initialization vector, we encrypt that, we need to XOR that, and then we need C1 before we can do the next block. And then we need C2 before we can do the third block, right? So this is something we've given up in terms of doing this, but we get nice security properties. So this is called Cypher block chaining that we just came up with, or CBC. So one is electronic code book, ECB. This is CBC Cypher block chaining. So yeah, we've basically, yeah, we've arrived at all of this, it's the same, cool. All right. So after DES, there was a strong need once it, and the cryptographic community, as we've seen kind of with the cost of, a break of DES cost $250,000 by the public sector in 98, and then in 2009 dropped to $10,000. Essentially we see that attacks against crypto systems continue to get faster and cheaper, so as soon as there's an indication that things are breaking, it's time to switch to the next algorithm. So AES is the advanced encryption standard. There was a competition that they held in order to decide which was gonna be the next standard. It was originally called Bridgendale, maybe. I don't know if anyone can pronounce that better than me. Please feel free. It was standardized in 2001. There was a five year process with 15 different competing designs, and they were all open to interpretation analysis and discussion from the community. It had now 128 bit block size, so what's the benefit of increasing the block size here? What was that? Block size? We can have a two bit key with a huge block size, but we still gotta, we would only need to break, try the different keys, right? But for two bits, we need to try four keys and we're done. Yeah, less blocks to encrypt, right? We can do, data has grown significantly, so we need to do less necessarily encryption operations. The other nice thing is you can choose different key sizes, so you can choose 128, 192, or 256 bit key sizes. And so from, I like reading this, it's pretty cool. This is from the process. So the design and strength of all key lengths of the AES algorithm are sufficient to protect classified information up to the secret level. Top secret information will require use of either the 192 or 256 key lengths. The implementation of AES and products intended to protect national security systems and or information must be reviewed and certified by the NSA prior to their acquisition and use. So this is the government's restrictions on this algorithm. So we went from an algorithm that was only useful to be used in sensitive and unclassified documents to now AES can be used in top secret documents and is, I'm fairly certain. And the other important thing that I mentioned is Intel extended the x86 architecture, so the chip will do AES encryption on the chip, saving you a lot of time. Cool, but we won't go into the design of AES, it's very similar to DES. But one thing I want to think about is, okay. I want to talk for a second about a vision air cipher. It seems simple, we've already done that. So we talked about a vision air cipher where I had the IG with the key, key, and let's say I have a message, foo. So what's this going to shift to? Can anybody do this really quickly, please? A, you can also just shout out random letters, I think that's fine too. But if you actually do it, you know. W. W, is it W? No, it can't be W, it's the same, same with a different key. There's one letter you can't say. What was it? Okay, cool. So let's say that I give you the cipher text, AWU, and I tell you the key length is three. What's the message? Any three letter message. Any three letter message, why? Don't have any restrictions for the cipher text or the key? Yeah, so the way I think about it, right, is depending on what the key is, the first letter can be any character from A to Z. The second letter can be any character from A to Z. The third character can be any character from A to Z. So you could get a bat or run out any other three letter words that are appropriate, what? Bye. Bye? Yeah, all of these are valid decryptions of this cipher text. Why? They're all real words and they're all equally likely, right? Previously, like if this was a Caesar cipher, we only had 26 possibilities, but here we have every possible combination of three letter words to choose from. So we literally have no idea which one the original message is and which one the original key is, except maybe if we had multiple messages that were encrypted with the same key, then maybe we could use that information to determine, but if we only have, and if let's say we find another three letter word, a cipher text that's encrypted with a random three letter key, we have the same problem. We have no idea what of the words the adversary was trying to send. And so I guess the question is, did I just invent a perfectly secure cryptography algorithm? Should I just quit and start a company and become a millionaire? Yes. Ooh. Sorry, just wait for him. He's on the page to block me if I quit. Okay. Yeah. It's perfectly secure only for messages of length three. Yeah, so what if the, exactly. So, okay, so now what if the key, so what if the key length is three, but the message is six or nine or 12 characters? Could you break that? Yeah. Yeah, we saw techniques to do that. The only reason this works is the key size in the exact length of the message that you're trying to send. And the key cannot be reused in multiple communications, right? You have to have a random key per communication and that key must be the exact length of the message. So when we went back to and we said, okay, so what's the, how do we share a key secretly? Take it offline and give it to them in person. Yeah, take it offline and give it them into person. But then you have to, so think about this. You have to share a key with them that's long and random enough that later on you can communicate with them, but only the length of the size of the key that you already shared with them. So on one side it's like, well, why wouldn't you just, why would you just share that message then? Could you have a secure channel for them then? But so it turns out though, what this is called is a one-time pad. So this is actually a type of encryption algorithm that requires the key to be the same size as the message. You can either use Visionair or XOR, but the trick is you can never reuse the key and this is provably secure. I mean, we just did a brief proof with Visionair Cypher with three characters. It's provably secure and possible essentially to prove for us if and only if, and this is a key, the key is truly random. So you actually need randomness and random here means every letter of the key or is equally likely. So it needs to be drawn from a uniform distribution. If there's any bias in what the key is, you can use that to break the cypher. The key is as long as the plain text and it's never reused in whole or in part and it's kept completely secret. So this is, and allegedly systems like this were used, I think even between the US and Russia. So they have the, they used to have during the Cold War like a secure, like a red phone that was a phone directed to Moscow so they could communicate. What they do is they share a book, like literally a book of code words or whatever, or keys, random keys. And they have to type in a bunch of those and that as soon as you use from that book you have to rip out that page and burn it. So it was never, the key was never disclosed and it was never reused ever again. But this is actually used if you really need high value communication but then your problem is you're limited to basically like that book. So once you run out of keys you need to exchange new keys but you can do this in very specific circumstances. Okay, this is gonna be great. So we're talking about several things. What's one of the main drawbacks of this symmetric crypto systems? It's like this crazy bootstrapping problem. Like how do you securely communicate with someone? Well first establish a secure communication with them and share a key. Like okay, but how do I get there if I need to establish a secure communication? So sure, we talked about meet in person. We also talked about all of the insane recording devices that are on us every day and everything that's trying to listen to us and record us. Meeting in secret is difficult. What if the person lives far away? How do you actually meet in person if you can't actually meet in person and securely share that information? So yeah, we have this key problem and I guess now we'll introduce the classic crypto people, Alice and Bob who want to communicate. So they're gonna try to start sending messages. We're gonna use them for our, and I mean I guess, maybe I'm theorizing a little bit, but I feel like kind of with the, this was seen as almost like an impossible problem. Like well of course you need a key. How else can you talk in a secure manner if you don't share some secret with somebody else? But it turns out there's an invention of asymmetric crypto systems where essentially we'll see that the goal is how can I encrypt information that I can share with you without requiring a secured shared key which is kind of insane. So to get there we're gonna first talk about a box. So actually this is perfect. I should actually build one of these things. Maybe one of you can do that. So okay, imagine on this table there's a box and it has a special kind of lock. That lock has three states, so A, B, and C. And it has two keys, but these keys are special keys. So normal keys, right, open door, closed door. So one key only moves, will only move the lock to the left. So if you're all the way in the right most state which is locked, it can move it to the left of unlocked and then to the left of locked. The other key is the right key. So we have two keys. And the other key is the right key. It only turns the lock to the right. So let's say that this key, the key that turns it to the left is public. I give it to all of you. You all have copies of this key on your key ring in your pocket. Maybe it's on the door of this room. I don't know. The other key is one that I keep secret to me. So it's a secret key that only I have the copy of. Let's walk through some scenarios. So you come to this room. The first person here looks in this box. The box is unlocked. You go open the box and there's a message in there. What do you know about that message? Who did it come from? Anyone, right? The box is in unlocked state. You have no idea who wrote that message, where it came from. No idea at all. Now, what if the box is in all the way to the right most state? It's all the way to the right. It's locked. You get to that box. You know it's in the right most state. Do you have a key that can move that to an unlocked state? Yes, you all have this key and it all moves you to the unlocked state. You do one turn to do an unlocked. You open it up. There's a message in there that says, if you found this, you got an A. The rest of the message I'm doing. Is this a prank from one of your fellow students? Or is it true that I actually wrote that? It has to be from me? Why? Yeah, so I'm the only person that can turn this lock. I'm the only person that has a key that turns it to the right. I'm the only person that can turn this key all the way to the right. So then you know at that point that you found the golden ticket and you don't have to do anything else. Okay. What about another scenario? I think that's gonna get too dark, but you've discovered a cheating ring in the class and you wanna tell me but only me. You don't want any of your other students to know you've read them out. So you write up a message. You make it anonymous or maybe don't put your name on it. Let's go with that. But you have a message that you only want to be for me and you want no other students to read it. How could you use this box to do that? Or can you? If it's already in the unlocked state, you just put your message in and turn it up. So if the box is already in the unlocked state, you open the box, you put your message in, you turn the key to your left. Now can anyone else with that key that turned to the left open the box? Who's the only person that can open the box? I'm the only person that can unlock this box, right? So when I get that message, I can look into it. I can unlock it, open it, read the message. Now, what do I know about this message? Yeah, do I know who put the message in there? No. But what do I know about that message? Only one person saw it and broke it. Yeah, only one person put it, from when that person put it in the box and locked it, nobody else of all of you students could have tampered with that box or that message, right? So it's a private communication from at least one person. I don't know who it is, but somebody, and I know that they put it in the box and nobody else touched it. So this is essentially the way to think about asymmetric crypto systems. So you will have a, every party will have two keys, a public key that everyone knows, and a secret key that that user keeps secret. So here we have Alice and Bob. They each have public keys of Alice and a public key of Bob, and they each have a secret key that they never share with anyone else. The other thing that this is called is public key cryptography. So if you've heard of public key crypto, the same thing as asymmetric crypto systems. And so we, and this is exactly what this scenario essentially is, and this is why this is a great example of how to, and this is where I got this from, it's great. So of how to think about this and how does it even possible, and how it's possible to get into math and different things that are being more difficult or hard to do without knowing some secret information. But the important thing is to think about and understand how we're gonna use these systems. I can't believe I'm saying this. I guess I'll let you out a minute early. We'll get into public key, like the properties of these public key crypto systems. And we'll dive in more. Very good.