Lecture 22: Cryptography: Encryption

• Download English-US transcript (PDF)

The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high quality educational resources for free. To make a donation or view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu.

SRINIVAS DEVADAS: All right. Good morning, everyone. So more of the same in terms of cryptography and cryptographic techniques similar to Tuesday's lecture. So if you liked it, you'll like this one. If you didn't like it, well, it's going to be more of the same, so sorry.

But what we're going to do today is do a couple of things a little bit differently. We're going to talk about encryption. So we talked about hashing, which, of course, you know about from the use of dictionaries. We haven't really talked about encryption in 046 or even in 006 previously.

But we look at two different kinds of encryption algorithms. We spend a little bit of time on symmetric key encryption, which is really something that was used in encoding machines including the enigma from World War II that you probably saw if you saw The Imitation Game. So there you have a shared secret. And it's that single, what's called, symmetric shared secret. Both parties know the secret.

And very quickly, we'll talk about what it means to actually exchange a secret. So we'll talk about key exchange. And then I'll move to asymmetric key encryption, which I alluded to a little bit when we talked about digital signatures last time. I talked about public keys and private keys.

But we're going to actually look at a couple of different public key encryption algorithms today. The classical algorithm, the very first algorithm really that stayed secure, the RSA algorithm. It stands for Rivest, Shamir, and Adleman, the initials of the three inventors, invented at MIT in 1977 and still in use today.

And the last part of today's lecture is going to be looking at hardness. So in encryption, if you don't know the secret key, it should be hard for an adversary to discover what the message corresponds to. The adversary sees what's called the cipher text, which is the encrypted text.

The adversary does not know the secret key. If he or she knows the secret key, game over. But assuming that adversary does not know the secret key, it should be computational hard to discover the message, right? That makes sense.

So there's clearly a relationship between this hardness and NP-complete problems, which are computationally hard. And it's not surprising that people have tried to build what are called cryptosystems, which are essentially cryptographic techniques, based on the hardness of NP-complete problems, including graph coloring and knapsack and so on and so forth. But it turns out there's a real subtle difference between the kinds of problems that have been useful in terms of building secure cryptosystems like RSA and NP-complete problems.

And we'll talk about that at the end of lecture. We'll probably spend a bunch of time on that. So let's get started with the symmetric key encryption, which is, at some level, kind of boring from a mathematical standpoint. So we want to spend a lot of time on it.

It's definitely very useful. It essentially assumes that there's a secret key k. And you can think of this as a 128-bit number. Some people want it to be larger, 256.

But it's suddenly at 64. At this point, it's probably not enough, even though 2 raised to 64 is still a fairly large number. With parallelism and with fast computers, it's a little worrisome that the adversary only requires 2 raised to 64 work to enumerate all possible secret keys of 64-bits right? So 122 raised to 128 is much better.

And this is shared between Alice and Bob. So we'll think about the protagonists here as being Alice and Bob. And they want to exchange information. And typically, the adversary is mal for malicious. But there's other ways you can obviously name adversaries.

So the basic equation here is really straightforward. It's C, which is the cipher text. So a little terminology here, cipher text. m is the plain text or the message.

And plain text means you can just read it. Cipher text means it's scrambled. K is, of course, the secret key that's up here. And the e is the encryption function.

Now, in symmetric key cryptography, basically the requirement is that you have to be able to get back the plain text from the cipher text given a public decryption function and knowledge of the secret key. And this should be a straightforward operation, right? So by the way, e of k m, this is a polytime computation.

It's not constant time. It's typically linear time. And you don't really want it to be quadratic time even, because you want to do this vary fast, streaming. You need to send streams of messages, many gigabytes potentially, that are all encrypted.

And this is actually what happens when you get stuff from your satellite and you're downloading movies. That's exactly what happens. It's symmetric key encryption of a lot of data.

So backwards would be dk c. And the only difference here is that everything else stays the same. This is our decryption function. All right.

So that's symmetric encryption is. And there's a requirement of reversibility here. So it's a lot different from one way hashes that we talked about last time. Because here, while you want going from c to m to be hard, it's only hard if the adversary doesn't know k.

If anybody knows k, it should be easy. In fact, that e and d are going to be virtually identical in terms of complexity and sometimes implementation. It's just you run it in reverse, and you get back what you encrypted. That's the way you want to think about it.

So really what happens is that you need reversible operations in order to build e or d, which are the encryption and the decryption functions. So permutation, for example, is reversible. You can always take something and permute it, and you can go backwards.

So you could do something like that. And the permutation, the reverse, looks like that. What is this supposed to be? It's the fact that I have 3 bits here. And they turn into 3 bits over there.

And obviously, if I reverse the permutation and if I just add a simple thing where it was abc and I'm going to convert it to cba, then cba can go back to abc through the reverse permutation. So clearly, this is a reversible operation. But there are other operations that are reversible as well.

Plus can be reversed by a negation. And exclusive OR is simply exclusive OR. Because if you do A exclusive OR B, then you get C. And imagine if you did B again to that, you get A back.

That's what I mean by reversal. Because you have, essentially, A exclusive OR A cancels out. And so it's something like a exclusive OR B exclusive OR B again would give you A.

So if you go look at AES, for example, which is the Advanced Encryption Standard, is really only about four lines of code, maybe it's eight lines of code. But this is a well used, it has been around for a while, symmetric key cipher that runs in 128-bit mode as well as 256-bit mode.

And it's, like I said, a few lines of code. And you'll see operations like this, permutations. And you'll see hat symbols if you see a C program, which is exclusive OR.

And you can see the encryption and the decryption are identical in implementation. You're just going to run it one way, and you run it again. And you get back the result. Because these permutations are reversible. And the hats are reversible.

And they're all signed integers, so you're just sort of adding them up. And it's just complement arithmetic, so that looks the same as well. So I encourage you to go take a look at AES. I'm not going to spend more time on it.

The key idea here is of symmetry and reversibility. We're going to move away from that. Clearly, we didn't talk about that when we talked about one way hash functions, et cetera. That was a different situation where we had no secrecy. But here, we wanted symmetry.

The big question that you would ask and you should ask yourself when you see this, you say, OK great. I can build symmetric key encryption algorithms. They're actually, I would say, somewhat easier to do than to build hash functions, which have a whole lot of more interesting properties and hard to obtain properties like collusion resistance. But the question really is how do Alice and Bob share the secret key, k?

So you need that. You need this 128-bit number in order for there to be a channel, a secure channel, that Alice can communicate to Bob with and vice verse. And so now you could say Alice sends Bob a letter. But you know, mal could intercept that letter.

And even worse, what wants to do is look at the letter, actually deliver the letter, which is the best thing for him, and Alice and Bob think that they have a secure channel. That's sort of best case scenario for mal, right? So you could have mal in the middle here.

And you've got to worry about stuff like that. So key exchange, let's move on to talk about key exchange. And how does the secret key k get shared? You can't put this out on a website, right? So it has to be the case, sharing is something that has to be secure in the sense that there can't be any eavesdroppers.

So here's my favorite example of a puzzle that most of you have probably heard about. But those of you who haven't, it's really pretty cool. And those of you who have, it's still pretty cool and worth recalling.

And there's actually something that you probably haven't thought about very much even if you've heard about this puzzle. That's the mathematical assumption made in the solution of this puzzle. That will be interesting to you.

But the puzzle is a pirate puzzle. So you've got Alice and Bob. Let's call it the Caribbean, because that's my favorite ocean. And Alice and Bob are in two different islands.

And we all know there are pirates in the Caribbean, right? And so Alice and Bob want to communicate with each other. And what Alice has are a bunch of boxes and locks and keys.

She's got the keys for her locks and nothing else and the same thing with Bob. So Bob has boxes, locks, keys for his locks that he can put on his boxes. And in this case, Alice wants to send a message to Bob.

And Alice wants to exchange a key with Bob, so they can eventually communicate in a secure way regardless of the pirates or whoever else is listening. So the problem here, of course, is that if you just send a message on a boat-- so the pirates are kind of nice, in a way, that they will deliver messages. But they are curious, right?

So they're very curious. And they will open up boxes. And so that's supposed to be a boat, by the way, not a box, a little mast there.

So I'm not a sailor. But you have these boxes that are going to get delivered. And the deal is this.

If there's an open box, the pirate's will open the box. And if there's any message in it, they might read it, they might throw it away. So clearly, a secret key can be exchanged by just putting a box with a message in it if you don't lock it.

They will not be able to open, they'll not touch, and they will deliver a locked box. But if they ever see a key, they'll keep it. If they ever see kind of a key on the boat, they'll just grab it and keep it. And then the next time around, they see a locked box, they'll stick the key in and try and open it.

All right. So how do Alice and Bob securely exchange a secret where security is based on this notion of piracy, I guess, with the pirates having a certain amount of capability in terms of storing keys, and opening up the locks, but they will not touch a locked box? All right. So that's the puzzle.

How many of you have heard of this puzzle before? So all of you keep quiet. Someone who hasn't heard of this puzzle before, think for a few seconds here and see if a solution occurs to you with respect to going back and forth-- so that's the hint, going back and forth-- and being able to securely exchange a message, which could be a 128-bit secret key written on a little note between Alice and Bob. Yeah? Back there.

AUDIENCE: Are they allowed to pass locks such that--

SRINIVAS DEVADAS: So if you see it locked, they'll throw away the lock, too. If the lock is on the box, then sure, they will deliver that box. But if the key is outside of that box, then they'll keep the key. No-- this is a difficult puzzle. Yeah?

AUDIENCE: Alice could lock the box and send it to Bob.

SRINIVAS DEVADAS: Yeah.

AUDIENCE: And then Bob could also lock the box.

SRINIVAS DEVADAS: Yeah. And then? At that point-- no, you're on the right track. Keep going. Just push it a little more. Couple of more boat rides and we're done. Yeah.

AUDIENCE: And then if Bob sends--

SRINIVAS DEVADAS: So there's now two locks on the box.

AUDIENCE: Yes.

SRINIVAS DEVADAS: And Bob has two locks on the box. And so what's Bob going to do next? What's the logical thing for Bob to do next?

AUDIENCE: Send it back to Alice.

SRINIVAS DEVADAS: Send it back Alice. And now the key's inside. Alice now sees two locks on the box. And one of the locks is Bobs. And other is?

AUDIENCE: Hers.

SRINIVAS DEVADAS: Is hers.

AUDIENCE: She can unlock it.

SRINIVAS DEVADAS: She can unlock the box and send it back to Bob. And all of this time, the only thing that's gone in transit is a locked box. No keys have gone into in transit, whether they're inside the box or wherever. But the only thing that's moved is a locked box.

So that's good. You're exactly right. So that gets you a Frisbee. Whoops, sorry. We need a secure exchange there. Yeah, that's good.

So that is exactly right. So just to recap, Alice locks box with KA, and that's the key for the lock, sends it to Bob. Bob locks box with KB, sends it to Alice. And Alice unlocks-- oh, I should've said that Alice puts message in box.

And that message has the secret key inside of it. Alice unlocks KA and sends box to Bob. And then Bob unlocks KB and reads message. So that's good. That's all good.

Let's look at it a little more deeply and think about it from a mathematical standpoint, not a physical standpoint. You could think about it from a physical standpoint as well. What is the relationship between this locking, this sequence, in this case a pair of locks, that we require here in order for this to physically make sense? s

I mean, there's different ways that you could add two locks to a box. There's many different ways. One way is to have a box that is locked if I look it over here.

And it doesn't open, because the lid doesn't open. I've got suitcases like that. And then there could be another spot here that looks it as well. So that could be one way. Well, what's another way of having two locks? Yeah

AUDIENCE: Putting a box within a box.

SRINIVAS DEVADAS: Yeah, putting a box within a box. That's great. So if you put a box within a box, then does this work? It doesn't work, right?

So nested locks actually don't work. Because what happened here is that KA was put first, then KB. And if, in fact, you had KA, and then KB out there, then you can't remove KA without removing KB. And this would be the case where you have nested locks.

So the mathematical operation that we require is commutativity between the locks. And the locks need to commute. I want to put KA in first. Like I described, the physical realization could simply be a suitcase with two different positions for the two locks. And any one of those positions locks the suitcase.

So you put KA here, KB here. And then you can take KA out, right? And it's still locked, because you have KB. So this commutativity between the locks and essentially the keys is what's required.

And so now, let's move away from pirates and go into the cryptography domain, pure mathematical domain, and see how this turns into what's called the Diffie-Hellman key exchange, which is a key exchange algorithm or a protocol that under certain conditions give you exactly what you see here. It gives you a secure key exchange. And there's one issue associated with it, and that'll be kind of clear once we write it out here, that we'll get back to.

But Diffie-Hellman key exchange assumes that you have commutative locks. And this is how it works. You'll see what commutes when I give you the equations associated with Diffie-Hellman key exchange. And this is also described in the '70s.

So what we're going to do is we're going to work in a finite field Fp*. And the finite field means that we're going to be doing mod p, where p is prime. And the star means we're going to be only looking at invertible elements only. So we drop the nonvertible elements.

These things aren't particularly important. And so we'll drop 0. And we'll be looking at 1, 2, to p minus 1. So all the numbers that you see are going to be 1 through p minus 1.

Now, what is the analog all this protocol that Alice and Bob, in our pirate puzzle, operated on or ran? What is the analog in the mathematical domain or in the finite field domain? Well, here's what happens.

Alice is going to select a random a. And we're going to assume the g is public. So she just shouts that out to-- Alice can see Bob from her house.

So she shouts out g and shouts out p. They're all public. She doesn't care if the pirates can hear this.

And Alice is going to select a, which is random, and compute g of a. And this is in the finite field, capital G. So you're going to do your mods. And she's just going to send over g of a over to Bob.

Now, what Bob does is select b and computes g raise to b and sends that over. So g raised to a is being sent over. g raised to b is being sent over, sent over to Alice. So Alice gets g raised to b.

And the key realization here is that Alice can compute g raised to b raised to a, because she knows a. This is all going to be mod p. And we're going to call that K. And thanks to the fact that exponentiation commutes, Bob computes g raised to a raised to b, because Bob knows b, which is also exactly K-- I should say mod p over here. Everything is mod p.

So that's it. That's Diffie-Hellman key exchange. You have now created a shared secret based on the commutativity of exponentiation. And the part that's still missing here with respect to the analogy is the fact that g of a is essentially the locked box.

So what g of a is hiding is a. Because you want a to be hidden here and the same thing with g of b. It needs to hide b. So the problem that the pirates had was they couldn't open up the box.

The problem that the adversary, let's call them mal, has is that he has to invert g of a in order to discover a. And in this particular finite field, and many such finite fields, you can think of this as being what's called a discrete logarithm problem. So if you don't know how to computer logarithms in that continuous domain. And there's tables. And it's pretty easy to do.

But this is what's called a discrete logarithm problem, because we're in a finite field. And we obviously want integers. a is an integer. So we need to discover what does that integer is. Because we're doing the mod p, et cetera, and p is typically on a large number, it's actually a hard problem computationally to do a discrete log.

So when you see g of a, you know g, you know p, but trying to figure out what produced that g of a is a difficult problem. And people have looked at this for 30, 40 years and there's not great algorithms to solve this problem, certainly not anything that's polynomial time solvable. They're all kind of subexponential. And you can make the numbers large enough such that g of a is secure in the sense that it doesn't give away what a is.

So that's the insight here that Diffie and Hellman had, which comes down to the discrete log problem is hard. And what this simply means is given g of a, the discrete log problem is compute a. And the same thing for b, of course.

There's one other thing that you want to say to be precise to sort of just cover the spectrum with respect to how this could break. And that is what's called the Diffie-Hellman problem, for want of a better names and since these are the folks who first came up with it. And the Diffie-Hellman problem is simply that given g of a and g of b, which is what the pirates see and what the adversary mal sees, we should not be able to compute g of a times b, which is exactly what we get here.

g of a raised to b is g of a times b. So given those two things, if there's a way of computing g of a times b, even though you potentially haven't discovered a and b precisely, g of a times b is just the secret key that Alice and Bob exchanged. So you're host. Alice and Bob are host if mal can do this.

So there's two things going on here. You want the Diffie-Hellman problem to be hard. And you want the discrete log problem to be hard. OK So generally, this is how cryptography works.

You set up protocols. And there's some information that's bound to be exposed. You want this information to be hard to reverse to get the crucial information. That requires the computational hardness assumption like the two that we've made here. And then you're off and running.

Your system will break if your computational hardness assumptions are incorrect. And they may be correct for a particular time, for example, the 1970s for particular parameters. But they may end up being incorrect assumptions, at least for those parameters, at a later point of time, simply because computers got faster.

It's like 2 raised to 40 was this huge number when I was your age. Now, it's like nothing. So that's basically part of the game. But the good systems are those that scale where you increase the parameter size and the system and the protocol stays the same. And so you just increase p, for example, in this case. And the discrete long problem is still hard for modern computers.

So those are the good protocols and the good cryptosystems that stand the test of time, not necessarily the ones that have exactly particular parameters. That's hard to do. Because as I said, Moore's law and computers have been getting really exponentially faster. All right.

So there's one main problem with the Diffie-Hellman protocol and the solution to our pirate puzzle. And so can someone tell me-- and it could be just for the sake of the Diffie-Hellman problem or just in the context of the Diffie-Hellman problem, but also in the context of the pirate puzzle-- what assumption are we making here that's as yet unstated with respect to this secure key exchange being actually secure? Someone. Yeah.

AUDIENCE: If I were to intercept a message from [INAUDIBLE] something of their own back?

SRINIVAS DEVADAS: What does that mean? The pirates see a locked box. So the first step of the protocol, Alice is sending a message inside a locked box with a single lock in it.

You're kind of on the right track. And what could the pirates do in order to break this protocol? We've kind of made an assumption here. And I might have said it explicitly. Yeah, go ahead.

AUDIENCE: [INAUDIBLE] throw the box away.

SRINIVAS DEVADAS: They could just throw the box away. But that doesn't break the security of the protocol. That breaks the functionality of the protocol, right? Yeah, go ahead.

AUDIENCE: Put their old lock on [INAUDIBLE].

SRINIVAS DEVADAS: Ah, that's exactly right, put their own lock on it. You know, if they had locks-- so these pirates don't have locks, right? We're making that assumption.

If they had their own lock with a key, if they just had a lock that locks and they didn't have the key for it, they will wouldn't be able to break the security of the protocol. But if they had a lock and a key for that lock, then they can pretend to have delivered this to Bob. And there's no authenticity here with respect to Alice doesn't quite know whether she's communicating with Bob or not.

She's at the mercy of the pirates to deliver these boxes. So if the pirates had a lock and the key for the lock, then we're in a situation where Alice may have exchanged the key with the pirates. And she thinks she's exchanged it with Bob. And she's, in fact, communicating with the pirates.

So there's a man in the middle attack, which corresponds to the pirates having their own locks and keys. And it's even more trivial in the case of our picture here. Because assuming the pirates know mathematics, they can generate a random number-- and the number could be c, for example-- and just send back g raised to c.

And for all you know, they could actually get Bob to send g raised to b back, but they would intercept it and replace it with g raised to c. And they know what c is. So what's happening now is so you can [INAUDIBLE]. I won't to go through all of the math here. But you can kind of see it, I hope.

You end up, if you're Alice, exchanging a secret key with the pirates as opposed to Bob. And the way you can set this up is the pirates actually will get into a situation where Alice and Bob think that they're communicating with each other in a secure fashion, but the pirates can listen to all of the messages. They can decrypt all of the messages, because they know what they secret key, k, is. OK.

And remember that the secret key, k, is something that is probably going to be used in a symmetric key encryption scheme eventually to send real messages. So you're going to have ciphered text with that secret key, capital K, over there. And if the pirates or mal get to know what the secret key, k, is through a man in the middle attack, you've got problems. All right?

So the man in the middle attack is something that we have to worry about. What we're going to talk about next is something that addresses this problem. And it may not seem like it's directly addressing the problem. But fundamentally, what's going on here is you need to have authenticity in who you're communicating with.

Alice has to somehow authenticate Bob. And Alice has to know somehow that g raised to b is something that came from Bob. It's not g raised to c that came from somebody else is in the middle. And that's where asymmetric key cryptography and public keys come in, where you have a certified public key associated with yourself.

And maybe you need VeriSign or you need the DMV, or the Registry of Motor Vehicles, RMV, to do this for you. But you create a certified public key, which is associated with your identity. And it's public. You can put it on a website.

And everyone can access it using HTTPS, so they know they're going to the exact website that you've put up. And that gives you a way of identifying yourself. And if you can do that, you can protect against the man in the middle attack using asymmetric key cryptography.

So that's kind of the final part of this puzzle that's associated with authentication and secret key exchange and all of that. Once we do that, you'll know what the functionality is that we require. And then we'll have to talk about how we can build a subsystems.

Cool. Any questions so far? How we doing? OK. So public key encryption, let me just do a little set up. I said some of this last time. But to make sure we're on the same page, what we have here is we really want a message plus a public key.

And you want to obtain ciphered text using this operation. And this plus is not arithmetic addition. It's just that we're putting these two things together into an algorithm, a public key encryption algorithm, that produces ciphered text. All right.

And this public key, just to reiterate what I just said, is going to be if Alice is producing the message and Bob is getting the ciphered text, this is going to be Bob's public key. And the fact that it's Bob's public key is something that Alice should be able to authenticate using VeriSign, using the Register of Motor Vehicles, what have you. That's what's going to protect against the man in the middle attack. OK.

We're not going to talk a lot about how you can get a certificate. Your MIT certificate is something which corresponds to your MIT ID. It's got information, what year you are, what your name is. And when you generate that certificate, you are getting a certificate of authenticity that you are you.

And of course, you give that away and you hand it to someone else, someone can pretend to be you as well. But that's what's happening when we talk about public keys and you owning public keys. We're not going to, as I said, get into that very much more. I'm more interested in describing this algorithm for public key encryption.

We'll look at a couple that produces a ciphered text given a message and a public key. Now, of course, what Bob needs to do is to take the ciphered text. And this is what Bob's doing. And Bob has a private key that is distinct from the public key and needs to get back exactly the message using a decryption algorithm that corresponds to the message that Alice sent.

OK. And this whole thing is going to work provided knowing the public key, let's call it PK, and the private key. We can't call it PK as well, obviously. So we call it SK.

Knowing the PK does not reveal anything in a mathematical sense about SK. But obviously, in order for this whole thing to work, PK and SK have to have some mathematical relationship. And the different cryptosystems including RSA, and we look at a knapsack cryptosystem, all have different algorithms for encryption and decryption. And they have different mathematical relationships between PK and SK.

And for each of these relationships, you have to show that the adversary has to solve a computationally hard problem in order to discover SK given PK. And it turns out that for most of these systems, it's symmetric in the sense that these algorithms, at least for RSA, you could use either one of these interchangeably. And there's issues associated with that. So we really won't go too deep into that.

But what I said you should hold, which is you have one, it shouldn't tell you anything about the other. There has to be a computationally hard problem associated with discovering one of these only given the one other. And we'll talk about what those hardness assumptions are certainly for RSA and also for another cryptosystem, a knapsack.

So we're going to present RSA, which is this real magical algorithm. It's amazing it works. Every time I prepare for this lecture, I got to relearn somethings. And that's because there's one subtle aspect of this.

It's all about number theory. Number theory can get pretty subtle. But it's also intricate enough that I forget the details.

So let's get started on that. Basically, RSA is based on primes and factoring numbers into primes and using number theory to make sure that you can actually accomplish what this is trying to do. The functionality of RSA should be distinct from the security of RSA. When we talk about the functionality of RSA, we are saying for any message, if Alice uses Bob's public key to encrypt it, the ciphered text resulting from that should be decryptable into exactly the message that Alice sent given Bob's private key.

That's the functional requirement of a public key encryption algorithm or a public key cryptosystem. The security requirement of a public key cryptosystem is what I wrote up there. It's the knowledge of SK should be hidden even given the knowledge of PK. And there's precise computational hardness assumptions that are associated with each cryptosystem.

So let's separate out functionality from security. We're going to talk about functionality for the next few minutes. Alice is going to pick two large secret primes, p and q. So what I'm going to describe here are Alice generating her public key and her private key.

She's going to then publish her public key and keep her private key secret. Bob does the same thing. And then after that, they have to register. And this is not something we'll spend time on beyond me saying it one more time. They have to register their public keys with the VeriSign or the RMVs like I talked about.

So everyone knows that Alice's public key is this long number. But no one knows Alice's private key. So Alice picks two large secret primes. So these are actually going to result in the creation of our private key.

And then Alice computes N equals pq. So she just multiplies those out. She chooses an encryption exponent, e, which satisfies this little equation, which says that it's relatively prime in relation to p minus 1 times q minus 1. And she knows p and q. So she can compute p minus 1 times q minus 1.

So the gcd of e and p minus 1, q minus 1 is 1. And you can certainly accomplish this simply by choosing e to be a prime. Because then a gcd of a prime with anything else is 1. And it turns out that RSA uses-- this is all going to be public, by the way. e is going to be public. So you can just fix that.

And most RSA algorithms just fix that to be a small number. The encryption exponent is a small number. And the reason it's a small number is because you're worried about performance. And we're going to exponentiate using e. And the smaller it is, the faster the encryption is going to go.

So if you want to encrypt fast and decrypt more slowly, unfortunately, that's the trade off here. You would pick a small e. And then we're going to compute our decryption exponent, which obviously is going to have to be private.

Because that's part of our private key. But that's going to be bigger if e is small. And that's just a trade off.

It's symmetric in the sense that while it's an asymmetric algorithm, it's kind of symmetric in the mathematical sense that the private keys and the public key operations are symmetric. So what is Alice's public key? Well, Alice's public key, which she can then publish, is simply m, e. OK.

Now, the fun starts. We have to figure out what the private key is going to correspond to. And it turns out-- and this is one of those things where how did they ever think of this? And that's still true 40 years later. You get the decryption exponent using the extended Euclidean algorithm.

And this is done by Alice secretly, where what you want is to have the relationship that e times d is 1. And this is mod p minus 1, q minus 1. And there's algorithms out there that would find the inverse that corresponds to d for e or vice versa. And they're polytime algorithms.

As long as you know this number here, mod p minus 1, q minus 1, and you know that Alice knows that, you can get your decryption exponent. And typically, if a is small, as I said, d is going to be large. By the way, the numbers here, p and q, are going to be the roughly 1,000 bits long. So that's essentially-- we're talking about huge primes here. And so n would be 2048 bits in that case.

So the private key, Alice's private key, you can think of as d, p, q. So now, it's clear as to what's public and what's private. n and e are public. d, p, and q are private.

So that's the set up for RSA. And it's not at all clear that RSA accomplishes either of the two things that we need, the first of which is functionality, the fact that encrypting, and then decrypting a message should get you back that message. So that's the first thing we need to look at. And the security part is actually a little bit easier. Because you can see we're going to have to make assumptions about factoring primes and so on and so forth.

Right here, you can just see that immediately. The biggest assumption made by RSA from a computational hardness standpoint is simply that if the adversary sees n, that they should not be able to factor it into p and q. Because if they can do that, it's over. So that's actually easier than the functionality argument.

So why does this work? And amazingly, we can actually do this in about 10 minutes. I'm going to explain to you why this works in 10 minutes. And the only theorem that we'll require on top of this, which I will not approve, because Fermat proved it centuries ago, is Fermat's Little Theorem that says that when you have p being a prime-- you can think of this as a special case.

You take m, and m is an arbitrary number. And if p is a prime, then this relationship holds. So you raise it to the p minus 1 power, and you get 1, mod p. So that's Fermat's Little Theorem that's going to be required. And that's pretty much the only thing that you have to invoke beyond sort of standard mod arithmetic to show that RSA works.

So what's going on here? Let's call phi p minus 1 times q minus 1. Obviously, that's showed up a couple of times. And you may as well represent it by using a smaller, simpler symbol. So we'll call that phi.

And we are going to say that d equals 1. Mod phi is given to us. And therefore, we can say that ed equals 1 plus k phi. So that's it.

All I'm saying is the remainder. Then you took to the mod with respect to phi was 1. So the actual number was 1 plus k times phi. k is some integer. Think of it as a positive integer.

Remember that we now have the p and the q are over there. And p and q are primes. So p and q are primes. And given that that's the case, we really have two cases to analyze.

Oh, I'm sorry. I missed one crucial point, which I should have told you, which is I gave you this. But I didn't actually tell you what is going on. I mentioned it in passing, exponentiation. But I didn't tell you exactly what the encryption algorithm was and the decryption algorithm was.

And obviously, you need that in order to prove their correctness. I mean, it'd be wonderful if you could prove correctness of this. There exists an algorithm that is such that RSA works or public key encryption works.

So it turns out it's extremely straightforward. c equals m raised to e. And that's part of the usefulness and the power of RSA, which is you take m and you exponentiate it. And you take c and you exponentiate it. And the first is the encryption.

You get the c through encryption, as you can see over there, the ciphered text. And m is the plain text. And you get that back.

So our goal here is to show that you have essentially something where when you exponentiate m raised to ed, it should give you m. For these choices that we have, of e and d, we've set up the d in such a way that m raised to ed-- because if you just go do encryption followed by decryption, you are doubly exponentiating. That make sense?

Ask me questions if this doesn't make sense. This is important. m raised to ed should give you back m. And if you can show that for any m, you're done. That's the functionality of RSA. All right.

So that's encryption and decryption. And so now let's go back to here. Now, ed equals 1 mod phi. Because I've set that up.

This is how I discovered d given e. So that's a given to me. That's part of what's called the key generation phase of RSA. And that's the mathematical relationship that I keep harping on in terms of the relationship between the public and the private key.

So given that p and q are primes, I have two cases. The first case is that gcd of m, p is exactly 1, which means that the message m. So what I'm comparing here, the two cases, is I have the message. And I'm going to break up the messages into two different categories.

That's it. There are all kinds of messages that are possible. These are arbitrary numbers. I'm going to break them up into two categories, one of which where the message is relatively prime in relation to the prime, p.

And it's not a multiple of p. That's the way you want to think about it. Obviously, gcdmp would be 2 if M were 2p. So the case I'm looking at is gcd of mp equals 1.

And then the another case is going to be trivial, actually, which is gcd of mp equals p. Did I say 2 when I said gcd of 2p, p equals 2? Come on. Wake up. Wow, that's it.

Perfect. Wake up. OK. So gcd of 2p and p is p. So those are the two cases. All right. So by Fermat's Little Theorem, this is really Fermat's theorem. And because he had a last theorem, for some reason, some people call this the Little Theorem.

But it's Fermat's theorem. And we know what that is. I just wrote that out there.

You can now write something that says what I'm going to do is I'm going to just take m raised to p minus 1, which is 1. So this thing is 1. And then I'm going to raise it to k times q minus 1.

And you'll see why I'm doing this in a second. Because I want to get the 1 plus k phi factor here. So I'm taking 1 and I'm raising it to this power, which obviously is going to give me 1 back. So all of that is straightforward.

And then I'm going to multiply this by m. OK. And this is clearly the same as m mod p. Because all I've done is multiply it by 1. All right. So why did I do this?

Well, I did this, because I want to group together these two exponents. And since I've run out of room here, let me just erase and finish this properly. The other case is easy anyway.

And so I can write this as 1 plus k p minus 1 q minus 1. And that, of course, is exactly m raised to ed, right? And so what I've done here is, because 1 times m is clearly m, but if I look at this, this is m raised to ed. So that's clearly m.

That's it. Just figured out that when I have k phi here, that's going to turn into 1, basically, when you exponentiate it. So that's the hard part, actually, as it turns out, of proving RSA's correctness, just introducing this 1 raised to something. And then the easier part is simply the case where the m is actually a multiple of p.

So you have a gcd m, comma p equals p. And in this case, you know that m mod p is actually 0. Because m is a multiple of p. So you're basically exponentiating 0.

What do you do with 0? You're going to get 0 on both sides. So you're sending a message that's essentially 0 mod p And when you decrypt it on that side, you get 0.

But one last line here is simply that m raised to ed is m trivially all of this mod p if m is 0, right? So that was the easy case. So it was really pretty straightforward.

In one case, we took 1 and we exponentiated it and showed the result in a couple steps. In the other case, you had messages that were 0 mod p. So it's very pretty. It works.

And so what happened here? I said that m raised to ed equals m. And what I did here, of course, was I did everything. So it's not quite done, a little slight of hand here as I switched over and talked about mod p.

So I had mod p over here. And I said p and q were primes. And I looked at p first. But what I need to do, just to finish this off, let me do this over here, is I have to do the same argument for q. And I'm going to put it together for n.

And the reason for that is simply that I have n over here. So remember n equals p times q. The encryption and that decryption are going to be done mod o. Certainly, the encryption has to be done mod n, because n is only public number that you have that you can mod with, correct?

So what I've done here, this analysis is for p, can do the same for q. It's exactly the same, because p is a prime and q is also a prime. But I have to just do one last thing, which is put these two things together and say that n equals p times q, so the math is all going to work out.

Let me just write that out. It's not too difficult to explain, once I have this up here. So in both cases of p and q, so when I say both cases, I mean the pk's and qk's. I have m raised to ed equals m mod p. And m raised to ed is the same as m mod q.

And since p and q are distinct primes, we can say that m raised to ed equals m mod N. And that essentially says c raised to d, if you really want to put it all together, which is m raised to e raised to d, equals m mod N, which of course is what we want here. And this thing was also mod N. This is mod N, mod N, mod N.

All right. So that's RSA. That's your first public key algorithm, the first public key algorithm, at least that stood the test of time, still in use today. From a standpoint of computation, this is the hardest part. You have to exponentiate, and you have these large numbers.

And as the years have rolled by, RSA, as I've said, withstood the test of time. But the parameters have increased. Way back then in the '70s, they were thinking about 512-bit primes. In fact, I can't recall whether n was 512-bits or p and q were 512-bits. But if p and q were 512-bits, then n would be 1024.

And now, NSA recommends 8192-bits for n. So there's been an increase. But the nice thing is that it's not like there's an exponential increase in the computation. Because the computation is polynomially related to the number of bits.

So if you double it, I think, if I recall correctly, decryption is going to be the cube of that. Or actually, verifying signatures is probably the cube of that. But don't worry too much about that. The bottom line is that as you double the size of the exponent, you're going to have a fairly small increase in the time required to decrypt or to verify a signature, et cetera. But it has grown from 512 or 1024 to 8192.

And so hopefully, you all understand how RSA works to some extent. I just will leave it at the hardness assumptions here are, like in the case of Diffie-Hellman, two-fold. And the first one is kind of immediately obvious.

Just like it was the case with Diffie-Hellman, where you had g raised to a flying about and obviously that has to hide a, here you got N, capital N, being published. And if anybody could take N and factor it, there may be multiple factorizations. But you're going to get a unique prime factorization. So that's what you want, that unique prime factorization of N.

And if you get that, then you've broken the System because you know what p and q are. And so this is all public in the sense that this algorithm is public. If you're using RSA, this is what you're following.

So the person is trying to figure out what the two primes are that together get multiplied to form capital N. And so that's a factorization problem. And so RSA hardness assumptions are given N, hard to factor into p, comma q. And this is factoring. And then one other thing, which is given e-- so you're not actually breaking the entire cryptosystem. But you're breaking the privacy associated with a particular message.

And so you could break the privacy associated with a particular message. You're given e, because that's public. And you don't know what p and q are. But you know that e is relatively prime with respect to p minus 1, q minus 1, because that's RSA algorithm. And that's a publicly known.

And you also know c, which is the ciphered text. And so what you're doing is you're trying to discover m. So you're trying to break a particular encryption that was created by the RSA algorithm. And you haven't discovered the private key here. That's only discoverable through the factoring problem.

But you could break security if you can find m such that m raised to e is c mod N. So you're doing the searching for an m. So you're trying to discover an m that you can exponentiate to get what you have on the right-hand side.

Because clearly, you can compute what's on the right-hand side. So this is simply called RSA problem. So those are the two computational assumptions that you need to make in order for RSA to be secure. Cool. Any questions?

AUDIENCE: [INAUDIBLE] center?

SRINIVAS DEVADAS: So that's anonymity. Yes. There's ring cryptography. And there's a whole host of protocols. I actually did some of them based on RSA, where you can, by collecting a bunch of private keys together, essentially set it up so it can be verified that the message came from a collection of people, but you can't tell which person the message came from.

So there's just a whole host of things. There's thousands of papers written. There's a wonderful field. I encourage you to look into it if your interests are inclined this way. And it's just gone on and on.

It's become more important with the internet. RSA, the company, was probably founded in the late '70s. And they struggled for a while. And then eventually, they were used for Secure Sockets Layer in Netscape, which was their big break.

And then, of course, Netscape meant the internet was around. And so really, the internet made RSA what it is today. And so just a whole host of wonderful algorithms out there, some of which are based in RSA and some that are broken.

And so let's talk for the last few minutes about all of the fits and starts that occurred in cryptography. And precisely what I'd like to focus on for the time we have left is hardness. So we spent a lot of time talking about hard problems.

And we talked about NP-complete problems that are hard. But they're hard in the worst case. So you have a situation where you have NP-complete problems.

And I'd like to talk a little bit about the relationship between NP-completeness and crypto. Because we've made these assumptions about hardness. Now, what's interesting here is that N composite is clearly in NP, but unknown if NP-complete.

So this is very interesting. The tried and trusted algorithm for public key encryption relies on a computational assumption where the problem associated with that assumption is not even known to be NPC. All right. So that's kind of wild.

So how does this work? Or why does this work? Now, if you take other problems, like, is a graph 3-colorable? And so what does that mean?

Well, you have three colors. And you're not allowed to reuse the same color on two ends of an edge. So if you put red over here, you can put red here, but you can't put red here and there. And so that graph is 3-colorable.

But if you had a click, then this would not be 3-colorable. Because you have all these edges. You have three edges coming out. And so clearly, the degree from a vertex is going to tell you what you have.

So if you have a 4-click over there, immediately it's not 3-colorable. But checking whether a graphic is 3-colorable is NPC. You can use a three set as a way of showing that.

So you can say, oh, wow, maybe I shouldn't be worried about RSA. I should just be building cryptosystems based on 3-colorability. Because it seems like a much simpler problem than all these grungy map that you have out there-- actually, beautiful map that you have out there. OK.

So that's something that's a perfectly reasonable question to ask. And then we have Knapsack. Knapsack is simply you've got a bunch of items and you just want to figure out whether you can get this particular sum S. Knapsack is NPC as well.

And you got a bunch of weights given to you. And the BI are going to have to be 0, 1. So you just want to discover a particular assignment of the BIs, such that you pick the appropriate items to put into the knapsack, right? That's it.

That's a perfectly reasonable problem to potentially use as a basis for computational hardness to go build cryptosystems. And people did that. People did that for years. They tried and they tried.

And they produced cryptosystems, public key cryptosystems, based on Knapsack that look fantastic. And they work from a functionality standpoint in the sense that you would use this Knapsack-- and I'll give you a sense of how this is done in a minute-- problem to encrypt. And then you'd use a different kind of Knapsack problem to decrypt.

And when you encrypt it and decrypt it, you did get that same message back, except the whole world knew what the message was. Because the problem associated with the Knapsack wasn't hard enough. So the computational hardness was what broke the Knapsack schemes.

And then you come down to asking why is it that this problem that's not an NPC seems to have stood the test of time, but all these other problems, like Knapsack and 3-colorability, which is even worse than Knapsack, when people have built cryptosystems based on this, they've all been broken very quickly? And so why is that? What do you think the reason is, sort of at a high level? What does NP-completenss say?

When we talk about complexity, what are we worried about? Most of the time, what are we talking about when we talk about complexity of an algorithm? Or in this case, in the case of a problem, what adjective do we put in front of runtime, for example, then we compute complexity?

AUDIENCE: Worst [INAUDIBLE].

SRINIVAS DEVADAS: Worst case, right? Worst case. In the worst case, you're going to be able to create random graphs where it takes exponential time to discover whether they're 3-colorable or not. But in the average case, all you do is if you have a large graph, if there's one little 4-click in the graph and you can find it, instantly you know that it's not 3-colorable, right?

So it turns out that's 3-colorability is just the worst thing ever when it comes to cryptography. Because the larger the graph-- and you need this graph to be large. Because anything that's small, is constant time, right? Because so what if it's exponential? It's constant time.

So you need the graph to be large. When you have a random graph that's large, the chances you're going to find a 4-click in a 2,000 vertex graph is pretty high. And so if you just go scan and look for a 4-click, instantly you know that this graph is not 3-colorable, right?

So in the average case, 3-colorability is easy. It's easy to solve in the average case. And the wonderful thing about factoring is as long as the numbers are large, doesn't matter what the numbers are, it's hard to factor in the average case.

So that's the big difference. If you're going to take anything away from the rest of this, it's the difference between problems that cryptographics systems are based on. The systems that have stood the test of time, they're based on problems that are hard on the average.

And the NP-complete problems, like the simple ones here, are hard in the worst case. And this is also true for Knapsack. So that's the essence of it.

I'll just give you a sense. You can read the notes. There's a way of generating secret keys and public keys using Knapsack that I think is kind of interesting that is worth looking at, even though all of these systems are broken.

It's just kind of cool. You know, how would you get encryption out of a knapsack? I mean, you're putting things in a knapsack and taking things out. How can you set it up so you get an asymmetric key system, a public key system, through a Knapsack problem?

So I'll just give you a sense of that. And you can read. I won't finish. But I'd like to do what we did here for RSA in the time that I have left for Knapsack. That is kind of cool.

You get a sense of the variety of different public key cryptosystems that are out there by looking at something that is very different from RSA. So in the Knapsack problem, the general Knapsack problem, what's hard is NPC. There's a super increasing Knapsack problem that's easy, that can be solved in linear time.

What is a super increasing knapsack? Well, a super increasing knapsack is something where I Wj has this property. So an example of that is 2, 3, 6, 13, 27, 52.

So the rates are super increasing. 2 plus 3 is less than 6. 2 plus 3 plus 6 is less than 13 and so on and so forth. Do you see why super increasing knapsack is easily solvable? I mean, what is a knapsack?

I got a limit on the amount of stuff I can put into the knapsack. And I want to make to be able to say yes or no in terms of whether it fits exactly or not, just in terms of our definition. So what I do here in super increasing knapsack? Yep.

AUDIENCE: [INAUDIBLE] from the biggest to the smallest [INAUDIBLE].

SRINIVAS DEVADAS: Exactly. That means that there's a linear time algorithm that basically solves the problem. And you know that you can do that, and you would get the correct answer. So that's pretty much what you've got. That'll give you the highest weight.

If you have 13 exactly, you know you can't put 52 and 27. You get 13. There's no point in putting 2 and 3 and 6, because that's not going to give you 13. So that's clearly easy.

So we've got an interesting case here, assuming this is all going to work out from an adversarial standpoint, which unfortunately it doesn't, you can look and say, ah, I want encryption to be the super increasing knapsack. Because that should be easy to do. And I want the decryption, not knowing the private key, to be as hard as knapsack. OK.

So that's the kind of thing that you could do if you built a cryptosystem. And people did, Merkle and Hellman. Hellman is the same guy, the second name, in Diffie-Hellman. They proposed this particular system that ended up being broken soon after.

But the idea is that you create a private key. And the private key is a super increasing knapsack. And then you use a private transform in order to get a-- and this is really I put it in quotes, because this was the bug-- "hard" Knapsack problem. And this corresponded to the public key.

And so what you do is you won't actually have to solve Knapsack for encryption, the hard problem. The encryption would just simply take the public key, which is completely public, and you would create the encryption of a message using this particular public key in a polynomial time. But the inversion, not knowing the private key, you would force the adversary to solve what you think was hard general Knapsack problem to actually break the scheme or to get the decryption.

And so let me show you really quickly how this works with numbers. And we won't have you worry about symbols and things like that. So just give me a couple of extra minutes here.

So let's say that I had a message. Oh, before I do that, let me look at-- let's say, that we chose N equals 31 and M equals 105. This is actually the message.

No, I'm sorry. Capital M is not the message. These are public parameters. And we're going to take-- this is a transform.

Oh, I'm sorry. These are not public. These are private. My bad. So what I'm going to show you is I'm going to take a super increasing Knapsack. And that's exactly what I have up there.

So that corresponds to an easy Knapsack problem. I'm going to convert it using these private parameters, N equals 31 and M equals 105. And so our private key is our super increasing knapsack, which is 2, 3, 6, 13, 27, and 52.

And the public key, what I'm going to do is simply multiply each of these, 2 times N. And I'm going to take mod M. So for each of those values, I multiplied by N, which is 31, and take the mod of 105, and I end up getting 62, 93, 81, 88, 102, and 37.

So you can get a private key and a public key using this private transform. I'll let you look at the notes. But basically what happens is when you take a particular message M, what you end up doing is you want to encrypt it using the public key, which is this quantity over here. And the way you encrypt that is simply by taking a particular message.

And let's say that the message is written as 011000. Then all you do is add up 93 and 81, because those are those two. And you say this is going to get encrypted by 174. So the message encryption is simply a simple operation where you add up weights of the knapsack. So you end up getting 174 out here.

And the hope is, of course, that when adversary sees 174-- and this is the part where things get a little iffy-- that it's hard-- you have to think about lots of numbers here, of course-- for the adversary to figure out that that 174 is actually 93 plus 81. OK. So the diverse is not necessarily an easy problem.

And that's exactly what Knapsack is, right? I tell you what the sum is over there, which is S. And I tell you what the weights are. And it's hard for you to figure out what the BIs are. So now you see why this didn't work.

So you have to have a situation where in the average case whatever you produce for the ciphered text here, you're sending out the ciphered text according to this cryptosystem, which is 174, and you want to make sure that the adversary can't figure out that this is actually 93 plus 81. Amazingly, people thought they could build systems using this assuming these numbers were much larger than they are here. But that certainly wasn't the case. Because in the average case, you end up being able to break these systems.

The last thing is, of course, you don't want to necessarily solve the hard Knapsack problem associated with this. So what ends up happening is you end up using N equals 31. So if you want to decrypt, you have N equals 31 and M equals 105. And what you're going to do is take this and multiply it by N inverse mod M.

So rather than doing times N mod M, you divide by N mod M. And you can do this operation relatively simply. And you can go back from 174 to figuring out what the actual message was by computing this quantity.

So I'll stop there. I didn't quite get to everything that I wanted to cover. But take a look at the notes. Get a sense for why the difference exists between NP-complete problems and problems that were used in cryptosystems. And happy to stick around and answer questions.