 Everything up until public key cryptography was using symmetric key cryptography or shared secret key cryptography, sometimes called conventional cryptography, the first approach. But some limitations of the conventional encryption techniques led people to develop public key cryptography. What's the recommended algorithm for symmetric key encryption? If you need to write some software, you need to encrypt some data. What algorithm? What cypher are you going to use using symmetric key cryptography? There are many to choose from. Which one would you choose if you have to develop some software that encrypts? What algorithm? What cypher? You wouldn't develop your own because most likely you would make an insecure one. You would make a mistake. You wouldn't even try to implement an existing one. You would use a library. Let's say you're a software developer. You need to develop an application that requires encryption of data. Then the recommended approach is not to implement your own algorithm. First, don't design your own algorithm because designing algorithms is not something that we can do in a day. It's something that people have done and developed the techniques over many years and the existing algorithms have been analyzed in depth and used a lot so people know how secure they are. Don't design your own. Don't even implement your own in most cases. Use a library that someone else has developed that's widely accepted and they're amortable around that others have implemented again because it's been widely tested and even though the algorithm may be considered secure, an implementation may have bugs in it. If there are bugs in the implementation, the resulting algorithm may be insecure. Use one which is widely accepted and tested. Use a library. What library is available for you to use for encryption? You've used it in a homework. What's the software that you used? Remember the command? Open SSL. Open SSL is actually a library. It implements many different encryption algorithms and what you can do if you write your own software is you can call that library. You don't need to implement the algorithm to yourself. You just call open SSL and it does the encryption for you. That's an example of a library and there are others. Which algorithm would you choose if you want to do symmetric key encryption? What's a recommended algorithm? Starts with A. AES. That's maybe the number one algorithm for symmetric key encryption. It's been around for multiple years. It's been tested a lot. People believe it's secure. It's fast compared to some other ciphers. It's fast to do encryption and it even has support in some hardware implementations. Your Intel CPU can do AES using hardware operations, not just software. It's very, very fast. So AES is considered secure. It's very fast. What's wrong with it? Why do we need some other approach? Why do we need public key cryptography if we have AES and other similar ciphers? Asymmetric key. So what's the issue? Key transfer. With AES, the encryptor and decryptor both must know the same key. I want to encrypt something and send you the encrypted file so you can decrypt. We must first exchange a secret key. How do we exchange a secret key? Encrypted. Using what key do we encrypt with? So we have this problem. How do I get a secret from A to B? And the public key cryptographic algorithms have been developed to overcome this problem. So the history, the quick history is that basically up until the 1960s everything was permutations and substitutions, symmetric key ciphers, going from the Caesar cipher all the way through to death at that stage, so death was designed in the 50s and 60s. Then it was later discovered that the NSA in America developed a concept or the ideas behind public key cryptography. This wasn't made known until much later, even more recently. And there's no actually reports on that. In the 1970s, the equivalent organization in the UK, the security agency, again wrote a report about public key cryptography but that wasn't released until a few years ago. So the first public knowledge of this new technique was developed by two guys, Diffie, Whitfield, Diffie and Martin Hellman, Diffie and Hellman. And they wrote a paper and published an algorithm which introduced this concept called public key cryptography. Their motivation, so this was in 1976 and before that there was no knowledge about these secret reports, they were released later. Their motivation was that up until then, when symmetric key cryptography was used, to exchange a key from A to B, the common approach was to give that key to some other trusted third party, like the government or some other organization, and they would exchange the key on your behalf. So it required some trust on some other parties. And we'll see that in the topic on key management. So they wanted to avoid the reliance of third parties. They don't want to trust someone else with their key. So they developed a technique which is we refer to as public key cryptography. And we will see their technique, Diffie-Hellman algorithm. And they also wanted to have digital signatures. The same concept, I sign a document and we think that my signature confirms it came from me. We'd like to do that electronically. I'd like to have a file, I'd like to be able to sign it, and then people can prove that it came from me, access some proof, some evidence. And symmetric key cryptography doesn't provide that proof. If I encrypt a file with a secret key, it doesn't prove that I encrypted it, because in fact there are two people in the world that own that secret key, me and the person I've shared it with. So another motivation was to allow digital signatures. And again, we'll see how that works shortly. So Diffie and Hellman developed the first technique and then shortly later some others. Revesh, Shamir and Adelman developed the RSA algorithm, which we know about. The idea of public key cryptography. With symmetric key cryptography, we use the same key to encrypt and decrypt. With asymmetric algorithms, we use one key to encrypt and a different key to decrypt. And it should be hard for an attacker to determine one of those keys in the key pair. One of them will keep secret, the other one will be public. We'll formalize that a bit more shortly. So the concept is that every user in a public key crypto system has a key pair. We call their public-private key pair, simply their key pair. It consists of a public value of that user and the corresponding private value. The keys are different, but they are related somehow. They're not randomly chosen. They are generated. And with RSA, we know the steps for generating the public-private key pair. And other users also have a key pair. By definition, the public key is available to everyone. You can tell anyone what your public key is. And the private key must keep secret. And we use the keys for encryption and decryption. But in some algorithms, we can use them in different orders. We can encrypt with the public key and decrypt with the private key. Or the other order, encrypt with the private key and decrypt with the corresponding public key. The assumption is that if we encrypt with one key in the key pair, we can only successfully decrypt with the other key in that same key pair. If something's encrypted with PUA, the algorithm must be such that the ciphertext can only be decrypted with PRA. But some algorithms support the opposite as well. If something's encrypted with PRA, the ciphertext can only be successfully decrypted with the public key PUA. So sometimes we use them in different orders. The next few slides show that for secrecy and authentication. You want to send a secret message to me? What key do you encrypt with? My public key, the receiver's public key. So here that's what we show here. If we want confidentiality, I take my message, I encrypt with the public P of the destination. PUB. I'm assuming a secure algorithm is used. Then the only person who can decrypt is the person that has the corresponding private key, which should be B. Only B has PRB. So B decrypts, therefore, the only person who can see the contents of this message is B. That provides confidentiality. Only one person can see the contents. But if we use the keys in the other direction, and I think we've seen examples of RSA that does this. So this is general for public key cryptography. RSA is one algorithm to do the encryption. There are others. So we've seen examples of this, but we can use the keys sometimes in the opposite order. Here, user A on the left sends a message to user B. User A encrypts using the private key of A, their own private key. User B decrypts with the corresponding key in the key pair, PUA, and they get the message back if they use that public key. Let's say the attacker intercepts this ciphertext. The attacker intercepts. Can they obtain the plaintext M? You're an attacker. You obtain ciphertext C. Can you find M? There's your challenge. Find M if you intercepted C. How would you find M? This is not RSA. This is in general. So it's not about specifically RSA. Any algorithm where we are assuming so far, if we encrypt with one key in the key pair, we can only successfully decrypt if we use the other key in the key pair. So if I intercept the ciphertext C, which was M encrypted with the private key of A, can I decrypt that? Yes. Because I know the public key of A. Because it's public. So this technique does not provide confidentiality. Anyone can find the message. We're not aiming to keep it secret in this particular case. What does it provide? It provides a proof that the message came from A. If this ciphertext decrypts successfully with the public key of A, then who encrypted it? It must have been encrypted with the private key of A. Therefore it must have been encrypted by user A. Therefore it proves that this message came from A. So this is a form of authentication. B can prove that the message they receive came from user A. Because it successfully decrypts with the public key of A, it must have been encrypted with the private key of A. And therefore must have come from A. So that's the purpose of this technique where we use the private key of the sender to encrypt. And this is the concept behind what we call a digital signature. A signs the message. They sign the message by encrypting with their private key. Same as you sign a document, it acts as some proof that that document came from you. You authorize that document. You put your signature at the end. We'll use this technique to provide a digital signature. We sign using the private key of the sender. And anyone can prove it came from A because they just decrypt with the public key of A. So this is the role of public key cryptography for authentication. And that's very popular. It's widely used this technique. So note we can use the keys for both confidentiality or we can use public key cryptography for confidentiality encrypt with the public key of the destination. Or we can use public key cryptography for authentication encrypt with the private key of the source. So we get two different services using public key cryptor. If you want both, you can do both. You just do two operations. Encrypt the message using one first, say the public key of B, and then sign it with A's private key. We can do both and combine them. It turns out confidentiality service is maybe not as common as the authentication approach for public key cryptography. So if you want to sign a document and send it to me, what key do you use to encrypt? You use your private key. So one of the homeworks we'll have coming up, you need to sign a document. You use your private key. If you want to make sure only I can read it, you would encrypt with my public key. So just get the key orderings correct. So for now, we've assumed that there's some algorithms, some encrypt and decrypt algorithms, such that if we encrypt with one key, we can only successfully decrypt with the other key in the key pair. What are such algorithms or what are the requirements on those algorithms? We know one example is RSA. There are others. What should they be required to do? This, we'll skip over. This just compares conventional versus public key or symmetric versus asymmetric encryption. Note that we use different names sometimes. Conventional, symmetric, shared, secret key, all mean the same type of algorithms. Public or asymmetric means the other type. Where do we use public key crypto? Well, there's really three main purposes. We can use it for confidentiality or secrecy. I want to send a secret message to someone. I encrypt with their public key. We use it for authentication. I want to sign something to make sure that someone else can confirm it came from me. Then we encrypt with my private key if I want to sign something. And related to the secrecy part, we will often want to send another key. Let's say an AS key secretly across a network. We want to exchange symmetric keys across a network. Well, it's common to use public key algorithms to do that, to exchange secrets. So key exchange is another way. So that are three main applications. There are different algorithms that are available for public key crypto. We've seen in detail RSA. We've studied RSA. There are others. We will study another one called Diffie-Hellman. So the original algorithm for public key crypto. There's variations on these and there's a general technique called elliptic curve cryptography, which has some advantages, especially in terms of speed compared to RSA. But maybe it's a little bit newer. So maybe people don't trust it so much. It requires some correct parameters. And there's a standard or a technique called the digital signature standard that is an alternative approach. And that uses something like it based on someone El Gamal encryption. But there are different algorithms. Some are designed to support secrecy, encryption and encryption. That is encrypted message, send it confidentially to someone else. RSA allows that. Elliptic curve crypto does that. Diffie-Hellman does not allow that. We cannot use the Diffie-Hellman algorithm to send, to encrypt our file to send to someone else. We'll see why when we go through the algorithm. Some support digital signatures, encryption with a private key. RSA and elliptic curve, yes. DSS, yes. Diffie-Hellman, no. Some support encrypting a private value, a key and sending to someone else. RSA, yes. ECC, yes. Diffie-Hellman, yes. Diffie-Hellman we'll see was designed for key exchange. Send a secret to someone else across a network without an attacker being able to discover that secret. So there's different applications of those algorithms. In this course we've gone through RSA, we'll look at Diffie-Hellman as well. We'll spend five more minutes or so going through some requirements or some assumptions and then we'll look at RSA and prove why it works. In general, what do we want for a public key cryptographic algorithm? We have key pairs, PU, PR, public and private key. It should be easy for a user to generate the key pair. The keys are not chosen randomly. We don't just generate random numbers, we use an algorithm to generate them. With RSA, what do we do? We choose two primes, P and Q, multiply, find the totion of N and choose E and calculate D. We generate our key pair. So we need that algorithm to be easy to perform. Easy, maybe it takes a couple of seconds on your computer to do it. And it should be easy to encrypt. If I have some message and I use, say, my public or a public key to encrypt, the algorithms should be such that it's fast or easy to encrypt. This is just a practical requirement. And it should be easy for the receiver, in this case, to decrypt if they have the correct key, that is. So if something's encrypted with public key of B, user B should be able to easily decrypt using the private key of B. So in terms of performance, key generation encryption decryption should be fast to perform on a computer. From a security perspective, it should be hard for the attacker if they know the ciphertext C, they know the public key B, a PUB, it should be hard for them to determine the private key. If we can find someone else's private key, it's no longer secure because it's no longer considered private. So that algorithm must be such that it's practically impossible for an attacker to determine the other key in the key pair, the private key in particular. In RSA, is that true? If you know someone's public key with RSA, can you find their private key? Yes, what makes it hard? What's the problems that make it hard with RSA? That's one of the exam questions. Factoring, so if we know the public key like E and N, we need to find D, D's the private value. And to find D, well, we need to know the totion of N because E times D mod the totion of N is one. So if we know the totion of N, we can find D. What's the problem with finding the totion of N? For large N, if you manually need to calculate the totion of N, it takes a long time. There's no known algorithms that can do it fast. The other way, the shortcut is to factor N into P and Q and then calculate the totion of N quickly. Again, factoring a large number into its two primes is practically impossible to do if those numbers are large enough. So that's why RSA is designed like that. If the attacker knows the public key, the E value, even they know the ciphertext, they can't find the private key. Similar, if you know the public key, you know the ciphertext, you shouldn't be able to find the message M. And similar, if you can find the private key, you can find M. Well, if you can't find the private key, how do you find M? With RSA, you could try to do the discrete logarithm, the inverse of the raise to the power. But again, solving discrete logarithms takes too much time. Some algorithms would like to be able to use the keys in either order. If we encrypt with, what do we get? If we encrypt with the private key, we can decrypt with the public key. Or the other way, if we encrypt with the public key, we can decrypt with the private key. That's all that's saying, that some algorithms support this feature that you can swap the ordering of the keys. You can use one to encrypt, the other to decrypt, or vice versa. Let's see what we can say. I think we'll not talk about this slide. What algorithms meet these requirements? RSA is one, there are others. In general, they are called trapdoor one-way functions. A one-way function, it's easy to calculate in one direction, but it's practically impossible to go the inverse. That's a one-way function. A hash function is commonly considered a one-way function. We can calculate the normal operation, but we can't do the inverse. A trapdoor one-way function is the same, except there's a special case, there's a trapdoor. We can calculate in one direction. We can't calculate the inverse unless we know a secret, unless we know where the trapdoor is. That's the concept. And the secret would be, say, the private key. Maybe these three equations cover the main point here. We need a function such that if we take some input x and we have some function that takes a key k, it's easy to calculate that function on x. It's easy to do the inverse of that function. If we know that key k, it's practically impossible to do the inverse of the function if we don't know k. That's the idea. It's easy to calculate the function. It's easy to calculate the inverse if we know the key. It's hard to calculate the inverse if we don't know the key. And that's what we require of all our public key crypto algorithms and RSA has that feature. It's easy to encrypt. It's easy to decrypt if we know the private key. It's hard to decrypt if we don't know the private key. That's the idea there. But rather than talk generally, let's go to some specific examples. The specific example is RSA, but first last slide before that. How do we attack public key algorithms? Brute force attacks are possible. The approach, if there's some private or secret key, then try and guess the key. How do we stop brute force attacks? Make the key large. We know that concept. If the key is large enough, a brute force attack is not possible in practice. The problem with public key algorithms, it turns out, is that the larger the key, the slower they are. If we use a very large key, a brute force attack is not possible, but it takes slower to encrypt and decrypt. So there's a trade-off between security and performance. And in practice, public key algorithms are so slow compared to symmetric key algorithms such that they're commonly not used for encrypting large messages. It's better to use AES. So they're only used for encrypting small things, because even though they're slow, it doesn't take so long to encrypt something small. So encrypting signatures and encrypting other keys, we'll see examples of. So to stop a brute force attack, use a large key. Try to determine the private key from the public key. I give you my public key, go and find my private key. Well, the algorithm should be such that it takes too long to do that. And for RSA, we know that involves solving problems like factoring numbers into its primes, calculating the atotian, or calculating discrete logarithms. And all of those problems, if the numbers are large enough, take too much time to solve. And other algorithms use similar concepts. They have mathematical problems, which are hard to solve in reasonable time. There's a special type of attack called a probable message attack. Try all possible values of the message. And once you find one that produces the known ciphertext, you've found the key. In terms of RSA, which we know, that's the concept with RSA. We know the algorithms, just to remind us, that's one way we write RSA algorithm. Consider the first equation. The attacker knows some ciphertext. They know n, n is public. And they know e. They don't know m, a probable message attack. In the worst case, involves try different values of m. That is, try some m1 raised to the power of e, which is known, mod by n. And you get some c value that says c1. If c1 matches the known ciphertext, then we've found m1. We've found the message. If it doesn't match, try another message. And keep going until you find a message where cx equals the known ciphertext value. c1 not equal to c. So that's the idea. Just try all possible messages. If we know the message is of particular length, then we know how many we need to try. In RSA, how long is a message? Have a look at your lecture notes. Look at the definition of RSA. How long is a message? What's the maximum length? Find the slide that defines RSA, the RSA algorithm. How large can m be? m must be less than n in RSA. When we take m to the power of e, mod n, the assumption is m is less than n. So there's a fixed size of the message in RSA. If n is a 2,000-bit number, then m must be a 2,000-bit number or smaller. So for the probable message attack, how many possible values of m are there? Two to the power of 2,000 bits, or two to the power of 2,000. Well, that would take too long. But we know that the messages should not be random messages. They should have some structure. So we could try some structured messages. And if the actual m was small enough, then the attacker could find the right m. So there is a problem in that if m, the message, is small, the attacker can just try many, many values until they get the right one. They keep trying different values of m until they get the right one. Then they've found the plain text. How do we stop that? Add some random bits to make the message longer. Make sure the message is not small. Even if you do have a small message, the implementations of RSA would pad it out. Add some random bits such that the attacker cannot find that they need to try many possible values. So it's easy to solve such an attack or defeat such an attack, but the implementations need to handle that case. In many cases, m is short. Let's say I want to send a secret value to someone, that secret may be quite short. So it may be possible. Therefore, it's important to consider padding it out. So that's the general requirements of public key cryptography. But we already know one specific algorithm and it's the RSA algorithm by Ravesh Jamir and Adelman. So a couple of years after Diffie Hellman published their algorithm, which we'll see shortly, RSA published this one. And this one became very popular because it was well suited for digital signatures and encrypting general data. Whereas Diffie Hellman was only for signing, exchanging secrets. So this became very popular and they created a company, RSA Security, and the remnants of that company is still around. The company had many different products. One of them that they used, the RSA algorithm was for signing web pages. The certificates attached to websites commonly use RSA as the algorithm. And there were companies that spun out of the RSA security that distributed certificates. And it's probably the most widely used algorithm, even though there are others now that are considered just as good. We know the algorithm. We know how to encrypt and decrypt. We've done many examples or you've done some study for the exam. We generate a key. One of the exam questions, which was prove that the encrypt and decrypt work. What does my mean by work? If we apply this encryption algorithm and we get some ciphertext and then we apply the decryption algorithm, will we get the correct plaintext back? So let's consider that. Let's go through that proof. Prove that the decryption works. Prove that when we decrypt, we always get the original m back. It's not too hard to show that. So let's repeat again what we know with RSA. RSA encrypt c equals m to the power of e mod n and RSA decrypt. The question is if I encrypt some message m, I choose a random m and then I decrypt the ciphertext, will I get the same m back? Well, we must for it to be useful. Why do we always get that? Or under what conditions? First, let's try an example. Let's not prove, but try an example. Let's say, and let's forget about our key generation. Let's just try for any numbers. Let's say if we used m of five, e of, I've got these numbers from before, e of 17 and d of four, n of 21. So we encrypt c equals m to the power of e mod by 21. Five to the power of 17 mod 21. My calculator, my graphical calculator sometimes doesn't handle very large numbers. It will handle these numbers, but we'll use another one. You may notice in the exam, your calculator may not handle very large numbers. It's a bit of a problem. So the calculators we normally use have limits. So what we need is a calculator that has no limits called an arbitration, precision calculator. There's no limits on how precise it is. The only limit is how long it will take to find the answer. BC is a program I have on my computer that is an arbitrary precision calculator. In this case, what do we want? Five to the power of 17 mod 21. The answer is 17. I think it's a coincidence that it's the e, same value of the e. That's maybe a bad example. So we just encrypt m, we get c. Now let's decrypt. I'll say m prime, the decrypted value. We want it to be the same as m for this algorithm to work. Let's see what it is. Is c to the power of d mod n. And using our calculator, 17 to the power of four mod 21. What do you think we'll get? Four. Does the decryptor value equal the original value? No, there's a problem. So the point is that these encrypt and decrypt algorithms don't work for any possible values. Only certain values it will work for. Here I chose some random e and d and n. I didn't generate them according to the key generation algorithm. And if we choose any value of e and d, then it's possible that we encrypt the plain text, we get cipher text, and then we decrypt, we will not get the original plain text. And that's useless for encryption. So the question is, under what conditions do we always get the original m back? When does m prime or equal m? When does the decrypted value equal the original value? And I think from the key generation steps, you'll have an idea. Let's see how to prove it. What is m prime? The general equation, the decrypted value, we take c raised to the power of d mod by n. What is c? Well, we know c is m to the power of e mod n. So let's substitute for c. I just replace c with the encrypt algorithm. Can we simplify? Note the mod n, it's inside the brackets, raised to the power of d. We can take it out, because we mod by n at the end. Remember the concept, if I have 10 mod eight, it equals two. Two mod eight equals two. If we keep modding by eight, we'll still get the same answer two. So here this mod n inside the brackets can come out and in fact we just need one mod n at the end. Your normal properties of exponential means that's m to the power of e times d mod n. n to the power of e to the power of d is the same as m to the power of e times d. A normal property of exponentials. So we end up with this equation. m prime equals m to the power of e times d mod n. Our question is, when does m prime equal m? We take some number, any number, it's gonna be less than n, but any integer, raise it to the power of something, mod by n and we must get that original integer back. Why? Not quite. What if, all right, a special case, I think you're on track though, what if e and d were one? That would be true, wouldn't it? If e and d were one, but that's not a very useful scenario when e and d are always one. We want e and d to be any particular value or to be some large values potentially. Look at formats and Euler's theorem. If you go back to the number theory lecture notes, you'll see Euler's theorem says that a is the same as a to the power of the totion of n plus one mod n. If you remember Euler's theorem, and it was in the exam, you see that it tells us this. Some number a equals that same number to the power of something mod n. Well, that's similar to what we have here. We want some number m to be equal to that same number to the power of something mod n. So if our equation for m matches the form of Euler's theorem, then we can meet the conditions. Euler's theorem that tells us that a will always equal a to the power of totion of n plus one mod n. So to have our equation for m in this form, m, a, m, a, mod n, mod n, E d must equal the totion of n plus one. If E d equals the totion of n plus one, then this equation matches Euler's theorem. m equals m to the power of the totion of n plus one mod n. So the condition is that this must be true. When does m prime equal m? When E d equals the totion of n plus one. So that sets our condition for E and D. We can't choose any E and D. We must choose an E and D such that we multiply them together, we get the totion of n plus one. Of course, this was in the midterm exam. There's no problem with me repeating questions from the midterm exam and the final exam, okay? Because no one got it correct. Maybe we should have another try at this in the final exam or something similar. So it's useful to know these approaches. Another way to write this, if we mod by the totion of n, what does the right side become? So totion of n plus one, mod by the totion of n, the remainder will always be one. So another way to write that, E d mod the totion of n equals one. Or let's write it in full equals one. Sorry, there's a mistake there. Mod the totion of n. If we mod both sides by the totion of n, then we get E d mod the totion of n equals one. Now this looks familiar to us. This is how the key generation steps for RSA had arrived. Or E and D are multiplicative inverses in the totion of n. Multiplicative inverse of D equals E when we mod by the totion of n. That's all it means. Multiplicative inverse. We time some together and we get one. When does a number have a multiplicative inverse? When does a number have a multiplicative inverse? In the mod, the totion of n? Yes, but and so we know not all numbers have a multiplicative inverse when they're relatively prime to the modulus. So if E is relatively prime with the totion of n, it will have an inverse relatively. And in fact that derives the key generation steps for RSA. We know if we choose some E which is relatively prime with the totion of n, then we can find some D which is the inverse of E. And if we have E and D are multiplicative inverses of each other in the totion of n, then it holds that E D equals the totion of n plus one. And if E D equals the totion of n plus one, then it means that this equation, if E D equals the totion of n plus one, this equation is in the form of Euler's theorem. And that means we will always get the original message M back. So this is a proof that RSA decryption works and it sets out the conditions for E and D especially. And that's how the key generation steps are derived. As a practical, as a way of making, calculating the totion of n easy, we choose n to be multiplication of two primes such that the totion of n is easy to calculate. And that gives us the key generation algorithm for RSA. So RSAs were designed such that when we decrypt, we'll always get the correct plaintext back. We've worked backwards to see why it's designed that way. Some students, not many, some students have solved this in past years. So it's a nice thing to see that RSA, you can fully understand all the steps if you can solve this. Let's return to our slides in the last five or 10 minutes, talk about the characteristics of RSA and then after the break, we'll look at another algorithm, Diffie-Hellman. So that's the requirements of RSA. We've gone through examples before. What about implementing RSA? There are different implementations and one of the problems with RSA is the speed of doing encryption and decryption. Especially decryption. C, which may be a large number, raised to the power of D. D is the private value. Should D be small or large? Should D be small or large? Large, because? That's fine. Hard to find. D is a secret value and it turns out it's a small number. Well, what an attacker could try to do is just try many values. So it should be a large number, D. And C, the ciphertext may be a large value, less than N. So we have a problem with performance. Take a large number, raise it to the power of another large number. What do you get? One large number raised to the power of another large number, you get extremely large number. And it takes a long time to calculate that. And then mod by N. So there are some optimizations that try to, instead of take one very large number, raise to the power of another very large number, they split it into two steps, such that we have a smaller number raised to the power of a smaller number, but we do it again. So there are some optimizations that do the same thing, but speed up the performance. In your homework, I think you'll see one performance optimization, okay? So I'll show you an example of the values later, but you'll see the actual algorithm for doing an optimization of that. You'll study the algorithm. Gives the same result, but it's a little bit faster, or a lot faster, in fact. So regarding the performance of RSA, encryption and encryption require explanation, very slow with large numbers. There are some optimizations that can be used to improve that. And many implementations use those optimizations. What about E? E is the public value. And normally what we do is we can choose a small value of E, such that the multiplicative inverse D is very large. So it's common that E is small, such that D is large. And it turns out that with E, we don't need to use a different number all the time. You have a value of E, I have a value of E. We could have different values, but many algorithms or implementations will use the same value. And some common values are three, although not recommended anymore, but 17 and 65537. It turns out they are numbers which make it easy to do some calculations quickly. And when you use OpenSSL to encrypt with RSA, by default it uses 65537. So everyone who uses the default values will have the same value of E. But it doesn't matter if your E is the same as someone else's because it's public. So E is usually a fixed value. All people have the same value. A small value has some possibility of attack as long as you pad M such that M is not small and it's okay. What about D? D should be large. We said that so no one can guess it, but making it large makes decryption very slow. So that's the problem. There are some algorithms to speed that up. P and Q, P and Q must be large and of course primes. To calculate the totion of N, we need two large primes, P and Q. Generally they're choosing or generated and using some algorithm tests to see if they are primes. But be aware RSA is slow compared to other algorithms. Last, the security of RSA, so that was about the performance. Brute force attacks. Well, the attacker tries to guess the private value D. Therefore choose a large D to make a brute force attack not possible. Generally D is about the same length as N. It turns out. I'll give you some values in a moment how long they are. The mathematical attacks we know from our exam and from our previous study the ways the attacker can use factor N into its two primes, determine the totion of N directly without knowing P or Q or do a discrete logarithm, find D without knowing the totion of N. So a discrete logarithm, the totion and factoring a number in its two primes. Of those mathematical problems, the one that's considered the easiest is factoring. That's considered the easiest. So since that's the easiest, that's the approach the attacker would take if they want to defeat RSA. So the measure of RSA security mainly depends on how fast we can factor numbers into primes. And the next slide gives a couple of examples. They're a bit old because it's not so interesting anymore, but some of the records, there used to be a competition where you'd win thousands or tens of thousands of dollars if you could take a prime, a large N and factor into its primes P and Q. And in 2009, the winner or the best, they could take a value of N which was 768 bits. If you wrote it down, it's 232 digits, zeros or nines. Very long number. It took them about 2,000 years to factor that into P and Q. They didn't spend 2,000 years doing it. They had many computers doing it in parallel. But effectively, if you used a single computer at that stage, it would take 2,000 years. So they could use 2,000 computers and do it in one year in practice. So that was the best in 2009. Things have sped up. The algorithms have been improved and the computer speeds have improved. Nowadays, 1,024 bits is considered maybe insecure. There are no attacks that have defeated at 1,024-bit value, but people think, well, 1,024 bits, maybe current computing speeds are approaching the limit where they can factor 1,024-bit number into its primes. So the recommended value nowadays is 2,048 bits. This is the length of N, the value of N, the recommended value 2,048 bits, and there are no techniques for factoring such a large number into its primes P and Q. So that's the length of the numbers we're talking about. Thousands of bits. There are other attacks. Correct. This is the value of N. So in RSA, there are three common values used, 1,024, 2,048, 4,096. Some people still use 1,024, but maybe in the future, that may not be considered secure. So recommended to use 2,048. Correct. Well, it's not so hard to publish. We just write the 300 digits down and put it in a file. And you'll see maybe after the break I'll show some examples of those values, the N value. When you access websites with HTTPS, usually the web server sends you their value of N. Okay, so it's just sent in a file. Yes, it's hard for us to manage and distribute, but we use the values and usually using some protocol or some file to distribute the value. I'll show you some examples after we have a break. Let's stop there, have a break, and we'll look at some examples of RSA and then we'll look at another algorithm, Diffie-Helman.