 And so that's how you solve part two of the homework assignment. They're laughing, so it's very, very easy. Okay. Cool. So we will go back to modern cryptography. So we looked at ECB. So what was the core idea behind ECB? Why do we need this? Why can't we just use DES or ADS or whatever encryption algorithm? Yeah, so the core idea what we have is we can take a key. We have this basically in black box where we can take a key. We put in data. We get out cipher text. We actually didn't talk about some of the other properties we want from this black box DES. So what are some things that we want? I think we talked about we shouldn't be able to brute force the key or derive the key directly from the cipher text. What else? Yeah. We shouldn't be able to know what the clear text is given this cipher text. We shouldn't be able to, wait a second. So we shouldn't be able to take the cipher text and go back to the data, the clear text. So it's a one way without the key. What else? Yesterday there was a penguin example where even though the cipher text is not really related to the clear text, there's still a pattern that's apparent because of how it was encrypted. So the way to think about this is think about it through the different types of adversaries. So let's say we have an adversary, a chosen plain text attacker. So they can choose their plain text and get the cipher text. So in that case, what's their goal? Have a plain text and a cipher text. The key. The key. To get the key. Right? So one of the properties there that would be nice to have, and this will come up again a bit later, is, and this is again not being able to go back from the cipher text to the data. So what if I change one byte in? So what if I do AAAAA as cipher text or as data and then I get that encryption? And what if I do, actually I don't know if this is one byte off. We'll say it's one or one bit off. We'll do BAAAAA and then encrypt that. What if the cipher text is only like one bit difference? Not good. It's probably bad, right? Why would it be bad? Because it, or it could be easy to go from cipher text to plain text. If you know that if I change this bit in the data, this bit in the cipher text changes, you could probably very easily go backwards. Which is actually very similar to what we have in like the Caesar cipher or the Visionaire cipher. So you want a one bit change in the data to produce basically a completely random cipher text. That was just something we didn't talk about. But going into these block modes, the core problem is we have 64 bits of data. We often want to apply our encryption algorithms on multiple chunks of data. And so the most natural way to do this is to just split up the input into blocks and then run each of those blocks through DES with K. What's another? So what are some benefits of this approach? Can we talk about that? I don't like some. Yeah? It's easy. Easy? Easy to implement, easy to describe. And what other ways is it easy? What is this computation of the last block depend on? Just the block and the key. The block and the key? What about this computation in the middle? Same thing. It's blocked and it's key? What about the first computation? It's blocked and it's key? Could you do all of these in parallel? Running them at the same time? Yes. This means you can take advantage of massive parallel computation like GPUs or even modern CPUs that can have 40 cores and you can run and can do each of those blocks in parallel. This is actually one of the major benefits here is using that. But as we saw, the problem then becomes every block, so given a specific key K, identical blocks get encrypted to identical ciphertexts. This encryption algorithm is deterministic. If the key is the same and the block is the same, the output must be the same. Otherwise we couldn't decrypt and we'd have huge problems. And this results in that awesome picture of tux, the Penguin, where you can take the raw byte, the raw RBG values of tux, you can encrypt them and you're encrypting this to send somebody this message and you want nobody else to see what you're sending. But if you just actually look at that image, you can see that every byte block has basically been transferred to this gray block because every block that's identical gets encrypted to the same ciphertext. So you can still see the patterns here at the block level rather than at the granularity of the character, of the image itself. But you can still get an idea of what the message is that's being sent. Does that make sense? Cool. So how did you fix this? Yeah. Or what's the key? Sorry, yes? Every block is a different key. Okay, you could make a different key for every block. How long, what size of key do you need then? Would you need a key the same size as the data? Possibly. If we make the same... Sorry, before thinking about solutions, let's talk about what's the core problem here? That the ciphertext maps to the same thing, or sorry, that the blocks map to the same ciphertext. Every block maps to the same ciphertext, right? And actually the nice part that we got with parallelism is actually the downfall here because all of these things can be computed in parallel which means none of these blocks actually depend on each other. Cool. Okay, so now solution. What do you think? We make it depend on the previous computation in some way so that way the ciphertext isn't exactly the same. Right, so we can make it depend on the previous... So one idea would be instead of 1k, let's use nk's where nk is the number of blocks we have. The problem there is the kind of nice thing about this is the security of this depends on our key. So now we need n keys that we have to somehow securely transmit to them. And at this point we're transmitting them n times 56 bits of information securely when we're trying to communicate to them n times 64 bits of information securely. So at that point we've kind of already done that. Any other ideas? Yeah. Just speed the ciphertext. So we could maybe mix this ciphertext in with the key. We could also... Another idea would be to mix the ciphertext in with the block. So you... And actually this is exactly the other style of mode which is cipherblock chaining mode. So the idea is... Oh, it looks like my xor is messed up. So you take the first block, you encrypt it with the key k. You get some new ciphertext. You then xor that ciphertext with the next block. Encrypt that to get some ciphertext too. So now what if this block and this block are the same? It'll be different. These ciphertexts will be different, right? And if you have the ciphertext, can you go backwards? What can't you go backwards of here? It seems silly because you have all the ciphertexts. So how come you can't derive the... You're xorring the block with the ciphertext, so how come you can't go backwards? Because you don't have the key? You don't have the key. Yeah, exactly. So you think of this as like a one-way trap door. You can go through it, but you can't go... Without the key you can't go backwards through it. You can't derive this input. And what is this input? Is this input the block? No. The ciphertext. It's the xor of the block with the ciphertext. And then you just do this. So this is the chaining idea. So now you have this nice property that even if the blocks are different, now the ciphertext... All the ciphertexts will be different. Except for what? The first one? The first one. Yeah, which why would that be a problem? Because if they felt they knew the key, they could check it for the first block. So if they think they know the key, they could... Well, maybe we'll go and do the reverse, but basically you have all this ciphertext. You can go backwards and do the decryption. You take the last block. You run it through DES. You xor it with the previous ciphertext to get the plaintext block. And then you just do that backwards. If you think you have the key, you can easily do that. So what does this ciphertext correlate to? The original plaintext. Specifically the original plaintext. So think about what does this ciphertext correlate to? The previous ciphertext and the plaintext. Yeah, the previous ciphertext and the plaintext. So it's kind of a mixing of both. So it's going to get randomness from this ciphertext. But this ciphertext is coming from where? Just the plaintext. Just the plaintext. So now every message, and remember one of the attackers we're kind of thinking about is a chosen plaintext attacker. So I may be able to try to figure out what your block is or what the messages are. So let's say I have some messages I've stolen from you. I think they're saying buy or sell. I could just with the chosen plaintext attack, I could encrypt buy and encrypt sell and see which ciphertext matched because the key is the same in that case. And then I could easily match those up. So you still have this problem of this first block that depends on that. So what do you do? From a concept, and if you think about it, so this one is different, why? So this one doesn't map one to one with exactly that plaintext because what happens? XOR again? Yeah, the XOR again, right? So the plaintext is XORed with the previous ciphertext. This ciphertext is different because this block was XORed with this previous ciphertext. This ciphertext is different because this block is XORed with this ciphertext. But what's there to XOR with this block? And so the idea is, well, we do want to hide what that first block is, so what if we randomly created a first block and then XORed 64 random bytes with the block and then encrypted that, and then that's that first block? So this is the concept of the idea of the injection vector. No, no, it doesn't sound like an injection vector. Initialization vector. There we go, initialization vector. That makes much more sense. Thinking portability analysis. Cool. So the idea is if this is random, then you XOR that with the block, and now what's the relation between the ciphertext and the initial plaintext? It should be no relation. It should be randomized based on that IV, right? So if you're doing the same blocks, as long as you have different injection vectors, then this ciphertext will be different. How would you initialization vector? How would you decrypt it if you didn't have that initialization vector? So how do you decrypt it? That's a great question. You have to keep both key and IV. You need the key and the IV, right? So you have the ciphertext, so you can easily decrypt, so with just the key, you can go backwards, get this block, you have this ciphertext, you get this block, and go backwards, backwards, and so you get to here, the very last block, you can't decrypt, well, you can decrypt it, but you need the initialization vector to XOR to get the original plaintext, right? So to decrypt it, you need the initialization vector and the ciphertext. So now what if somebody sees that communication, extracts, steals the initialization vector and the ciphertext? What can they learn? The first block, how do they do that? If they have this ciphertext, then they do what? They're not the first block, but they can determine what the first ciphertext is, but they already have it. They have everything here, right? They have all this ciphertext, they have the initialization vector. They need the key, right? They actually don't have the key. So they can't take the ciphertext block and go backwards to get this to XOR with the initialization vector to then get the original block, yeah. Wouldn't it still be vulnerable to plaintext attack? Yeah, plaintext attack. Just like it was before, that was the whole point of making the IV vector. Right, okay, so then how would that work? So, oh, wait, let me see. Ah, I see what you're saying. Could you have the IV, you have the ciphertext? Yes, it would definitely not fix that. Okay, so then the, so let's say not a chosen plaintext attacker. Let's say you collect a bunch of ciphertext and you can separate them into two groups, basically based on what they are. Then you could figure out some or buys and some or sells from a side channel or something. So with the initialization vector, you then no longer can tell that the blocks, that the first blocks are the same. And that would prevent that. Yeah, so it actually doesn't prevent the chosen plaintext attacker. Good call. Cool, so now would you, yeah, exactly. So now would you, and essentially you can think of it as you're using the same scheme, but you're creating a random block at the start. If we want to guard the initialization vector, wouldn't that also sort of be part of the key? Yes. Because we also need to decrypt. Exactly, so if you need, if you, if this whole scheme relied on the keeping the initialization vector secret, then essentially it's part of the key, which we don't want to do because, and we don't need to do it, right, because for any other important thing is this initialization vector is random for every message. And that would mean we can transmit the key once out of band, now we both have it, now we can decrypt messages from each other. But if we had to do that per message, send a new piece of information out of band, then it's kind of a waste. Cool. And so this then gets rid of our, oh I don't have a picture of him, but this will actually completely scramble tux so you can't see anything from it. And one of the, so from these, so what are some of the pros here we talked about? What are some of the, what are some other pros of this design? Are there any? More secure in that you're not leaking any information about the entire plain text? What else? You don't have two keys. You just have the key. The initialization vector is public or with the ciphertext. So you would send somebody over a channel where it can be stolen, the initialization vector and the ciphertext. Similar messages don't produce similar ciphertext? Exactly, similar messages don't produce similar ciphertext and similar, even similar blocks within the same plain text will not produce the same ciphertext. Right, so you're kind of, and the whole reason why it's using this and the whole idea is that, and this is why, so this should be again another theme of why cryptography is difficult because you design this box to be very secure. You design this box such that there's no way to map these outputs. So if you're giving this ciphertext you cannot find this input unless you know the key. We'll actually see if it's not 100% the case with DES, whatever, you design this super securely. But you're using this a ECB mode and you're actually leaking information about your plain text because there's this additional operation of splitting your plain text up into blocks. And how just doing that actually introduces and can undermine the security of your crypto system. So what if the initialization vector is basically public information? Yes. What security advantage does it actually offer us? I'm a little confused because it seems like if they have the initialization vector and they have the ciphertext. Yes, what can they get? They don't get the block but they still even if they just have the ciphertext versus having the initialization vector and the ciphertext. There's no difference so we assume that they can have it because in order to transmit this message we have to send the ciphertext and the initialization vector. So because we're sending this over a channel and we assume that the adversary knows both and then we can say, well the security doesn't depend on them knowing both which is fine. But it still doesn't solve the problem of the chosen plain text attacker. Correct. Yes, those we have a problem. Why wouldn't we send the IV in the same way that we send the key? So the key, we could establish a key let's say at the start of the semester and use that to send however many messages we want and we're fine. But with this we have to send an initialization vector for every message that we send to each other. Cool. Other things? When you're programming, anybody use a library when they're programming? What kind of libraries? Collections? What else? Input output? Base 64. Boost? Base 64? Requests. Requests? We request a good one. Do you go through and read the source code of every library that you use? Of course. Do you read the manual cover to cover of every library that you use? Absolutely. Absolutely. Anybody ever use a crypto library? So a lot of crypto libraries actually, and you can see clearly from here of the two for security purposes which one would you want to choose? CBC. You should almost never use ECV because it introduces these vulnerabilities unless there was some reason that you thought you had to do it, but then you have to do other ways to try to mitigate the problems there. The problem was for a long time, security libraries, if you wanted to do symmetric encryption, they would default to... I'm losing my thing. Yeah, they would default to ECV mode and then you had to set a flag on a parameter to actually switch it to CBC mode. And this actually caused a lot of problems in people using crypto libraries because they think they're doing things securely, they're not writing the crypto themselves, they're letting somebody else do it, and then the API itself is poorly designed and the defaults are very poorly designed such that everyone uses the default parameters, and if you write it and it works to encrypt and decrypt things, why are you going to dig in and figure out exactly which flag you should set to put it in which mode? Or maybe you're reading it and you don't know the difference. What's that? Unless you took a class like this or did your own research, how would you know the difference between electronic code book and cypher block chaining? Anyways, this is my mini rant using programmer usability of APIs and libraries and how they can lead to security vulnerabilities. Okay, so one of the problems with DES as we kind of saw, the key size is actually too small and this seems kind of crazy, 56 bits, but computers, and this was again created in 76, computers are insanely fast, very, very, very fast. I don't know. So the key size for this and we talked about what lengths we were willing to kind of risk. So when we talked about, let's say, if you think back to like 1976 and you said, okay, I want a key size that's going to keep my data safe for whatever, a year or two years or something. And you did that computation in 1976 or let's say five years or even 10 years. What are you basing those numbers on? The what? The speed of the current computers and how fast they can compute DES. What are you not keeping into account? The future. The future, how fast computers can get in the future. And I don't, somebody can look up when Moore's law was first stated. Does anybody know Moore's law? Does anybody know the real Moore's law? I'm not the incorrect interpretation of it. So what's Moore's law that you've heard? 75? Yeah. Right about then? Okay, cool. What is it? That transistors will like be smaller or not, they'll be able to have like double the transistors in the same amount of space. Yeah, so it used to be for every 18 months I think. So the colloquial thing of this was every 18 months CPU speed would double. Right, and this is an exponential growth which is very fast. Right, so. And so if you don't keep that into mind when you're developing something like this and saying like how fast CPUs are going to get in the future they could reach the point where now people can brute force this or what if I just buy a million computers and have them all running in parallel brute forcing a key. Right, that could be something I could do if I was a government agency maybe with enough money. So hey guys, the real Moore's law is that for the same, like the density of transistors really doubles every 18 months. Or did, I mean. Anyways, now it's super complicated, yeah. For the DS key size. Does that mean, like what would the so like when it eventually became obsolete about how long would it take to brute force the keys? That is a great question. I don't know that up top of my head. I bet now, especially with like a GPU and stuff you could brute force it pretty quickly. I think, let's see. I mean I'm definitely with a desktop or laptop you can brute force a 32 bit value. I think 64 bit is also within the realm of possibility but I'm not 100% sure. So that would be something to look into. Oh, cool. Well, here we go. So the other thing, wow. So yeah, it seems like a really big number, right? What is this? 72 million, billion, trillion. Quadrillion? Is that actually true? Did you just make that up? No, it's true. Okay. We'll take your word for it for now. So in 1998 the EFF the Electronic Freedom Frontier so they built, I believe, a hardware based DES cracker for about $250,000 and they broke a key in two days. That's a pretty good number point. And then it's been getting more and more easier to break DES. So now this group, I believe in Germany built this machine in 2009. They used 120 FPGAs so for only $10,000 was able to break DES. And so this idea, this one I mentioned earlier is that in the 1980s public researchers discovered this idea of differential cryptanalysis and basically a way in statistics to understand what bits, I believe, of the key affect what bits in the cipher text from the plain text. And so if it's not fully distributed you can break things this way. And this is what I mentioned earlier that our initial version of DES was vulnerable to differential cryptanalysis but the NSA actually helped them tweak it so it was withdrawn as a standard and so then what do you do? So this initial version was just prepared by IBM submitted for standardization so it's clear that the writing is on the wall even around this time and even before you get to the point where you can build a machine that cracks it in two days you can see that computers are getting so fast that it's within the realm of possibility to break a DES. No more encryption. No more encryption? You outlaw encryption? It's a whole other issue I'm going to do. You can increase the key size? You could maybe increase the key size but the algorithm is actually really tied into the key size so you have to have some way to I don't know, do that and then what if you introduce a new problem so maybe your key size is larger but you tweak DES in such a way that now it's weakened to these new types of cryptanalysis. You throw a contest. You have a contest and you say let's so this led to the introduction of the advanced encryption standard AES and the whole idea was they held a contest and they said cryptographers design your best algorithms then multiple groups propose algorithms and then they held a break basically like a breaking contest and said okay now everyone analyze these algorithms and let's see which one is the best out of all of them. So it's standardized in 2001 and so you can see it was like a five year process that involved 15 different competing designs it has an 128 bit block size so why is having a larger block size important? Maybe you can have a larger key it kind of depends on the key size maybe, yeah that would make sense like the key size needs to be roughly equivalent to the block size also you can encrypt more stuff like less operations maybe especially as these chips move so like the especially if you're doing CBC what's your limit on how like what can you do can you do this step before this step? No you have to do it sequentially right so you're actually limited bandwidth wise by the size of the block size and how fast this encryption algorithm is so you can go faster if you can ingest more at once the next thing about AES you actually get to choose a different key size from 128 bit 192 all the way up to 256 bit keys so and then of course this is again and remember this came kind of the standardization effort came from the government and the whole idea of DES was to encrypt unclassified documents so interesting thing to note here like the design and strength of all key lengths 128, 192, 256 are sufficient to protect classified information up to the secret level top secret information will require the use of either the 192 or 256 key oh and this is a super interesting thing the implementation of AES and products intended to protect national security systems and our information must be reviewed and served by Bay and SA, oh that makes sense cool so basically saying like if a government system is going to use AES to encrypt secret or top secret data they are going to review that implementation which again shows you the problems that can come up between the algorithm itself and the actual implementation cool, super interesting so Intel at a certain point extended the x86 architecture there's now an AES instruction so why is that important to do it quickly on the chip in hardware you can do a software thing or you can have the chip do the AES instruction itself in a lot less time because it can optimize it it can do things in parallel cool so we are not going to get into AES you can think of it very similar to DES it's just a different box but it still has the same fundamental property blocks of 128 key size of one of these 128, 192, 256 and use it in either ECB or CBC mode a few other ways but we won't go into those at all and again it has complicated it's all just transpositions and replacements just like we saw but I don't know very complicated it's probably a good description of it so we are going to talk about something really quickly and we are going to think about so what if I sent you you stole a message from me it said it actually doesn't matter and you know that this is a so if this is a Caesar cipher what can you do if you know it's a Caesar cipher brute force you try all possibilities shift it try to see if this matches up to any word what if I told you it was a visionary cipher with a key length 4 brute force it so what are you going to get so you can brute force it you can brute force a fork yeah it's pretty easy yeah so brute force it you can choose a key and make it anywhere you want you can choose a key and make it anywhere you want so I can make it say Adam I can make it say I'm running out of four letter words you can make it your favorite four letter word whatever you want it to say and why the question is why why can you make it any possible word you want let's go back the key size is the same as the message so every single letter the key size is the same as the message which means every letter independently has been shifted and there's no relationship between any of the letters movements so there's no way you can't do any there's no statistical assuming the key is relatively random or the key is random there's no correlation there and if you're brute forcing this which of the four letter words it is so we need more information about the intent of the message maybe maybe you have that fundamentally though even making all the assumptions we've already made that it's in English that it's likely a word you still can't break this key because there's a number of key possibilities is the number of not only four letter words but two letter words or three letter words and one letter words that make sense and how you know from that universe of possibilities which one it is you fundamentally won't this is why this is a fun game I should have bet you that you couldn't guess the key because whatever word you say I'll just say the key is something else you'll never win this game so this is kind of nice though so why don't I one letter message and the cork idea was so if you knew that the key length was four but there were eight characters could you do something and what about 16 but what if the number of characters in the message is eight but the key length is eight same problem right you still can't brute force that or learn what the plaintext is this seems great did we just solve cryptography why not I'm perfect though I do agree now we need a new key for every we don't have a new key for every message we send then we're vulnerable if we have an attack of that as all the psychotexts right so now if you had another if you stole another plaintext with the same four digit key and it was whatever something you could then X or shift find out what the shift between those are do something to figure out the key maybe that could give you then you'd see what shifts in here and what keys in here are four letter words are likely right so reuse of the key becomes a problem what if I want to send in a hundred character message I need to somehow communicate in a hundred character key securely securely so that nobody else can see it but if I can do that then I can actually use this and so this is a going off of those ideas is the idea behind a one-time pad where the idea is if you can use a key that's the same length as your message you can actually use a vision air cipher or just the X or cipher that we're using and you have a hundred percent provably secure communication message for as long as you have that key but yeah exactly then you have this problem where well you have to tell the message and you have to make sure you never reuse that same key what other things do you have to do in order to do this correctly so you have the initial problem of man if I have to if I have to use a key that's the same size of the message why don't I just send them the message over that same channel that I'm transmitting the key what are some other things this could be nice though there should be a pattern with the keys the key needs to be completely random it can't have a pattern it can't just be Q W E R T Y that'd be bad but what if I was able to give you a gigabyte of a key and then I could just send you messages using that key so I can send you up to a gigabyte of data but at that point we need to start over and I need to give you a new key cool so it seems like this is like a easy just academic scheme because this is something that academics love it's provably secure you can prove the security here of this communication thing so is this never used it's just completely in the realm of yeah so it's actually used a lot in all types of military and spy intelligence gathering operations and then they would actually do like code books like entire books of literal just random characters and so then they would make two copies of this they'd send one out and that way they could communicate securely but yeah it's a huge pain right so you'd only use this for the utmost and then of course then if somebody steals that code book or that key book you're hosed right so you have to make sure that remains secret and that's difficult does that have a question for the previous slide is it possible to have a key larger than the 4x size you have the 128 and 4x size you have the 128 and the 22 no so for AES you have to I mean you have to follow these parameters because that's the only thing it's been studied under so for AES you'd have to use a 128 bit block size but you can use a 256 bit key I don't know how it works internally to do that you'd have to look that up but it does work anyway so one-time pads super cool actually used but a huge pain to effectively implement so what are some of the main drawbacks of the crypto systems that we've seen yeah the same key why is that a problem that seems awesome you know a way to securely transmit that key so can you conduct so think about you want to go buy something from a company on the internet how does that happen like what are the mechanics there can you exchange a key so using symmetric encryption you've never been to this place before you have your laptop it's transmitting over some hops to them any of those routers on any of those hops can see your transmission if you're on a public wi-fi that doesn't have a password anybody can see the transmissions that you're making they type in your credit card number it's going to send that credit card information or even worse it would send a key across and then they would use that to encrypt communication with you but if you're sending the key across on that same channel that you're talking to them what's the point right so symmetric cryptography really can only be used if you can establish a relationship with somebody and transmit a key in out of band manner but there's often a lot of times where we want to talk to somebody securely usually on computers over the internet but we've never talked to them before there's no way for us to establish a key with them and it really becomes kind of a chicken and egg thing as we've just been keep going back to because in order to securely communicate you have to transfer a key securely if you can transfer a key securely why can't you just communicate securely that way and so this is the main problem luckily math comes to the rescue a development of what we're going to call and talk about asymmetric cryptosystems or a different thing so the idea is and this is kind of an insane idea when you think about it because it makes sense intuitively the idea of keys makes a lot of sense because we have locks, we have doors you have the key, you can get into the door and the idea was and this is what people and cryptographers mathematicians, computer scientists were struggling with is how can you encrypt information without requiring a secure shared secret key it seems crazy, it seems like I don't know, it seems impossible it's crazy, I still part of why I like teaching this it's crazy that any of this actually works and they're actually able to do this and the whole idea is essentially at a high level thinking about rather than having one key that's essentially the master key you, every party basically has two different keys a public key and a private key so Alice and Bob have public keys and Alice and Bob have secret keys as the name implies who should you tell about your public key? everyone, the public who should you tell about your secret key? no one, absolutely no one only you should know about the secret key what about Bob? should Bob know Alice's secret key? no, very different than symmetric crypto you had to share a key with them but here everyone has their own secret keys and their own public keys and another way and actually the main way, I like the term symmetric crypto systems and that will be clear in a second it contrasts with the symmetric crypto systems but a public key crypto or public key cryptography is the main way of discussing this so the whole idea is we're going to start with an exercise not that kind of exercise okay it's going to require a bit of visualization and it doesn't translate super well into there we're going to assume that we have a box we'll use this box it's a super awesome super awesome box but it has a key like you haven't seen before it's got a key so most keys are lock unlock this has three different states we'll talk about what they mean in a second achieve a little bit okay, they do have the sides are going to be locked and the top is going to be unlocked makes sense so when the lock is in the unlock position the box is open anybody can open it and the box has two things so let's say I have two keys but these are very special keys that you're not used to I have two very special keys one is a key that will only move the lock to the right does right make sense here that's going to be clockwise counterclockwise but it's only a half circle so I think we're okay with right and left does this actually work? yes okay, perfect, I've got to make sure it works with where I'm doing it in here so the right key only moves the lock to the right can the right key ever so if the lock is in the far right most locked position can I use the right key to move it to the left to unlock it no, absolutely not these are special keys cool, and my left key can only move it to the left so let's say for the sake of argument that I am going to keep my left key entirely 100% to myself none of you have access to this key but I'm going to make a copy of this right key for everyone in this room okay so let's think about this I put a secret message in this box and I put it in the unlock state and I put it in the middle of this room and then I walk away and none of you see any of this so you come in, you see Adam's special box on the table, who wrote that note I just told you, come on now maybe somebody stole the box from me it was unlocked and put it here and wrote a message and put it in there the lock is in the unlock state the box is in the unlock state there's a note in it yeah okay, let's think about this yeah, so let's go out of this so the box is in here, who wants to be the first person to walk in the room what's your name? Joe Joe walks in the room, he sees the box there so what are you thinking that you know about the box and the note contents in that box you think it's likely but it could be mine, could not be mine you don't know, you sit down who's the second person that comes in yeah, so you come in, what's your name? Josh, Josh comes in he looks at the box, he looks at Joe he looks at the note what do you think about that? yeah, who's to say he didn't take the note out and write his own note and put it back in or it could have come from me or it could have come from somebody else and the third person can do that and the last person in here has no idea of what's in this box because at any point anyone could have changed and edited that lock everyone agree with that logic? so I'll agree when this box is unlocked nobody knows what's in there okay, let's say I wanted to write a note and this is breaking down a little bit but that's okay so I want to write a note we'll go with poor Josh because he didn't know who was doing and messing with these notes so now I want to write a message that says let's say class is canceled everyone gets extra credit into the box and I want you to know that I'm the only person that wrote that that message so what do I do? so I pick the box that's in an unlock state what do I do with that box? lock it? there's nothing in the box I write the note and then what? I put the note in the box and I turn it with my key so currently the lock is in an unlock state I turn it to the left and then I put the box in the room right? so now you all get here let's say you all wait for each other you're all here in the room is there anybody that you trust? well I guess it actually doesn't matter you all have identical copies of this right key so how can you prove to yourselves and each other that I was the one who wrote that note so you know that it's because it's in the left position? the only key that could have put the lock in the left position is my key can any of your keys do that? your key only moves the box to the right so then how do you read the note? you turn the right key you turn it to a mocked and at that moment you know 100% I wrote that note or you know more technically the person who has this left key wrote that note and then you can read that message let's say one of you, I won't go with a dark example wants to the box is on the table in an unlock state you want to write me and only me a note that says one of your classmates deserves extra credit because they're super awesome and they helped you to study for the exam or whatever so you write up this note how can you do that in such a way that I know that nobody else can see that note lock it to the right lock it to the right so you take the note put it in the box you lock the box to the right but now can any of you open that box? even though you have the same key none of you can open that box because it's always in the far right position and you can't possibly turn that box anymore so when I can take that box turn it one quarter back to unlock to open it up and now I know that do I know who wrote the note? no but I know what I know it's one of you or anybody that had this and I knew it was only meant for me and I know that the only people who have seen that note well I know that nobody was able to tamper with that note let's say that because I know nobody else was able to open this box unless that but I would, well exactly that's their problem but even if somebody tampered with it I know once they put it in and locked it that nobody else was able to mess with that box or change the contents of that box cool so this is public private key cryptography that we just figured out very easily at a high level it is incredibly cold but the concepts here are fairly clear in that this left key is my private key this right key is my public key and basically I can encrypt something with my private key such that any of you can check it that it was encrypted with my private key with my public key but you can't forge something with my private key and vice versa the other, yeah if you wanted to like keep something private to yourself could you put something in there and lock it with the public key yes, if I wanted to keep something for me that only I could unlock because I have a copy of my right key I could put it in the box and move it to the right and then none of you can undo that unless me with my secret key in this example, no right we don't know that but we can examine the box as stated and the other important thing is there really any difference between this right and this left key what if I swapped it around and said I'm going to give you all my left key but my right key I'm going to keep for myself it would just switch the states it would just switch the states but fundamentally everything still remains the same right, I can still put a message in that box such that you know it actually came for me and you can put a message to me that nobody else can mess with and these are the fundamental properties so even though we're going to use this kind of terminology of public key and secret key in most almost all crypto systems they're essentially can be interchangeable which is nice because they're not special they're special in what you do with them the public key you give to everybody make sure everybody knows it and has it you always keep secrets I guess sacred if that's also your thing cool okay so this actually and actually I stole this from somebody online this analogy that I really like so you can go check out the full blog post if you feel like you want more explanations here but I think this has a really good analogy for the idea of having separate keys doing different things and that allows you to build a crypto system such that now even if I don't know you as long as you have my public key you can send me a message and I know that nobody else mess with it right from what we got we got super cool security properties we got confidentiality how do we get that so what aspects of confidentiality do we get so okay so so going back to the analogy if I put a note in there encrypt and with my secret key and I put the box in there what does that mean right so it doesn't give me confidentiality because anyone with my public key can read that message so there's actually no confidentiality gained there because my public key lets assume everybody in the entire world has a copy of my public key but what did we get confidentiality from if someone locks it with the public key then only you can open it with your private key exactly so if you wanted to send a private message to me that nobody else could read you would put it in the box, encrypt it with my public key and now even if you use the public key you cannot read that message you cannot open the box except with the private key which is the one that can open that box and read the message so we get two cool properties and hopefully you can see that if we all have public private keys and now we get to move away from the boxes it's very confusing if you have too many boxes around but if we all have public private keys if I want to send you a message I take your private key your public key encrypt a message send it to you and if you want to reply back to me you can take my public key encrypt a message and send it back to me so is there like example you just gave you kind of said like your public key and my public key so there's like two sets of public keys in that sense or is it just that everything so every entity will have a public and private key the private key they never share with anyone the public key they share with everyone exactly cool we also how do we get non-repudiation what does that mean let me refresh our memory it's been a while it's a big word you can't say you didn't send it right so for me sending a message if I so if I want to send a message to somebody or let's say everyone how can I make sure that nobody else can read it or that I can't claim that I didn't send that you can all see that I'm the one who put that in there nobody else could have possibly put a message in there right cool okay and and maybe what should be this is actually kind of a it's a weird intuitively obvious thing that has crazy ramifications but if I'm giving you all my public key what should be true about that versus my secret key they shouldn't be the same for sure definitely yeah one for the other yeah you can't derive one from the other so you shouldn't be able to take my public key and be like oh here's Adam's secret key that would be bad from the shape of the key how to make the key move the other way that would be very bad because now the fact that I'm the only one who knows that secret key is no longer true equals sq or p not equal to mp and if p equals mp do you think we should be taking steps to like find alternatives to public secret key encryption in case it is proven so a lot of things in there in general I know the like RSA style security which deal with factoring numbers is not resistant to quantum cryptography so I know in that sense they've already moved on to like types of public private key crypto that are resistant to quantum cryptography so in that sense I think we sidestep it I don't know I think my money is kind of on a p is equal to np but we can't ever calculate it really well like it's going to be some kind of thing that doesn't actually help us yes exactly like it'll have some crazy high constant or I don't know something but that's my completely uneducated guess so don't quote me on that okay so this is actually pretty easy requirements that we've derived just from talking about this in class so it should be yeah so how do you know cool so great so think about this that situation right I get to the box I see that there's a message for me how will I know there's a message for me it's locked to the right it's locked to the right which means nobody has mess with that message since it went in the box so I unlock it I look at the message how do I know who wrote that message you can put this name on the message they can put their name do you guys lie and put wrong names on things all the time I mean now you personally I don't lock where each of our keys turned it in a different direction yeah or it gets more complicated but we'll get to that in a second so you need to think and we'll see that we can actually use these two properties to build systems that allows to do that the way to think about that is if I have your key that turns your lock your public key you could get a box unlock it put your note in there put yours to the left then put that box in my box put that to the right with my public one and then I could open it up see oh this is just for me it's not been tampered with and I take your box out and I see this is your key unlock it with your public key so I know that you're the one who put that note in so yes you can get that we'll go over it again this gets a little crazy but again these are basic building blocks and it just makes us that you just have to keep in mind who has what and what does that mean so and the important thing to know is that everybody knows everybody's public key including the adversary who's trying to snoop on this conversation cool okay so we'll use this notation going forward of a message so Alice uses Bob's public key to encrypt a message to get some ciphertext Alice sends this ciphertext Bob can so okay we'll go back so then how does Bob read the message and go backwards Bob uses secret key and you can think about encryption I mean it's it's really we'll just talk about it like this I mean encryption decryption it's essentially the same thing here so Bob then uses his secret key to then transform c back into m and to see the message and so now it's worth thinking about at this point what does Bob know is true about this message it was meant for Bob does Bob know that Alice sent it does Bob know that Eve sent it no knows nothing except that at this point Bob is 100% certain that the message was meant for him and has not been tampered with since that message was created so we'll stop here and we'll continue on the public key crypto