 So why did we spend two lectures going through all this new math? Some of it may not be new, but some theorems and some concepts that are definitely new. Well, because in public key cryptography, as opposed to symmetric key cryptography, we commonly use these mathematical principles to design ciphers. And one of the things we started to see, some problems are hard to solve. Factoring integers when the numbers are large, factoring that large integer into two primes is hard. Calculating the discrete logarithm is hard. Calculating Euler's totian is hard. By hard we mean if the numbers are large enough you cannot find the answer on your computer. But it's usually easy to go the other way. The other way of discrete logarithm is raising to the power. We can raise to the power. If we know two primes and multiply them together to get a large number, we can do that. So we take advantage of these problems. It's easy to calculate in one way, but it's hard to calculate in the other way. And that's what we'll use for encryption and decryption. It'll be easy to encrypt something. It'll be hard to decrypt it unless we know some secret values. And that concept is used in public key cryptography. We don't have time to go through many slides in this. What I want to go is go direct to an example algorithm of public key cryptography. So we see some of the number theory in practice. And then, because this is our last lecture, after the mid-term we'll come back to the concepts of public key cryptography. Look at advantages and disadvantages. We just want to see an example today. An important thing to remember about public key cryptography is that there are two keys. In symmetric key cryptography there's one secret key. You encrypt with one key, you decrypt with that exact same key. In public key cryptography you encrypt with one key, you decrypt with a different key. But those keys are not random. The keys are related in some way. So such that we can successfully decrypt with a different key. And that has a key advantage, but let's go direct to an algorithm and see it in practice. The algorithm is called RSA. It's named after Ravesh, Shamir and Adelman. They're initials. Ron Ravesh you saw was a creator of RC4 and many other cyphers. So the people who have created some of these algorithms have made other contributions to cryptography. We'll talk about the history of RSA later, but let's go to how it works. The algorithm is here. Before we encrypt we have to generate a key. Remember DES or even simplified DES. In simplified DES we choose a random secret key to start and in your homework you have to choose a random key. In RSA we don't choose a random key, we generate a key from some parameters. Maybe those parameters are random, but we generate a key from that. So there's a key generation process, but we generate two keys. We'll call one a public key and one a private key. By definition a private key is kept secret. If I have a private key and I tell you that private key it's not a private key. So a private key is a secret key. A public key can be made public. It's not secret. So what happens is that every user generates a key pair. We talk about a pair of keys per user and I denote them as pu and pr, pu being the public key, pr being the private key. So if I want to use RSA I generate my key pair, pu, pr. I can tell everyone my public key. I can put it on my website. I can attach it to the bottom of my email and put it on my office door. So everyone knows my public key, but my private key I must keep secret. So that's the assumption we'll make here. We can know other people's public key, but we never know someone else's private key. And there are some other parameters we'll see as we go through. And every user generates a key pair. You have your own public-private key pair. I have mine and we'll use them to encrypt and decrypt messages to each other. So we'll first generate keys. We're going to use some small numbers so we can calculate, but in practice we need to use large numbers. Then to encrypt a message, some plaintext message M. We'll call it M not P for plaintext so we don't get confused with the public and private P's. To encrypt plaintext message M, we take M. We take our message, treat it as an integer. Let's say my message is a short set of letters, hello. Then I convert that into an integer. Maybe I convert each letter into ASCII values and combine them to make one number. We take that integer, raise to the power of some exponent E, which will come from our keys, mod by N. And we get ciphertext. You'll see this in the example, but one thing that I'd like to make clear now, encryption algorithm is this equation for RSA. Remember that encryption algorithm for desks, or even simplified desks, that encryption algorithm for simplified desks involve multiple pages of S boxes, permutations, XORs, degeneration. You'll know how to simplify desks for the exam, but there are many, many steps. In RSA, it's an equation with four variables. So conceptually, RSA is very simple and some say very beautiful in that it can encrypt something with such a simple operation and secure if used correctly. So that's interesting in comparing public key cryptography to symmetric key, the complexity. But we'll compare them later. Let's go through an example, yep. So let's say I have some message, a short set of characters and we can convert it to a number. So we need a way to convert it to a number. And it needs to be fixed. That is, my message is H-E-L-L-O. Let's represent each letter by a 8-bit value. Then I have a 40-bit value. Five letters, 8 bits each. So I have a 40-bit number. That's M. If I encrypt and get ciphertext C, then we'll see the decryption algorithm down the bottom. And the decryption algorithm must be designed such that we get the same M back. I must get exactly the same M back. If I do, I can convert it back to hello. If I know the way that I converted H-E-L-L-O to an integer, then I know if I have that integer I can convert back to H-E-L-L-O. There must be some way to convert the normal message into an integer. And there are algorithms to do that. That raises an important point. We must make sure decryption works. And we'll see decryption is the same as encryption with a few different parameters. Before we go through the example, everyone has their notes. The new lecture notes. Any questions on the theory? This example will be in the exam. There's always a question about RSA in the exam, and it's usually hard. Prove that something is secure, or defeat some instance of RSA. So we'll follow this algorithm, but we'll use some small numbers to calculate. First step, generate what we say is a key pair. Public key and private key. And we choose two primes, p and q. They should be large, but on my example I'll choose small ones. And calculate n is p times q. Let's try it. I'm going to choose two primes, p and q. Let's say 13, a small prime, and another prime, 23. And in practice, those numbers would be chosen to be very large. Close to a thousand bits, maybe hundreds of bits in length. And randomly and secretly, I would not tell you what these values were as part of the key generation. Then I calculate the multiplication of those two primes, which will be called n. That's easy to calculate. That is, a computer can calculate that easily. Multiplication, 13 times 223, 299, I calculated it before. So this is what I do privately. I'm generating my own key pair. Now I choose a value e, which is relatively prime, with actually maybe I've skipped a step. Sorry. If we go back to the slides. We chose two primes, p and q. Calculated n is p times q. We're going to select a value of e, where e is relatively prime with a totion of n. So I'm going to need the totion of n. Let's calculate that first. What's the totion of n? We'll do it here. Because we know n is made up of multiplying two primes together. We know it's the totion of p, q. Which is the totion of p times q. The totion of q. And we know the primes. So it becomes 12 times 22. So that we can calculate easily. So this is still what I'm doing to generate my key pair. Find n, calculate the totion of n and note that the calculation of the totion of n is easy for me to do. We're going to take advantage of this property. If n can be factored into two primes. Then we can calculate by multiplying the totion of those two primes together. And the totion of a prime is very easy. It's prime minus one. So that's something that even with very large numbers, I can calculate. As long as I know p and q. Any questions so far? What is the public and private key? How are they secure? How are they used? And then we'll see how we talk about the security of the public and private key. We're just creating them at the moment. Next step, step two. Why do we need the totion of n? We're going to select an e, some number e. Such that the greatest common divisor of e and the totion of n is one. Greatest common divisor of two numbers equals one. The other thing we say is that those two numbers are relatively prime. So we can say it in either way. Choose an e which is relatively prime with the totion of n. An e should be less than the totion of n. So there are some limits here. So find an e which is relatively prime with 264. Maybe let's start. Is one relatively prime with 264? Yes, one is relatively prime with every number. There's a limit. We don't want one. It's not going to be useful for our algorithm. So don't choose one. Make sure it's greater than one. Two is two relatively prime with 264. Greatest common divisor of two and 264 is not one. It's two. Therefore they're not relatively prime. We can't use e of two. Three, check. 264, can it be divided by three? Divide by three. So then it's not relatively prime. Four. Four has a divisor of two. 264 has a divisor of two. So even numbers won't work. Five. Five is prime. Can 264 divide by five? No. It has to end with a zero or five to divide by five. So in fact five is relatively prime with 264. So we could choose five. But they're more than one number. There's others. You can keep trying some others. We just need to select one. And let's start with five because that's the first one we got to. So there are some numbers relatively prime with 264. Choose one of them. Let's say e to five. The greatest common divisor of 264 and five is one. So that satisfies our condition. We'll see why we need that condition when we look at the security of this scheme. Now find another number, d, d which is the multiplicative inverse of e. We know e, it's five. Find the multiplicative inverse of five in mod the totion of n. Does every number have a multiplicative inverse? No, not every number. Under what conditions do we have a multiplicative inverse? If our number is relatively prime with the modulus, then we do. That's why we chose e in this way. Find a d which is a multiplicative inverse of e in mod totion of n. In other words, d times e equals one. Mod the totion of n. What we want is e times d mod the totion of n equal to one. That's our definition of multiplicative inverse when we times two numbers together and we get one. What's the answer? What is a value of d? Five times something mod the totion of n. Five times something mod 264 equals one. Multiply two numbers and get one. That's what we mean by multiplicative inverse. How do you find a number? 55. 55 times five mod 264. I think 55 won't work. 53 might work. How would you do that in the exam? Find d. How would you do it manually? 264 plus one. When we mod by 264, the remainder should be one. Five times something mod 264 gives us one. Five times something should be either 265. This something must be an integer. Can we get... Sorry. Five times what? 53 gives us 265. 265 divided by five gives us 53. So 53 is a possible answer there. So the way to solve that... Well, we realize it's quite simple in this case. Five times 53 mod 264 does equal one. If we didn't get the answer in the first case, we could try... We'll come back and try a different value of e later and show you another case. So that's d. E and d are multiplicative inverses of each other. Mod the totion of n. Because we wanted to find a multiplicative inverse, the reason we chose e to be relatively prime to the totion of n is because we know if we're relatively prime to the modulus, there will be a multiplicative inverse. If we chose an e which is not relatively prime with a modulus, we would not get a multiplicative inverse. Because we wanted an inverse, we needed to choose e to be relatively prime with 264. We're finished in the key generation steps. And we say that there's a public key and there's a private key. And the public key we actually write as two values. And this is a little bit confusing, or the naming is. We define the public key as e, the value of e, and n. And let's say this is the public key of user A. And then there's a private key of user A is the value of d and n. So this is the result of key generation. I come up with these values of public key and private key. I'm, say, user A. I did this step. And the public key, e is 5, n is 299. And I can tell everyone these values. They are public. And my private key, d is 53, n is 299. Now this is a bit confusing. n is the same n in the public key. n is not private. d must be kept private. But n is public because it's also in the public key. But it's common that we combine the d and n together. So I say this is the private key of A. The private value of importance, the secret value, is d. I cannot tell anyone what d is. Everyone knows what n is. So that part of my private key they know, but they don't know the d part. That's secret. The other thing that I cannot tell anyone is how I generated this key. In particular, p and q. So I may store the values of p and q or I may know them when I generate them. And even the totion of n, I may store that. I don't tell anyone those values. These are the private values. That is, we cannot let anyone know what they are. Whereas e and n can be known by others. That's our key generation step. Any questions on how to generate keys? Good. Then generate another key pair for user b. Spend 5 or 10 minutes and generate user b. Another user generates their own key pair. And I'll tell you the values of p and q. So we all end up with the same numbers. Choose two primes. p is 17, q is 11. Generate the key pair for user b. Same steps. Of course you'll get different values. So you remember those steps. Take the totion of n. Select an e. Find the multiplicative inverse. We've chosen p and q. We can easily calculate n. Totion of n is easy because we know p and q. Then select an e. Let's do that. n equals 17 times 11. 187. Is that right? The totion of 187. Because we know n and the prime factors of n. The shortcut. And that's why we choose n this way. We choose n this way such that it's very easy for us to calculate the totion of n. It's the totion of 17 times 11. Which is the totion of 17 times the totion of 11. Which is 16 times 10. So this algorithm we're seeing that. The reason we've chosen n this way as multiplying two primes together is because it's easy to calculate the totion. I have a large number. n is 187. Calculate the totion. Easy to do if I know 187 has prime factors. 17 and 11. But if I have a large number n and I didn't know the prime factors, calculating the totion would be hard. Next step. Choose an e. Greatest common divisor of e and 160 is 1. Well the even number is not going to work. Because 160 has a divisor of 2 so any even number has a divisor of 2. So we try the odd numbers. 3 and 160. 3 works. 5 no because 160 divides by 5. 7 works. And we could keep trying. 9. I think 9 works as well. So there are multiple answers there. They're not just one possible but we select one. In practice it's common that we all select the same number. 3 works for all of the values. So 3 is a nice number to select. So in practice we usually select a common value. It doesn't matter. It's public. You can know my value of e. It's okay. What did you choose? 7. I would choose 3. What's d? We choose a d such that something times 3 mod 160 equals 1. Multiplicative inverse of 3 in mod 160 is something times 3 mod 160. 107. Correct. If you need to calculate well again we can try. Mod 160 equals 1 so we think can 161 divide by 3 and give us an integer? We need an integer remember? No. We don't end up with an integer. So next we try 321 divide by 3. Can we? It equals 107. Because 321 mod 160 is 1. If that didn't work I would try 481. Because it needs to be a multiple of 160 plus 1. The second one got us there in that case. So that's a way to do it quickly or do it in the exam if you need to. So I would end up with d equals 107. But I told you to use the second value of e. If you use 7 what would your d have been? You use 7 I think. What d do you get? 23. So if you choose e of 3 you get d of 107. If instead you chose e of 7 you get d of 23. Fine. You choose one of them. Since I told you to choose e of 7 let's write down for that value. The public value of b, e, let's use this one, is 7, n is 187. The private value of b, d is 23, n is also 187. The secret value, the one of importance from b's perspective is d equal to 23. As well as p, q and the totion of n they must be secret. So you actually generate these values on your computer. One of your homeworks you'll use open SSL to generate your key pair. And while open SSL it chooses two values of p and q, two large values of, two large primes. And goes through these steps and it will save in a file the key pair. Now let's encrypt and then decrypt. Any questions on key generation? The questions, is it secure going to come up? That is, is it a good way to do it? What can the attacker do? But we'll come to that after we encrypt. Ah, sorry. So it depends on what value of e you chose. Two different answers here. This pair or this pair of e and d. I calculated for two different values of e but I chose this one in fact. There are multiple values of e that satisfy the condition of being relatively prime with 160. You need to choose just one of them and that's used in your key pair. So another key pair maybe the public private key of user c could be the e of 3 and the d of 107. But it would have been unlikely that they'd choose the same primes p and q. Let's encrypt. User a and user b. User a wants to send a message to user b. First, what keys do they know? Well, every user knows their own key pair. Let's write them down. Public key of a, these are the ones we calculated. I know as user a my public and private key values and b knows its key pair. What do we choose? e was 7. d was 23. What else does user a know? A knows the public key of b. We assume every user knows every other user's public key. And similar, b knows the public key of a. Public key of a. Public key of b and b knows the public key of a. How do they know them? Maybe they told each other or they post it on a website. How do they know them and for sure it is the public key of a? That's a problem which we'll come to after the midterm. But for now we assume that you know everyone else's public key. You've exchanged them in advance. Now we want to encrypt a message to send from a to b. So let's choose a message and let's go to our algorithm encryption. Our message we're going to treat as an integer. In real life we don't want to send numbers to people. We want to send text files, pictures and so on. But we need some way to convert them to an integer. So there are ways. Same way we can convert ASCII or use ASCII encoding to convert letters to binary values. We can convert to integers. There are issues when the integers are too large because we have a limit on the size of the plain text. The plain text, the integer, might be less than n. So if we know n, make sure our integer is less than that value. In practice n will be very large so m, the plain text, can be very large. So the message I want to send, let's choose some number. Let's say 8. There's my integer I want to send. I just choose a small one so we can calculate. I want to send from user a to user b. And I want to make sure no one who intercepts the message can see the plain text. Can find our message. So I want to send 8 to b. But I don't want anyone else to know what the message is. So I'm going to encrypt it. And send the size text to b. Such that hopefully another user cannot discover the message 8. Of course 8 doesn't make much sense. But if we had larger numbers maybe the number represents a sequence of letters in some message. Using ASCII encoding. How do I encrypt? Take the message m, raise it to the power of e and mod by n. But be careful. To send a message confidentially to user b, the way that it works with public key cryptography, is I encrypt with the public key of user b. I'm user a. I'm going to encrypt with the public key of user b. And the design of the algorithm, RSA in this case, should be such that if I encrypt with one key in the key pair, it can only be successfully decrypted with the other key in the key pair. That's how the algorithms are designed, we'll see that. So if I want to encrypt with the public key of b, who can decrypt the cypher text? If something's encrypted with the public key of b, then the algorithm should be designed such that only the other key in the key pair can decrypt. The other key in the key pair is the private key of b. So the concept, encrypt with the receiver's public key, only they have their private key so only they can decrypt. And this is the general concept, not just for RSA. Encrypt with one key, decrypt with the other. Encrypt with the public key of the other person such that only they can decrypt. Because only they have the private key. Let's try that. I want to send this message to user b. So what I do is I encrypt it. c equals my message m raised to the power of e mod by n. That's the encryption algorithm. m is 8. e, I want to send to b so I must use the public key of b. e is 7. n is 187. I do the calculation and this is relatively simple with a computer raised to the power mod by 187. 8 to the power of 7, sorry I'm not in my calculator. 8 to the power of 7, mod 187, 134. Just take 8, raise it to the power of 7 and then mod by 187 and you get ciphertext with a value of 134. There's no theorem being applied here. That's my ciphertext value. Send it to b, ciphertext 134. That's what's sent across the network. b will receive 134, the attacker. Any malicious user may also intercept 134, but let's see what b does. b decrypts. What's the decryption algorithm? The decryption algorithm is essentially the same as the encryption algorithm but using the different values. Ciphertext to the power of the private value d mod by n. To decrypt, c to the power of d mod by n. c is what's received, 134. What's d? It was encrypted using b's public key, so we must try to decrypt using b's private key. So I'm b, I just received a message to me. So I know to use my private key to decrypt. My private key is b, private key d is 23 and is 187. Calculate a time, 134 to the power of 23. Problem. My bad example. Too large. How are you going to calculate that? Thank you. It's getting late in the lecture. Mod. I thought it should work, but I thought I chose the wrong numbers. That's better. It may not work on your calculator, alright? I'm using an arbitrary precision calculator that does handle big numbers. But your calculator may go up to a limit, so you need to be careful. So we need to choose small values that we can deal with. We get 8. Some of you may not see that clearly at the back TV. The value is 8. Magic? We got the same message back. That's good. We expect with decrypting the ciphertext, we must get the same message back. Otherwise, this is not reversible. It did give us the same message back, and you're all asking why? Why does it give 8 back? Another exam question. Prove that it will always give 8 back. We may do it in a moment. But the algorithms are designed. The key generation, the encrypt and decrypt are designed such that we will always get the same message coming back when we decrypt, if we do it this way. That's why we went through those steps of the key generation. If we encrypt our message using one value of the key pair, in this case the public key, and then get ciphertext, if we decrypt with the other value in the key pair, we'll always get the original message back. We can prove that? With RSA it turns out we can use the keys in opposite direction. Any questions before we look at the attacker? So we've encrypted and decrypted, and magically it gave us the right value. There's a proof to show that it will always give us the right value. But first we'll look at an attacker. Why is it secure? You can try other values and see if it works. You may need a bigger calculator. When you try, M is, let's try, M is another number. What M do you like? Someone choose an M. It needs to be less than N. We'll encrypt again. 99 to the power of 7, mod 187, encrypt, 176, decrypt, 176 to the power of 23, mod 187, 99. You can try other values and it will always be such that when you use this algorithm you'll get the right plaintext back. Let's see what the attacker needs to do. The attacker intercepts the ciphertext. Can they find the plaintext? Or what do they need to do to find the plaintext? Let's try some different approaches. What is known by the attacker? Well, first we know the ciphertext. We've intercepted. We know c is 134. What else do we know? Public key of both users. In this case, the public key of B is the one that was used. So yes, we know the public key of B. What was it? E is 7. N is 187. What else do we know as the attacker? All right, we know the public key of A, but it's not relevant in this example because we didn't use it. So what do we want to find? Now you're the attacker. You want to find M or what else would you like to find? M or D. D is part of the private key. So the private keys at the top. Remember, we know as the attacker the public key of B the private key of B contains N, but I know N already. But I don't know D as the attacker. So if I could find D, I know the private key of B. And if I can find D, then I can decrypt. If I find D, I know C, I know D, I know N, I can do what B did to decrypt. So my challenge as the attacker, find M or D. How do we do that? Well, let's look at different things that they could try. Try M, try M. That is, I know that the message was some value between 1 and 187. Because our rules were, message must be less than the modulus N. To encrypt, M must be less than N. So from the attacker's perspective, do a brute force on the message. That is, I know the algorithms. As the attacker, we know the algorithm. And of this equation, what do I know? I know C is 134. M is unknown at this stage. E is 7. N is 187. So the first thing I can do as the attacker, all right, let's plug in M. M is 1. Does the answer equals 134? No, M equal to 2. 2 to the power of 7, mod 187. Does it equal 134? No. Keep trying until I find a value of M such that the answer does equal 134. And now I found the message. So this is a brute force attack on the message. Not on the key. Just try all possible values of the message. And it would work once we'd get to M equal to 8. I'd plug in 8 as the attacker, 8 to the power of 7, mod 187. I'd get 134. Now I know the message. So I've defeated the security of this scheme. In practice, how do we make this impossible for the attacker? Increase number of what? Make sure M can be very large. So that if we have say a random M, then the attacker has to try many possible values. How do we allow M to be very large? N must be large. Our condition is M must be less than N. It only works when M is less than N. So N must be very large. Practice, not possible if N is large. If N is very large, M may be very large. And the number of values of M I need to try is very large. And if we make it large enough, it will take too long. Calculating modulus to the power and then mod some number is not a fast thing to do. There are some algorithms to speed it up, but it is slow to calculate. So I have to do that many times and it may take centuries to do it. What else? Well, let's look at this equation. We have an equation. There are four variables. Three of them are known, one's unknown. We should be able to solve it. Just do the inverse. So this is a brute force on M. The second approach is inverse. That is, what's the inverse of this equation? This is an exponentiation mod some number. The inverse operation is a discrete logarithm. Slightly different from what we saw, but we can write it. What we want to find, that's how we could express it. The discrete log in base M, mod 187 of 134 equals the index or exponent of 7. That's the way to write that. In essence, we need to find the discrete logarithm of a number. Now it's different from what we saw in our discrete logs. We want to find the base before we want to define the exponent. It turns out they're effectively the same difficulty. Finding the base M or finding the exponent if you know the base are about the same. In terms of solving this for large numbers is not possible. In general, we need to find the discrete logarithm of a number. In practice, discrete logarithms are not possible if the numbers are large. Assuming the numbers are much larger than what we've got, discrete logarithms take too long to solve. There are no algorithms that would do it in a fast time. What else? There are other avenues. Find M, what about the other challenge? Find D. If we can find D, we can decrypt. Try and find the private key D, so let's look at that. Because what we also know, remember we know C, we know N. If we can find D, we can find M. So our next challenge, find D. How is D generated? Let's go back to key generation. D, E times D mod the totion of N equals 1. That's how we know that user B generated D. We know the algorithm they used. User B chose a value of E, I know that as the attacker. Then they found a D such that it was a multiplicative of inverse of E in mod the totion of N. What do we know from the attacker's perspective? We know E, what is E? I forgot, 7. 7 times D mod the totion of 187. We need to find the multiplicative inverse of 7 in mod the totion of 187. How do we do that? How do we find a multiplicative inverse? We need to know the modulus. To do this, we need to find the mod of 187. If I can find the mod of 187, it's easy to find the multiplicative inverse. That's what user B did. How do we find the totion of 187? We need to find that. Manual approach. The totion of 187 is 2 relatively prime with 187. It is 3 relatively prime with 187. Keep going up to 186, count all the numbers. We've got the answer. Possible? Yes, you can sit there with your calculator and try or write a bit of software that would do it and it won't take long. But if N is large, not 187 but maybe a thousand bit number, if N is very large, it takes a long time. There's no easy way to solve the totion of a large number. So the manual approach takes too long if N is large. Solving the totion of N is not possible if you do it manually. N is large, you need to try many possible values. But there's an easier way. The last avenue for the attacker. What do we do to solve the totion? If we can factor N into 2 primes, P and Q, then it's easy to find the totion. Because if I know P and Q, the totion of N is just P minus 1 times Q minus 1. So the second approach factor N into P and Q. Integer factorization, not possible if the numbers are large enough. Possible for our small 187, we could try very easily and find the answer. But when N is very, very large, there's no known algorithms that would do it in reasonable time. And you can try other avenues of attack and you'll see that they come down to these problems. For the attacker to find the message or D, they either need to do integer factorization, factor a large number into its primes, or calculate the totion of a large number manually, or solve a discrete logarithm. If they can do one of those three, then they can defeat this RSA algorithm. But these three problems, there are no known solutions that can do them in reasonable time if you choose large enough values. So we say RSA is secure. The attacker cannot find M or D if we use appropriate sized values. So that's where these concepts of the number theory come in of making this a secure encryption algorithm. Questions, lots of questions, I'm sure. Some of you can think of in the last few minutes. N still needs to be calculated as P times Q. Because when I generate my key, I need to calculate the totion of N. If I chose a large random number N, I wouldn't be able to calculate the totion of N. So that's why. So what we do, we start with two large prime numbers, multiply them together, then I get a very large N. So in practice, very large N is typically 1,024 bits. So N is 1,024 bits. Two to the power of 1,024. That's, I know it's wrapped around, but that's the maximum size of N. So that's, I don't know, hundreds of digits long. That's the value of N. The primes are smaller, but we multiply them together to get a 1,024 bit number. You can also go up to 2,048, which is more commonly recommended today. So you don't, you want a longer number, then that's alright. It's gone off the screen, a 2,048 bit value of N. That's the size that we're talking about that's considered secure. And then finding the totion of such a large number is not possible within reasonable time. Factoring it into P and Q is not possible. Solving it a discrete logarithm is not possible. Right, as always, when we use bigger numbers, we get more security here, but we slow down the performance. To do the calculations takes more time. So that's the trade-off with many algorithms. Increased security with larger numbers, but decreased performance. And that's a key limitation of RSA and other public key cryptographic algorithms. Compared to symmetric key ciphers, they're generally very slow. Very simple in concept, but the calculations on a computer are much slower than des and aes. So we've gone through key generation for RSA. Encryption and decryption, you just remember the same algorithm. It's the same equation, but you just use the keys in the different values. And remember, to send something confidentially to someone else, use their public key to encrypt. They will use their private key to decrypt. That's to achieve confidentiality. I want to send something to you, I will encrypt using your public key. You want to send something to me, you encrypt using my public key. Because the only person who can decrypt is the one that has the private key, which is the receiver. It turns out RSA can be used in the other order as well. RSA is commonly used, but we'll see that it's mainly used for encrypting other keys. It's a good text document, but encrypting other keys, secret keys especially. Because we don't have an exam next week, we'll stop there.