 Okay folks, let's get started today, Thursday, 13th, okay so as promised new assignment, assignment 3, you're gonna be breaking some crypto. This is up now, the grade scope stuff will all be there at 2 p.m. so you can get all the stuff you need at 2 p.m. Essentially to break it down before you start looking into it, the goal is there'll be four different parts, basically four different cypers. You'll each have your own cyber tech, so you go to grade scope, you'll just submit literally anything, it doesn't matter what, and it will give you your cyber tech to use for that part. You figure it out, break the key, and then submit the key in a README along with any code that you use to help you break that, and then it will be able to get feedback right away. I'm gonna go over it very briefly now because the PAs are gonna do virtual representation on Friday, so they'll cover it much more in depth, and it is up, it will be up at 2 for you to read. But the basic idea is the first one is a Caesar Cypher, it's the same thing that we saw in class, so practice breaking a Caesar Cypher, A through Z all caps. The second test is a Vision Air Cypher, same thing, A through Z all caps just like we talked about in class, and then we, so these are kind of warm-up problems to help you get used to solving these. I have links to automated solvers here, so you can double check your work and know that you're making progress, but the skills that you're developing here are gonna help you a lot on the next ones. So parts three and four are essentially Caesar Cypher and Vision Air Cypher with a twist. Now instead of shifts, we have XORs with bytes, so our alphabet is not A through Z, it's zero to 255 represented as ASCII values. So there's code here for Python, C, and Java of the different implementations of these so that you can read through it to understand how it works. You're free to use these functions in your code when you're testing it, whatever you want to do is good. The one trick, and the TAs we'll talk about this more tomorrow, is, so okay, let's think about this. So we have one Cypher is the alphabet is zero to 255. In the ASCII alphabet, one of those characters are printable. I don't know, the important example is the specifics are not important. It was slightly a trick question. The important is that not all of them, so it's not 255. They're not all printable characters. If we look at the ASCII table, we can see in hexadecimal, which is always a nice one to look at, you can see there's zero. So zero is a null byte. There's tabs. I think basically everything above 7F is also not, so there's a ton of non-printable characters there. There's a lot of these characters here less than 20 are not printable. So it's hard for the website to communicate to you what the Cypher text is if it's in all this gobbledygook that you can't see it. So what we use is we use an encoding. So we're going to use base64 encoding. This is a, basically it looks kind of like this, white space isn't important, and all of the examples have functions in their specific languages of how to base64 decode something. So you get a base64 string on the website, you put it in your program, you base64 decode it, and now you have the Cypher text like that you can copy. Again, the TAs are going to go over this in more detail. They have experience with this, so they'll definitely be able to help you out. So yeah, the basic goal is do everything that we talk about in class and use the techniques to break the Cypher questions. Well, you know where to find this, Office Hours, Piazza. Now to symmetric key crypto. Alright. So what were we talking about on Tuesday? So what was important about this box? Two keys. What did they recommend the two keys? Yeah, we're in this example. So how did the two keys work? Yeah, one only turns the key to the right and one only turns the key to the left. What we made them doesn't quite matter here, but if we are able to create keys with this properties, we talked about it. We saw that we can get really awesome things that people can leave me a message in my box and I know that it hasn't been tampered with. You can also verify that a message is from me. And okay, cool. So we will see. Okay. So we're going to get into different properties here. So we're going to go through them and talk about them. We're going to see how you can get confidentiality and non-repudiation, which are great properties. But we have a key requirement here. So it's this fundamentally different than symmetric crypto where we had the exact same key that both parties needed to know. So for this, even this box scheme to work, if you have my public key, what should you not be able to do? And generate or figure out my private key, right? Because I give the public key to literally everyone in the name of public or the secret key is kept with the user. So it's kept secret. I don't give it to anyone. So that means if all of you have it, it should not be possible to derive the secret key from the public key. The other assumption we're going to make and we'll talk about how what this actually affects real systems is we're going to assume that everyone does everyone's public key, including our attackers. We're going to introduce Eve, our adversary, our eavesdropper. So everyone including Eve knows the public keys of Alice and Bob, but does not know their secret keys. Let's start using some notation. We have public key of Alice, secret key of Alice, public key of Bob, secret key of Bob. And then we have Eve over here and Eve could have her own public key of Eve and public key and secret key of Eve. What else of this does? So think about it from different people's perspectives. So from Eve's perspective, what does she know? Alice and Bob's public keys and her own public key and her own secret key, right? So similarly, you can go through the same steps with Alice. Alice knows Bob's public key, her own public key, her secret key, and maybe Eve's public key. Okay. So we're going to use these just like functions. So we're going to just say, okay, well, we'll go into a little bit more details about how this operation is actually done. But for now, we can just say, well, if we pass a message, if we encrypt a message with Alice's public key, then that gives us some ciphertext C. Think about this in terms of a black box. We're not going to worry about the details too much right now. So think about this as a black box. So we encrypt. So now, how do I decrypt this message? Yeah, the private key. So this is like the lock system. So we can lock it one way. Now the message is now locked. And the only way to go backwards is with the secret key. So if I decrypt the ciphertext of Alice's with Alice's secret key, I will get the message. Alright, so we've done encryption. But what is this? So let's think about what does now Alice know about this message? And that also we know that it's the original message that somebody sent. So we know it's here. We know it hasn't been tampered with. So that's one of the properties we're going to want from these algorithms. Just like we live with a metric system. If somebody tampered with that message, we'll look at integrity, but we don't know who knows the contents of that message C as it's being sent. What else does Alice know? Or doesn't know? Yeah, Alice doesn't know who sent it. Yeah, Alice has no idea who sent it. Why? Because everyone has access to a public key. Right. So in this example, the people who have Alice's public key are Bob, Eve, and effectively everyone on the planet. Everyone has that public key. Alice has no way of knowing who sent that key. Okay, so we have a couple different scenarios. So this is like, I don't know, message comes in. Oh, no, not sorry. So this is just an encrypted message C. Okay, so we got encrypt. So we have our basically our encrypt and our decrypt operations. But these keys work in the same way. So just like a on our mock example left and right have no real difference, besides their different directions, because we could take Alice could take her secret key and encrypt some message to get some ciphertext. And now what key can decrypt that message? Republic key. And so then who can do that? Anyone? Okay, so let's say Bob does this, right? So Alice sends this C to Bob. And Bob decrypted with her public key. What does Bob know about that message? Actually came from Alice, because the only person who could have encrypted that is the person who has Alice's secret key. But does Bob know if anyone else read this message? Is there any confidentiality guarantee there? Alice puts this second text C, let's say on our web page or on Twitter or something. Who could read the message? Everybody had access to the ciphertext. Yes. Only Alice can see the message. Why? Once it's encrypted, you need the secret key to unencrypted. I've worn this. So we've encrypted with Alice's secret key. So what do we need to decrypt it? And who has Alice's public key? Everyone. Everyone. Which means anyone can read that message. Right? So it's not a. So there is no confidentiality guarantees here, right? Here in the previous example, by using Alice's public key, we've got confidentiality. And here we basically have non-repudiation because everyone can cryptographically verify yes, Alice sent this message. This message came from Alice. Everyone can check. Everyone knows that. But also everyone knows the contents of this message. There's no security here. Which is great, right? So we got some cool security properties. And we so now we just saw the case where Bob can send a message to Alice with and without ever using a shared key. Right? So Bob can securely send a message to Alice. Nobody else can read the contents of that message except for Alice. Without rearranging a secret key beforehand. The only requirements are everyone just has to know everyone's public key. But what about combining them two? Would we want to do that? Why was that usual? Bob can encrypt with Alice's public key. Only Alice would know why not why why not how to keep everything a secret from the public. But I'm gonna do that in the first case, right? So in this first case, confidentiality, Bob can encrypt a message only for Alice with Alice's public key. I can give that message to everyone on earth and nobody can keep that message unless they have Alice's secret key. Yes, we don't have where the message came from, right? We actually have no idea that this message came from Bob. It could be Eve pretending to be Bob, because Eve has Alice's public key. So Eve could just as easily do this operation, generate some cyber text and send it to Alice and pretend that it was from Bob, right? So there's yeah, would you combine box secret key with Alice's public key? Yeah, so let's think about that. Okay, so now we need Bob. So now we want to Bob send M to Alice confidential and I'm trying to think of the right term and known standard we'll think for now. There's an easier term, but we haven't introduced that concept yet. So we want so basically, we want Bob to send a message to him to Alice that nobody else can read and that Alice will know is from Bob. So what do we think? We have our message M. So we want to be confidential. So maybe we encrypt it with Alice's public key. That will give us confidentiality. And then we can use maybe Bob's secret key on that. Get some cyber text C. Is that actually right? I was trying to do the opposite. Okay, yeah, let's go to this. Okay, this is good. Okay, anyone to know it's from? So let's think through this. Okay. So let's go to this scenario. Alice, Bob sends this message C, the cyber text to Alice. What can Alice do to peel off this last layer? Bob's public key C to get, let's say, I don't know, we'll call it alpha or something. And then how does Alice get this message? Her secret key. So Alice's secret key takes alpha and out pops M. But does this mean that this message came from Bob? If M pops out? Okay, think about this. So your Eve. So Eve, the adversary can do, let's say, doesn't know secret keys, but basically do anything else, right, seal messages in transit, modify messages, right? Let's say Eve gets a hold of C. What can Eve do? Use Bob's public key. So use the public key of Bob with C to get what? Alpha. And then so we what you can't open up alpha, right? There's no he doesn't have access to the secret key of alpha. There's no way to open up that message and alter the message. But what if I take alpha and I have my own secret key of Eve alpha, which gives me, let's say C prime, I send C prime to Alice, right? I send this to Alice C prime. Alice thinks it's from me. In our scheme, what does Alice do to verify that? The public key of Eve C prime, which gives beta, we didn't give it a name yet. Let's go with beta. And then the secret key of Alice, she can get beta to get M. So what's the problem here? Or is this a problem? But I'm telling, I'm telling, like, maybe the message as you owe me a million dollars, right? So I'm able to take, in this case, Eve can take that message, take away Bob's secret key, apply her own secret key on top of that, tell Alice actually and block the original message, and say, actually, that this message comes from me, like intercept messages and communication between two Yeah, so I can be in between them, I can alter their messages, or I can alter the messages, the content of the message, but I can maybe trick it that it comes from me. Yeah. Okay. So as long as Alice has to apply Bob's public key and her secret key, she knows that the message has it in the template. As long as she has to apply both and out pops the correct, some weight about it. Yes, you need to apply both or we're trying to combine both confidentiality and nonrepudiation. So which means we need both either of those keys, or she applies both of those keys, it's a weird pop sound, but nothing weird didn't pop out and popped out in both cases. So how does, how does Alice know if message n came from Bob or from each, they're both telling her they're sending her this message. But who does it actually come from? The exact same message? The issue because they started with using the public key of Alice so that anyone could have made the message in the first place. Right. So the, the very last thing we did to the original message what Bob did was use the secret key of Bob. But the problem is anyone can take off that layer. And alter what's inside of it, right? If you think about it like onions or layers, right? So the secret key of Bob, anyone can open that if they have Bob's public key, which everyone does. So we swap the two operations. So now Bob wants to send a message, we have the secret key of Bob first, the secret key of Bob, we put the message. And we'll continue with our use our Greek letters, they're gonna mean something different in this example. But that's fine. It's gonna be something alpha. And then we encrypt it with what? Alice's private key. We don't have Alice's private key. Public key. Yeah. And we get C. Right. So our previous example, we can say we basically did this. So now if we think about it in terms of those layers and like an onion that we're talking about, who can peel off this last layer? Or let's see what key will be able to peel off that last layer? Alice's secret key and who's the only person that's not that secret key. So now same thing. Let's walk through our same thing. So Bob says to Alice from Bob. And Alice is like, well, anyone could claim their their Bob. So let's see if you're actually legit. So Alice takes C. What does she do to it? Yeah, private key. So the or let's do secret key because if you use public and private, they're both P's, which doesn't match up with the acronyms here, I have to watch myself to. So the secret key of Alice passes it to C. And we know up here, we get alpha. And then what does she do with alpha? Bob's public key of alpha, and gets the message M. So now, okay, but this is exactly this is the problem. We just stopped here. This is exactly if we'd stopped that in the previous example, we would have thought that it was secure, right? We need to think about what can you do in this situation. So, okay, let's go Eve steal C, the cyber text. So now what can you do this message? Nothing can't peel off the outside layer because the secret key of Alice is protecting that he does not know that you can't change it. The only thing that you can do is try to say, well, this message C is to Alice from Eve, we'll use the seek Alice will use the secret key of Alice on C to get alpha and use the public the public key of Eve with alpha and then what is this going to give us? Definitely not M, right? I don't know some, right? It'll be jibberish, garbage, whatever we maybe we can check for in our protocol in the message, whatever it doesn't matter, we'll look at that later. But fundamentally, that one doesn't be scripted. And so we know that this message is not from Eve. Cool, so you just define the whole public key. So, okay, then if we go through this. So Bob just sent a message from Alice to Bob, then how would Alice send a message back to Bob so that Bob knows that it's from Alice. So we have a new message and prime from Alice back to Bob. So what do we have to do to get the same properties? For their secret. So encrypt what with what Alice's secret? Yeah, the message with Alice's secret key. Okay, and then what and then encrypt with Bob's public. Yep, we can do that back. We get C prime, we send it to Bob, Bob can do the exact same verification as it. And now here, we have a communication channel, where everyone knows everyone's public key. We've never shared private keys, but we're able to establish a conversation and share messages with Bob, no matter if anyone can intercept or listen to our communications, we know people cannot break our communications. So is this a win from in terms of symmetric encryption? Yeah, in what way? And you don't have to meet beforehand, we can talk to each other. Think about if you had any website you visited, like the company would have to send you maybe a physical piece of mail. So you can type in your key with them to use. And that's the only way you could use that website. Right, cool. So we just did this. Nonrepudiation, we did that with a confidentiality and nonrepudiation. Awesome. Cool. The question is, how to get that? Yeah, please. So in the model of the box, would that just be a box in a box? Say it again? Oh, yes, in the month. Yeah, this is why I stopped using the box metaphor. Yeah, because for this to work, you have multiple boxes, and they each be with different people's keys, you need to like get somebody's box. So we're going to go in the box for now. That was just the this idea of these different types of keys. So some of the super interesting things of how you actually water some operations, and how can you create these two keys that are linked, right? They must be somehow linked because you can encrypt with one and decrypt with the other. But you know one you can't arrive at the other. It's kind of actually, it's almost like magic, definitely to me. So this is a super interesting paper book, maybe from 1874. Talking about this. So I'm going to read this. The same difficulty arises in many scientific processes given any two numbers we may by a simple and infallible process obtain their product. What's that talking about? Multiplying two numbers, you've been multiplying numbers your whole life, right? Probably starting in hopefully elementary school, right? Okay. But it is quite another matter when a large number is given to determine its factors, right, to go back from a large number and determine what two numbers multiply together to get that. So a basic operation like arithmetic, I mean, multiplication, it's easy to go one way, but it's difficult to go the other. Can the reader say what two numbers multiplied together will produce the number of this 8,616,460,799. I think it unlikely that anyone but myself will ever know for there are two large prime numbers, and can only be rediscovered in trying in succession a long series of prime divisors until the right one be fallen upon. This is great. The work would probably occupy a good computer for many weeks. So what is the author talking about here, a person, a person, right? Yeah, it's important to remember it's 1874. They're not talking about a computer system. They're talking about a literal human computer who used to do computation and answer questions like this by hand. The work would probably occupy a good computer for many weeks, but did not occupy me many minutes to multiply the two factors together, right? So essentially, he's saying, it took me two minutes to multiply two prime numbers together to get this number that he's showing here, but it would probably take a person two weeks in order to derive those factors. Similarly, there's no direct process for discovering whether any number is a prime or not. It is only by exhaustively trying all inferior numbers, which could be divisors, that we can show there is none. And the labor of the process would be intolerable where it not performed systematically once for all in the process known as the, I always mess this up, this is the sieve of Aristophanes. There's all being registered in tables of prime numbers. Okay, so and this is what's super interesting is taking these ideas of one operation multiplication that is very quick for one party to do and factoring a large number into its constituent factors is very difficult and takes a long time is basically the basis of at least the start of modern public key crypto systems. So we'll look at kind of different ways of thinking about and doing this. But yeah, isn't that kind of crazy? Like something in 1874 was talking about this problem, and it is the basis of modern public key cryptography. So we'll look first at the Diffie Hellman algorithm from 76. And this is a way to exchange keys where it's a little bit different than the way we thought about it. But basically, we can establish a protocol so that both of us have a shared secret at the end. And then in 1977, this is probably the most famous public key crypto system by Ron Rivest, Adi Shamir and Leonard Adelman, they created RSA. So the RSA is from each of their acronyms of that for the first letter of their last names, which was a general public crypto system. Super interesting, though. Again, we may be seeing how the gap between the public and private has narrowed. In 1970, a British cryptographer in a GCHQ had this idea of non secret implementation. And one of his colleagues actually implemented RSA in 1973. So here, actually, again, you see an example where the public is closing the gap in terms of knowledge with the classified space. So they were only four years ahead in necessarily designing these new crypto systems. Also a great example of like how concurrent discoveries can happen, because the ideas are kind of in some sense in the air, just waiting for the right people to think about them. Questions on that? Does everyone understand what we mean by like factoring a large number or any number? Right? We want to basically essentially do the reverse of that multiple occasions. So we'll get to that in a second. We'll look at Diffie Hellman first. It's pretty cool. And it's we won't go into it in depth. But again, I like to think about the thinking about the intuition behind these types of algorithms. So the idea is, okay, we're going to use paint, because this is a great one. So basically, Alice and Bob share some common starting numbers, this paint. Okay, so this would be the yellow here, and then generate their own secret colors. So Alice has been right. I will narrate. I'm sorry if your color blind, that's totally fine. So in this example, Alice and Bob's shared common paint is yellow. That is mixed with Alice has a secret color of orange, and Bob has a secret color of teal. And I'm apologizing, I'm realizing I don't actually know what all these colors are. So combine them together to get each a unique different color that is based on the shared color that they agreed on, and their own secret color. So Alice gets kind of a yellowy orange, like a light orange. And Bob gets a I don't know what somebody sky blue, maybe, baby blues. Yeah, okay. Is a periwinkle a word? Or is that more purpley? Getting off topic. Okay, so they then now generate this new color that's a combination of the other ones. And I don't know, let's make the assumption I think it's pretty, that it's difficult to separate back the paint into their constituents colors, right. So given sky blue, it would be difficult to know that you got to sky blue through yellow and teal, and not, I don't know, blue and lighter lights or something. You can think of it as many different colors that can get you the same color combination. But and so we can share now this combined color over the public network, we can assume that anyone can steal that they can't bring it apart, even if they know the yellow, that's the other thing. So somebody can see that yellow, but they can't derive what that other color was we added to it. Then the cool thing is by then adding in their secret color, they both have if we look at this process, so Alice started with yellow and orange, and added bobs, which was yellow and wait, wait, that's wrong. Okay, yeah, there we go. Okay, so Alice gets Bob's sky blue, I'm gonna go with that, which contains yellow and teal, and adds to it her secret, which is orange and gets a super ugly brown color. Right, so the same three colors are all combined and gets one final result. And then Bob gets the light orange from Alice, which is combined from yellow, the common yellow, Alice's orange, and then mixes that with his secret teal and ends up with the same ugly brown color. So and the idea is anybody looking at those interactions, the yellow and the sky blue and the light orange going across can't derive what those actually are. Yeah, the yellow actually colors are more difficult, let's say. Yeah, that's why I'm the color analogy for example, slightly, but but at least a graphical representation of what's going on that you could actually buy, you could come up with the same common secret. And so okay, let's take a look. Yeah, no, so same thing. Once the colors are mixed, you can't go back. Everyone knows the common key is the orange color from Alice and yellow. But that's the same thing as teal. So he also knows that, right, he who's sticking all this in the middle, he can tell the common color yellow, and see the light orange, because the properties of the colors that we're using can't get arrived at the orange is the secret. So yeah, the same thing as they both can derive the secret from each other. But this is not quite what we want, right? There's no real public keys, secret keys here, like we've talked about that would be very nice. But could we use this maybe? So let's say we had some scheme like this, right? So let's say the common secret we use numbers, I don't know, let's say the common secret is whatever 10, they both end up with 10 as their common secret number. Now how do they actually establish a secure communication? Just use symmetric cryptography with Yeah, we can just switch to symmetric cryptography, right? Now we have a shared secret, we've never communicated this number 10 to each other in public. But we both were able to derive it based on our own private data. And so we can use this as the key to an AES session and start talking to each other. So I can send so Alice and Bob so Alice can start sending Bob AES. Hello. Using the key 10 to Bob and nobody else will be able to break that because AES uses a 256 bit can use up to a 256 bit key and that's very, very difficult to break. So yeah, now they can use symmetric encartions, which is well, let's see this again. But yeah, so they have this shared secret questions on the concepts here. Yeah. Why would they want to switch to symmetric afterwards? Is there some benefit they get from this? In this example, there's nothing else they can do. So in Dizzy Hellman, you only end up with a shared common secret, but there's no keys like we talked about. It would be like, you and I, I don't really know how to, it'd be like us trying to maybe talk to each other in riddles or something. So we both kind of know what we're talking about. And then we write down a cypher based on that key that we're all thinking of. But nobody else who's listening can derive what that key is based on our conversation. So it's similar here at the end, you're just left with a common secret that nobody knows. But I there's no public key that I can use to encrypt this or decrypt this. So that's why. So Dizzy Hellman was first, but RSA was more general, you actually get public private keys that you can use to encrypt things. More questions? Yeah. So it becomes symmetric so they can decrypt it like it's what you're saying here. So that they can even have a communication. So this is one way of getting around the key problem of symmetric key cryptography where you need to share a secret key. And the question that we always brought up was well, how do you share that secret key? But here in this case, we can run this Dizzy Hellman algorithm, both derive the same secret key, and nobody else who's listening to our communication can derive that same key. More questions? Anybody in the back? And I really like this diagram. It's one of my favorites. Okay, and then you could go through the exact details of the algorithm. They're not super important. We can walk through them a little bit. So they agree to some values P and G. Alice and Bob both create a secret. In this case, Alice is four, Bob's is three. Then the sending is Alice will send Bob, what is this a nine. So nine to the four. So raising the G to whatever her secret is, mod 23, which is P to get six. Bob sends Alice, let's say Alice B, whatever Bob sends Alice B. So raises nine to the third mod 23 16. And then they both compute with that value. Alice computes 16 to the fourth. So 16 is what she gets from Bob to the fourth raises it to her secret. Mod 23 is nine. And Bob computes S with BS with what with what he gets from Alice, which is six six to the third mod 23 is nine. So they both end up with nine properties of exponentiation and modular group theory on all this kind of stuff. So I don't expect you to know exactly why this works. I know I want you to know the intuition behind what's attempting to be going on here and what the end result of all this computation is. Cool. Okay, but then RSA is going to be built on exactly that idea that was essentially present in that paper of prime numbers. So just like, what's his name, I should figure out his name. Just like will or maybe called Bill. Just like Bill did, you choose two distinct prime numbers, so different numbers, P and Q, you're going to then multiply them together. Simple operation and computers can do that pretty quickly. And the idea is, and this is what everything is based on, is if we have N, we it is difficult to break it apart into P and Q. Agreed? Don't agree? And we can maybe look at this later, we're talking huge numbers, like very long digit numbers that influences our operations. But when we do this, we can do this very easily, we can multiply N times Q or P times Q. And then so for our encryption operation, so we also have this notion that if we have some A that's between zero and N, so any value that's less than N, and we have some E that's greater than zero, if we raise A to the E mod N, gets us some cybertext C. So we can, we can take any number A, raise it to a power, mod that with N, that's a very easy operation. There's nothing difficult there. It's just multiplication and mod. Now the goal is given if we have C, E and N, it's difficult to calculate A or that's, so now we have the C that we've calculated, we have E, we have N. And it's gonna be difficult to go backwards to calculate A. So we are going to then compute another value M. So we have N, which is multiplying the two of them together. We're gonna have M, which is each of those values minus one, so the prime values P and Q, minus one, multiplied together. And then we're gonna pick another E that's less than one and M, we will compute a value D, that's E to the negative one mod M. So essentially, man, I don't want to get into all these details. Okay, yeah, yeah, we're basically there. So essentially, we do a lot of easy math in terms of key generation. There are some tricks here like, so even if we go back to what Bill said in his letter, how did he say you had to detect if a number is prime? Anyone remember? Yeah, why? Yeah, because it's only divisible by itself in one. So you need that in his mind, you need to check all of the previous primes essentially to see if it's divisible by any of those. And only if it's not, then it's a prime number. And to get more and more, so if he was talking about tables, so it's really nice to have tables, it turns out there's crazy other algorithms where you can get assurance that a number is prime so it can be, you can be like 99.999% sure that a number is prime without generating and having to do a lot of work. So really, that's kind of the difficult part. Everything else is easy. We end up with our public and our secret keys. And then now we have this way to turn a message into an integer. So we're limited here in this scene by sending messages that are less than n. So our Bob Bob's n, which was Yeah, so Bob, the n is p times q. That makes sense. Okay, right. So this makes sense. So let's break this down a little bit. Okay, so we give people the public key, we give people n. Everyone knows n. Right by the basis of what we're doing is on you can't fact it is very difficult to factor in if it was possible to factor in this entire scene breaks down because somebody could write q and then they break the whole system. So we turn our message into an integer that's less than n. And Alice does m. So it takes the message, lowercase m turns into an integer. You can do this kind of power you want mods that with n, raise that to the d power, which is given. So that's Bob's the mod n sends C. And Bob can take C raised it to the E, which is part of his secret parameter that he never gives anyone mod n. And that actually gives the message. So even with, yeah, with the ciphertext, the public key of Bob and the public key of alpha, essentially, because this E value gives you everything you need in order to decrypt the messages. So anyways, this is just a brief overview of this encryption algorithm. If you're interested, you should definitely check that out more. I believe we have an undergrad crypto class. Yeah, okay, so there's an undergrad crypto class. If you want to get into this stuff, you should do that. So, okay, from this, we get really nice things. So we can send numbers less than n. But how do we actually turn this into a real crypto system? So we want to send a message like Hello. Yeah, what if we just applied encryption to each letter? So we turn to each letter into its ASCII value equivalent, all of those will definitely be less than n. We can do that commutation, send a bunch of these images over, and Bob can decrypt it. What does that look like? We don't have to go through all the details. But let's say we have the message he ll o. Right. And so we have some RSA. Well, we can think we have our public key of Bob. So Alice is trying to message send a message to Bob. Let's say Justin crypt it for Bob doesn't care about non repudiation. So our public key basically can take in an integer and returns an integer. So what we could do here is public key of Bob. We did this before. Does everybody remember? I have this up six, six, seven, six, six. I can't. Okay, fine. It doesn't matter if I'm going to encrypt it into something gibberish, or something random. Let's say that the crypts of 10 or encrypts of 10 takes public key of Bob, zero x 62, encrypts that into zero x 54, PB, zero x, maybe 68, zero x F one. What's the next one going to be F one? Why? Yeah, exact same letter. I'm running out of 70. Okay. So when I send all these letters, all these numbers to Alice, Alice or to Bob, Bob decrypts them, comes backwards gets the message. What's the problem here? We've seen this problem before. Pattern. Yeah, it was a pattern, right? The pattern of the letters still remains even my second text. Right? We want encryption that and this was the key problem we saw with ECB, right, electronic code books that if you may not be able to tell exactly what that letter is. But you definitely know that it's the same letter repeated, right, which can tell you information about the text, and you definitely want to avoid that. So we can't do that. We need some way to turn this whole string represented as an integer. So maybe one thing we could do is say, okay, well, I have all the values here. Why don't I just encrypt zero x 6762686870. And I'll get some value back. I send that they decrypt it. Great. Is that gonna work? It'll work. What's the problem? It could end up being too big. It could end up being too big. We're limited by n. So we're limited by the n which was p times q, the, oh, that's not a q, right, by these prime numbers that we derived. If we, you know, set pretty large prime, you know, we're still limited here by the size of messages we have to send. So, okay, maybe we've been, well, then we have to break the message up, but still then we can't protect all the message of the public key. We end up with a whole lot of a pain. What do we do? Are we just stuck? Yeah. So what if you pair every letter with a random letter, and then Bob can just ignore the second letter? Okay, I think you may be able to do that. But then in that case, you're still Yeah, you're doubling up your bandwidth. And your message is twice as big as before. Which is tough. That's a tough sell. I think that actually would get rid of this problem. That's interesting. What's a fixed size thing that maybe we can encrypt that would allow us to then encrypt however much we want it, maybe. What was that? That's a metric key. Yeah, we use the same technique as before. Right. So we can generate basically a random AES key. And then we send Bob. So we have the message. We take the message, we encrypt, take the message, I'm going to call this lowercase k. That's insane to rewrite. So we run AES on the message. Get k. Get C. Now do I send? But I can't send Bob k in the clear, right? That's the problem we're trying to get around. But I can encrypt with Bob's public key k to get, I'm going to call it CK. So then I send both of them. I send C and CK to Bob. Now, how does Bob decrypt this? So let's think about it. First, if Eve steals any of these things, can Eve decrypt C? Why not? She doesn't have the k. She doesn't have the key, the key k, right? This is the what's protecting this, right? It's encrypted with k. Can she get k? So we have CK. Can Eve decrypt that? Who's the only person that can decrypt CK? Bob's secret key. Right. So then when Bob gets this, he says, oh, okay, great, CK, let me decrypt that with my secret key. And that gives me K. And then he can take AES, put C in with k, and get the message down. So now we can use and it turns out so the other really nice thing here is that exponentiation, especially with very, very large numbers is very slow on modern hardware systems. Whereas AES, something like AES, which was XORs and SWACs and these kind of things is very, very fast. So most modern crypto systems want to limit the amount of public key cryptography they're doing because it's, and it's very slow based on the size of the data because you're taking the data, you're exponentiating it, it's a very slow process. So this is how basically modern systems work to do that. Let's see. Yeah, okay. So yeah, we can use RSA to transmit an AES key. And this will be sending a message. We also now have a nice session as that was with Bob. So if Bob can send us messages, AES matches the back keys and we can send him messages back. We know that only the two of us know that key. Well, questions here. Hand almost up. You might as well put it up. Could you also use Diffie Helman to exchange the keys and then use AES? Yes. Should we do that instead? I don't know that it is necessarily faster. I think it's a good question. I don't know the ultimate answer there. But I know, let's see, there's also more modern public key crypto systems that are based on elliptic curves, which are the public and private keys are smaller. How many days can you faster? So those are used more than RSA, but Diffie Helman is very infrequently used, let's say. I know it's I think it's used in very specific cases, but I don't know all of them off the top of my head. Okay, but we actually encountered a problem earlier. So going back to this example, where Eve tried to mess with a message, or let's think of a different situation. So, well, all right, yeah, this situation. How does Alice know that this is garbage, and this is the original message? Readability maybe one, but what if I'm sending you a, I don't know. It's not trivially noticeable as what if it's a zip file, so zip file by itself is not readable necessarily. It has some structure. Maybe it's reading from a sensor that is inherently noisy and random looking. Yeah, we need something to validate it, right? And specifically, so what security property is that that we want? integrity, right? We want some way to verify the integrity of this message. Has this message been altered in transit to us, right? Or that's one of the ways we've thought about integrity has somebody mess with this message. Another way of thinking about it is, has anybody, what was the original message that Bob wanted to send? How can we verify that this is actually the message Bob wanted to send? And that nobody's mess with it? Yeah, so this is kind of the scenario here is what if an attacker flips a bit, right? Or, or if the bit is corrupted and the message doesn't get sent. How do we know that the message is actually garbage versus what we wanted the message to be? So to do that, we got to talk about some super interesting functions. So the idea here is we're going to be talking about now cryptographic hash functions. There's several different types of hash functions that will tire out what may send specifically good for cryptographic applications. But you should basically, so the idea is a hash function is essentially a function that maps that takes in as much data as you can give it. So arbitrary size data, and outputs a fixed size bit string. Cool. Let's think about what we want from this. Okay, we have hash functions. Let's call our hash function H. We'll try to think about what properties we want from H. So we have a message m that we want to send that we want to maybe calculate some hash on. So we basically want the property of if I and let's not worry, we're only focused on integrity right now. So let's not worry about confidentiality or anything like that. So how does Alice send to Bob a message m and a way for Bob to verify the integrity of that message that it didn't get corrupted along the way. So we're going to think about the hash. So in some sense, we want Bob to be able to check if m has been tampered with. So let's go to the real scenario. Okay. Okay, so let's say I don't. Okay, this is a let's say, okay, since we've been doing this, let's derive what we actually want to have happen. And then we'll look at this function. This makes more sense. Okay. So I have my message, I have my hash function, I can run the hash function on the message. It let's say tells me what we know in some sense the message has been tampered with or not. So I have this information, I want to send it from Alice to Bob. If it's confidential, what do I do? I don't care that he knows it came for me. Public key, public key of Bob. And I'll pass. I'm just gonna put commas. So message. Well, go with this. So I have C and public key of Bob, the hash of the message. And I will get the cryptographic hash. Bob gets these C and CH. So what does Bob do? We can decrypt the message, the secret key of Bob with the ciphertext returns. And question mark, we don't know, right? Maybe it's been altered, maybe the message got altered, maybe C got altered in transit, we don't really know. So Bob can also take the secret key of Bob and the hash of m. We'll see this is not actually necessary, but to get the hash of m. So we'll call this m hat because we're unsure. We'll care on on the m. So now how can Bob check if m hat is the same as what Bob originally sent? Run it through our hash function, m hat. And we want to check, does this equal the hash of m that we got here? If it does, and h is a good function, the cryptographic hash function, Bob can be secure in the fact that this was the actual message that Bob wanted to send. But what properties do we want? Why don't like, so I talked about some things like fixed output size. Yeah. On the last example for the part where you used Bob's secret key on the secret key on c sub h. Yes. Good, you're good. Thank you. Yeah, great. He's getting ahead of myself. So what if m is huge? Like 100 gigabytes. I mean, c is roughly 100 gigabytes. What about ch? Do we want that also to be 100 gigabytes? No, it kind of beats the purpose, right? We have to send a hash of a message that is the size of the message itself. We've failed in some sense, right? So we want it to be small. So, okay, so we're going to say, well, h of m, okay, fixed size output. What else do we want about our hash function? So we all say one, it needs to be deterministic, right? Given the exact same input, it needs to produce the exact same output. Right? Is that right? No, I think that's wrong. That's fine. This is a good thing with bad handwriting. Okay, cool. Okay, so we got this. So we have a fixed size output. So again, a small change in the input should produce a fairly large change in the output. Yeah, so let's think about that. Okay, so another thing that Alice may want to do, right? So we, actually now we have enough, maybe understanding here to understand this motivation. So we have, so Alice has a message m. Alice is going to, let's say, predict that our Alice wants to send a message. She wants non-repudiation. She wants everyone to know that it comes from Alice, but the message is huge. Tens of gigabytes, right? Maybe it's her research data or whatever, but she wants everyone to know that that data is from her. And we actually saw if we encrypt that with, if Alice takes her secret key, encrypts this very large message. She'll get some cipher text c that everyone else can decrypt with their public key, with Alice's public key to verify that it's hers, to get that message, but it's very large. It's a very slow operation and Alice actually doesn't want everyone else to have to decrypt this message. It's just a public message, but she wants everyone to know that it came from her. So Alice is just going to release m, but how does anyone know that nobody's tampered with m? What was that? They don't, right? Because somebody could have altered m or actually maybe the best example of this is like software packages, right? So you're installing software, just a giant blob that came from a server somewhere else that you don't know. How do you know that the author of that software actually intended it and that nobody else's is altering that along the way? Release the hash of it. Yeah, so one thing is I can release the hash of m. So Alice releases the hash of m and m. So now public m hash of m. So I can get both of those. I can compute m. I can compute the hash of m, make sure that hash that I compute matches what's actually there. But now Eve goes in, hacks into this server, creates m prime and then calculates the hash of m prime and tricks everybody and says, hey, this is actually Alice's data, even though I've changed it a mess with it. If Alice doesn't want to do public key crypto on her message, what if she encrypted this with her secret key, the hash, right? And this is a small value. So we can think maybe 512 bytes bits. We'll look at it on 64 bits, 128 bits, 256 bits, whatever. So fast operation, get, no, not ck. We'll go ch. Now we have out there in the world, Alice has published m and ch. So now you want to check, did anybody alter this message? What do you do? You download m, we'll call it mHack because we don't know what it is. So we get mHack, we get ch. What do we calculate? Yeah, let's say the hash of mHack and we want to check, does this equal the, I put key there, sorry about that. But with Alice's public key, ch. And now if that checks out, I know nobody has altered that message, right? So Eve can hack in, Eve can change this to m prime and leave ch alone, in which case this check should fail, right? We want it to be the case that if that message is altered that it won't be the case that they match. What if Eve puts in m prime and ch prime, which is something from her. So she calculates the secret key of Eve, h of m prime is equal to ch prime. It'll fail to decrypt with Alice's. Yeah, it'll fail to match. And we actually don't care that it fails to decrypt. There's actually a great property here. We don't care that it gives us gibberish, we just know that it's not going to match. When we decrypt that, that is not going to match our calculation of the hash. Because we would use Alice's public key to decrypt something that was encrypted with Eve's secret key. So we would never get those hashes to match. Okay, so now we're starting to develop some properties. So deterministic, we want to say, and we went with this earlier, right? Somebody, I can't remember who said, we'll kind of talk about this a little informally. So we want it to be the case that h of m is not equal h of m prime, right? So if you make a change to m, the hashes should be different. Can we actually guarantee that that's the case? Why not? Huh? Yeah, well, yeah, and the reason why is we said there's a fixed size output. So if you only have 32 bits, but you accept arbitrary large inputs, there will be at least, well, right, there's only two to the 32 inputs that would be different bit combinations. And at some point you will need to have multiple ones. There is the case that you'll have different m's that match to the same thing. So this is other properties we want. So there's another couple more properties we want, some of which are things that it's, well, we talked about like a small change in an input bit. So it shouldn't be the case that we change one bit and the hash changes by one bit. Because then maybe an attacker can use that to seal our input to understand and break the algorithm. And fundamentally, we want it to be also easy to compute and difficult to go backwards. So we'll talk about what those mean. And, oh, there we go. We just did this. That's great. Did the hash. Cool. Okay, then we'll look at more hash functions on Tuesday.