 So, with single desks, the key size is effectively 56 bits, so brute force attack is possible. So, since we have a lot of, or at that time, there's a lot of software and hardware invested in implementations of desks, the idea, one idea is to use double desks, encrypt twice, but each time you encrypt using single desks, use a different key. So, we'd think that that, well, that doubles the key size. So, now the key size is effectively 112 bits, so a brute force attack is on the order of two to the power of 112 operations, which is much more stronger. But there's a weakness, and the weakness comes from the meat in the middle attack. And we tried to go through an example, not on desks and double desks, but on our example cipher. So, we had an example cipher, just a small block cipher with just five-bit blocks, and we used a three-bit key, and we said that with a single version of that cipher, ABC, normally it takes a three-bit key, so a brute force attack takes two to the power of three operations. The double version of that cipher, what we do is we encrypt using that cipher, the plain text, using K1, so there are two to the power of three possible values of K1, and then we encrypt the output of that first encryption again using the same cipher, using another key, K2. So, in effect, using the double version of this cipher, ABC, means a brute force attack requires two to the power of two times three, okay? Two to the power of, and the exponent is two times the number of bits of the single cipher key. So, two to the power of two times three, or two to the power of six operations. So, the equivalent we think with single desks, two to the power of 56, double desks, two to the power of 112 for a brute force attack. But the meat in the middle attack makes it simpler against the double version. So, we went through the case, and the steps we went through were, given that the attacker knew a plain text cipher text pair, P1C1, so here's a known plain text attack. The attacker knows more than just existing cipher text. They also know at least one pair, and typically they need to know two pairs of plain text cipher text. So, P1 and C1 are known by the attacker, and what they do, the steps of the attack is that they take P1, the known plain text, and they encrypt it using all possible values of K1. In our simple version, it was all eight keys, three bit key. We try and encrypt P1 using each value of K1, and that's what we come up with these eight values of output here, these x values. Which is just from the encryption. Then the second step of the attack is that we take this corresponding cipher text, C1, and we take that cipher text and decrypt with the eight possible values of the key K2. So, going backwards really, and we get another eight x values. And it must be, if we've got the correct key, that is the correct values of K1 and K2, it must be that the value that's output from encrypting P1, one of those x values, matches one of the x values obtained from encrypting or from decrypting C1. And in fact, in our example, we found three matching pairs. Which told us that there are three possible values of K1 and K2. The ones which lead to those matching pairs. And we ended up with those three possible values. Now, the attacker needs to select which of those three is the correct one. And we need more information to do that. So the attacker actually needed to know in this case, a second pair of plain text cipher text, P2, C2. And all we do is we can check of those three values, three potential keys, these three. Check whether they work for our second pair of plain text cipher text. And we checked through them, we did them quite quickly at the end of the lecture and we found that the first one works, the other two don't work. Don't work in terms of if we encrypt 1 1 0 0 1 with say K 1 0 1 1. Take the output and then encrypt it with K 2 1 1 1. We do not get the corresponding cipher text. That tells us that that potential key pair is wrong. And as a result the attacker finds the values of K 1 and K 2 or the six bit key. So let's go back and just summarize the concepts and apply them to real desks. But one thing that maybe is not clear to people is why do we give these x values? Why are they the same? Well, it's easy to check by seeing what the normal user would have done to obtain the cipher text. And I will not waste too much time with looking up our table. I think you have it in front of you, the one with the encryption. But if you look at what the normal user would have done to obtain the cipher text with P1, we had, I've done it before. So we had a value of 0 1 1 0 1. And the normal user, the one that did the encryption knows the key. And they know that K 1 is 0 0 1. And when we encrypt P 1 with K 1, we get some x value, some intermediate value. I just not label it x so we can refer to it. And if you look up your table, you'll see the value is 0 0 1 1 1. And then with the double version of our cipher, we take that x value, that value and we apply the second key, K 2, which in our case was 1 0 0. And again, you get the output from the table. So you look up and you, if you look up those rows, you'll find the output cipher text 1 1 1 1. That's how P1 and C1 were obtained by the normal user. Now, let's try the other way. Let's say that this was the encryption. What about the person who receives the cipher text and they want to decrypt? They receive that cipher text 1 1 1 1 1. And again, assume they know the key. So which key do they use first to decrypt? You would use K 2. That's shown here where we encrypt using K 1 and K 2. To decrypt, we take the cipher text and decrypt using K 2 and then K 1. Let's do that. So we just did the step of what the normal user would do to encrypt. Now let's do the step of what the receiver would do to decrypt. We take the received cipher text. We know the key, K 2 is the same as the original value. If you look up the tables, can someone look it up? You have it in front of you. I don't. Decrypt 1 1 1 1 5 1s with key 1 0 0. What do you get? Decrypt. Be careful. Decrypt. Let me bring up the table. This table. We have the cipher text of all 1s using the key 1 0 0 1 0 0. This column, look for the cipher text. Where is it? You can see it, I cannot. Is it down or up? Up, up there, we found it. Okay, so the decrypting going backwards, remember. So be careful there. So if we have the cipher text 5 1s, we use this key 1 0 0. The plain text, the result of decryption 0 0 1 1 1. This intermediate value, X, then we decrypt that. We take that X value and use K1 and look it up. So the column for K1 0 0 1, the input is 0 0 1 1 1. What do we get out? You should get that value. If not, something's gone wrong. What's the point? This is what the encryptor does when they know the key. They get an intermediate value, this X here. And the decryptor, when they also know the key, they get an intermediate value, it is the same. It must be the same, okay? So that's what the meet in the middle attack takes advantage of. That if you go from one direction in one step, you get this intermediate value X. If you decrypt also for the cipher text using the other key, you also get the exact same value of X. So that's just showing that this intermediate value, when we encrypt or decrypt, is always the same. You can try it with other pairs of plain text, cipher text. So what the attack does then is finds the values of X which are the same because of those, one of them must be the correct one. The one which uses the correct values of K1 and K2. It turns out there may be more than one. As we saw, we got three. So when there's more than one, what we need to do is try another pair on just those three. And the one that produces the correct cipher text, given those three possible keys, tells us the correct key. And the point was to cut down on the number of operations to make the attack faster. And we tried to count in this case. In the first step, we encrypted two to the power of three times, two to the power of three operations, that is for all possible keys. In the second step, we went through and did another two to the power of three possible operations, in this case, decrypt operations. And there were a couple more steps down the bottom, I think, three more or actually six more attempts of just confirming those keys, another six operations. So in our example, we went through two to the power of three plus two to the power of three, plus another six operations, totaling 22. Brute force, if we did it that way, would have took us 64 operations. So yes, our attack is faster. If we extend that concept to desk, double desk would take two to the power of 112 if we did brute force. Using the meat in the middle attack, it turns out that it's approximately two to the power of 56 for the first set of encryptions, two to the power of 56 for the second, plus a few more. And the few more that we need to do is very, very small compared to two to the power of 56. So in fact, it's very small, there's plus a few more here. So we typically approximate that to two to the power of 56 plus two to the power of 56, two to the power of 57. That is, using the meat in the middle attack, the number of operations an attacker needs to break this cipher is about double what is needed for single desk. Single desk is two to the power of 56, meat in the middle attack on double desk is two to the power of 57. Doubling is not a good improvement in security. It just doubles the cost, which is usually trivial to make up. So the meat in the middle attack because of that, double desk is not much stronger than single desk. So it doesn't gain us much. There are some details which we will not try to explain too much. With double desk, it turns out you don't have to do all of these decryptions in some cases. As soon as you find a match, you may try on a second pair and if you get a second match, then you assume it's the right key. That is, there are ways to optimize, but normally you need to do two to the power of 56 operations and up to another two to the power of 56. So we say it's about twice as good as single desk, which is not very good at all. So this is an example of a crypt analysis. It's not brute force, it's improved upon brute force. What are the problems with this attack? Compared to brute force, it's faster than brute force, but what are the negatives? So the attack, if we do the attack, we'll get to the solution before then using brute force. So that's a good thing, but there are some problems with this attack. We need the pair of plain text, cipher text. In our attack, in our simpler case, we had P1C1, so the attacker needed to know that first pair and in fact the second pair. And in real attacks on desk, double desk, again generally the attacker needs to know two pairs of plain text, cipher text. So this is a known plain text attack, so the attacker needs to know a little bit more information than normal. But knowing two pairs is not too hard. So that's one minor thing, but in practice it's not a big issue. What else is a problem with this attack? So we care about the speed. This one was faster than brute force. We care about what the attacker needs to know. This one required the attacker to know two pairs, which is not a big problem in most cases. And we care about one more thing when we're doing an attack. Can anyone see what's the problem here? The other thing is memory or storage. When doing the attack, in our case, the attacker stored or calculated eight values of x. Then what they do is they go in the decrypt operation going from the cipher text C1 and decrypting and really what they can do is compare these values they get with this existing eight values. To do that, we must store these eight values. So what we do is that we find this value of x, x21, compare it to our eight values. If it matches, then keep note of that. If not, try the next one and so on. So the problem with this attack is we need to store at least these eight values. In desk, how many values do we need to store? Here we need to store two to the power of three values of five bits long. In desk, two to the power of 56 values of 64 bits long or eight bytes. Two to the power of 56 times eight bytes is how much storage space we need. How many terabytes? I think it's about 500,000 terabytes are needed. Okay, so the storage is the trade-off that we make in this attack. It's faster, assuming we have a large space to store it. There are some ways to get around that that trade-off that make it slower but use less storage. But in general, with any crypt analysis, the attacks consider those three performance metrics. Speed, you want the attack to be fast. Known information, we'd like the attack to be successful without the attacker knowing any extra information. In this case, we needed to know an extra pair or two pairs of plain text, hypertext and memory. That is how much we need to store when we're performing the attack. In a brute force attack, storage is almost zero. We just do it and throw away the old values. In this attack, storage requirements are on the order of two to the power of 56, which is quite large in practice. So when people compare different attacks and compare ciphers, they usually compare by those three metrics. And that finishes our analysis of the meet in the middle attack. Questions on our example before we return to our slides. There have been quiz questions, exam questions about perform a meet in the middle attack on some simple cipher, okay? So given that table you have in front of you or a smaller table, go through the steps of okay, encrypt the known plain text and then start decrypting the known corresponding cipher text and see when you get a match. This, the slides, this explains the algorithm, okay? So we've gone through the example of applying this meet in the middle attack. So this just explains the algorithm for double desks. You need about, well you need normally two known plain text cipher text pairs. If you have two, then that's with very high probability enough to be successful with the attack. It requires about twice as many operations as single desks but a lot more memory. So how do we improve? Not double desks, triple desks. And there are variations of triple desks. The one we see here, triple in terms of three operations. Take our plain text, encrypt, take the intermediate value, say A, decrypt. It could have been encrypt here as well. We'll explain why it's D but apply the operation again and get an intermediate value B and apply the operation again and you get the cipher text. And to decrypt, you go the same operations but you use the keys in opposite order. So apply three operations of desks instead of two. This is called triple desks or triple encryption. There are some variations of it. You can either use two keys, like in this picture, K1 and K2 and in the second operation use K1 again. Gives us an effective key size of 112 bits. So two desk keys, we mean here. Or you can use three different keys, not shown, but it will be K1, K2, K3. Three by 56 is 168 bits. So there were two options that you could choose from depending upon what key length you wanted. And it is not subject to the exact same meet in the middle attack because you see there's no, if we take our known plain text, we get some intermediate value A. If we take the corresponding known cipher text and decrypt, we get a different intermediate value B. Whereas with double desks, they were the same, the same values of X. So there are extensions of the meet in the middle attack but it improves the security significantly and it's commonly used or commonly was used. It's maybe still available today but there are considered better alternatives. It could have been EE, encrypt, encrypt, encrypt but in practice sometimes it's used encrypt, decrypt, encrypt just so it's compatible with single desks. To get single desks out of this, just use the same key. Encrypt with K1, decrypt with K1 and you get your original plain text. Encrypt with K1 and you get the same output as if you use single desks. So it's just a compatibility feature to have encrypt, decrypt, encrypt. It could have been encrypt, encrypt, encrypt as well. So triple desks is considered secure nowadays. What's the problem with triple desks? Speed, it's three times slower than single desks and in fact single desks wasn't designed for some hardware and software systems so single desks was not very fast compared to other ciphers. So this is three times slower than single desks. And the NIST, National Institute of Standards and Technology in the US in the 1990s started to develop a new standard for encryption and they had some really competition where different researchers submitted their algorithms for this new standard and one called Reindahl was chosen as the winner in 2001 and that's called the Advanced Encryption Standard, AES. And this is widely used today. Many of the software that you use to encrypt is likely using AES. It uses a block size of 128 bits. Desk use 64-bit blocks, this uses 128 bits. It allows three different key sizes. So depending on what security you want, you want normal, 128 bits, you want ultra-paranoid, 256 bits. And relating to the key, it uses different rounds. We'll not go through the operation, but it uses rounds in the same way as desks and it uses S-boxes, exclusive or and some other operations to do the encryption. Very widely used, generally considered secure today, no known attacks, but we will not go through the details. We've gone enough through desks as one example of a real block cipher. And there are others. Okay, so this lists some names of some common ones you may come across if you see different encryption software. So others, and they differ maybe in terms of the blocks that they operate on, usually 64 or 128 bits. The key sizes they accept and the design approach. Fistal structure was what desks use. Some use a slightly different approach, but there are others and they have advantages and disadvantages like speed, whether they are restrictions on patents and being able to implement and some security advantages. What we want to finish this topic on is some further analysis of brute force attacks and other types of attacks. But before we do so, let's encrypt something just to show you in practice what happens. I'm gonna use some software just to encrypt a file, just to illustrate and then we'll use that same software to give some indicator of the speed it takes or the time it takes to encrypt. With brute force attacks, the time it takes to do a brute force attack depends upon two things. How many keys you need to try and how long it takes to try one key, which is really your computer speed. So we'll do some encryption. I'll just demonstrate some quick encryption and then we'll give an indicator of how long it takes my computer to encrypt or decrypt and then generalize that to other systems. The instructions or the commands I'm gonna go through, you have, again, I hope, in one of the printouts and it's on a website if you wanna look. It's called demo of symmetric key encryption using OpenSSL. You may have to keep scrolling through forward. I hope so. Go back. Is there another one? Maybe. Anyone find it? There's another printout in there that is called simple example of, maybe I included a different one. You might be okay. If it's not there, then you have one which is maybe just, you have this one, simple introduction to using OpenSSL on the command line, okay? Two slightly different ones. OpenSSL is some encryption software. It is primarily used as a library by other software to do encryption. That is it provides a set of encryption operations and other security operations and when you write your software, you can include the OpenSSL library so you don't need to encrypt or you don't need to implement your own encryption. You just use OpenSSL. It can also be used as a standalone program to encrypt things and that's what I'll use just to demonstrate. There are other libraries. This is just one that's widely used. But don't worry too much about following on in your notes. I'll just demonstrate and just, you'll have a chance as one of your homeworks to do this yourself. Let's do some symmetric key encryption first. First I'm going to get some plain text and I'm gonna copy and paste some of the commands to save on typing. Here's my plain text message I'm going to encrypt. So my file, I just have a message in a file. We'll actually encrypt the file which is encrypting the contents of the file. How big is the plain text? The plain text is 72 bytes. Okay, we're gonna use DES to encrypt. How many blocks do we have? Remember DES operates on a block at a time. How many blocks? What's the block size used by DES? DES uses 64 bits at a time. So 64 bits is equivalent to eight bytes. We have 72 bytes to encrypt. So we have nine blocks to encrypt. Okay, so our plain text is nine blocks long. So the normal or not the normal way, the basic way to apply our encryption cipher when we have input which is larger than the block size is to encrypt one block, get some cipher text, encrypt the next block, get some cipher text, and at the end, those output cipher text values just join them together, concatenate them together to get the resulting cipher text. To visualize that, what we're gonna do is we have our plain text P as input and we can think P is broken into nine blocks. P1, concatenated with P2, concatenated with P3. The double bars here means concatenation or joined and we keep going and up to P9 in our example, nine blocks of 64 bits. Remember DES takes 64 bits at a time or eight bytes. We're gonna use DES, 64 bits per block. So the way that we'll encrypt this nine blocks is that we'll apply DES on, we'll have a key. We'll apply DES using that key as an input and the plain text P1 as an input and we'll get C1 as output. So this is the encryption block and then what we do is we use the same key with the second block of plain text. Encrypt with DES again, we'll get C2 as output and what comes in here is the same key. And we do that for each of our nine blocks of plain text input and we'll get nine blocks of cipher text out and in this simple example which we'll use, we'll just concatenate the nine blocks of cipher text. Join them together and that will be our resulting cipher text. There are other ways to combine the outputs of the encryption for each input plain text block and we'll see them in the next topic. They're called modes of operation. This is the basic one but we'll see this as a flaw in a moment. So the cipher text is made up of nine blocks of component cipher text. We can look at the plain text before we encrypt it just to compare. How do we convert our plain text to an input that DES will support? DES takes 64 bits, what do we have as plain text? Some English letters, how do we convert them? What's the name of the system we use to convert English letters or any letters usually or English letters to bits? ASCII, okay so the ASCII encoding tells us that usually each English letter is mapped to a eight bit value, one byte per letter. But remember DES just treats it as a sequence of bits, he doesn't understand that they're letters. XXD just shows us that plain text but in this case in hexadecimal form. So the letter H corresponds to what, four eight in hexadecimal or even in binary we can have a look. It doesn't fit so well, come out again. There we go. There's the binary that we're going to encrypt, okay? So from DES's perspective the first eight bits which represent in our case the uppercase H are these eight bits, which is whatever it is, 172 or something. And then we need to, so DES will take each block of 64 bits encrypt and produce 64 bits as output and we'll have a look in a moment. With DES we need of course the plain text as input and what else do we need as input? A key, how am I gonna choose a key? It should be random, okay? We shouldn't just choose our favorite number and convert it to binary. We should choose a random key. So we need a random number generator and we'll see with one of the later topics generating random numbers is not easy as well. Of course we've got software to do it but some software is better than others. I'm also gonna use OpenSSL to generate a random eight byte value. I'll do it in hex. There's our key but in hexadecimal. Remember DES takes a 64 bit key although it only uses 56 bits. We still need the 64 bits. The other eight bits are used for a parity check but we need a 64 bit input. So I generated an eight byte random number but instead of printing it in binary I printed it in hex because we can use that and the software will convert the hexadecimal value to binary. There's my key. To do this joining of the ciphertext blocks together we use what's called a mode of operation and that's our next topic and we'll see when we get to that next topic that that mode usually has an extra parameter. Something that initializes these steps. A vector that initializes it called an IV and initialization vector. And we'll discuss that later when we look at modes of operation but for this encryption we need to specify what value we'll use and we'll use a random value. I'm going to generate a second random number. The first one is my key. The second one is what we'll call the initialization vector to initialize the combining of the blocks. It becomes important with other algorithms. Now let's encrypt. OpenSSL is the software. The function we're going to use is encrypt and we're going to specify the algorithm DES and we specify the mode in which we'll use this algorithm and again, this is a bit ahead of the next topic but the mode we are going to use is the simplest mode called electronic code book. We'll come back to that. It's this mode of concatenate the ciphertext on output. That's all it means. Minus e for encrypt. If we wanted to decrypt, we'd do the same but minus d. Our input is the plaintext file. The output, let's call it something. Some ciphertext file and we need two other inputs. Minus k for the key so I'll just copy and paste. So we have a key as input as well as an initialization vector, the second random number. So again, you don't need to know them yet but ECB initialization vector come up in the next topic. IV initializes the algorithm that specifies how to combine each block when we encrypt the input plaintext blocks. In this case, it's very simple. How to combine is just concatenate but in other more secure algorithms, the way to combine the output of encrypting each plaintext requires some initialization to get started, some first value. It's not needed in this case but we must specify it for the software to work. It'll make more sense in the next topic. Usually when we encrypt something, the software will add some padding if necessary and the padding has two purposes. The padding is to fill out the plaintext to be the right size with respect to the blocks. In our case, we're okay. We've got exactly a multiple of 64 bits in our plaintext but of course you may have a plaintext which is not exactly a multiple of 64 bits so padding would add some characters at the end. Padding can also be used to introduce some error checking so we can add an error detection code inside such that when we decrypt, we can automatically check if what we obtain is correct or not. To avoid all that detail, I'm gonna say no padding. Usually we would not use that but we'll see why it's useful in a moment. That's it. Seems complex but specify that we wanna use des, encrypt our plaintext, obtain some ciphertext using this key, this random key and we do it. And it's done. The ciphertext file, the output is also 72 bytes, that's what we expect. 72 bytes in, 72 bytes out. Let's have a look at the ciphertext. What do you expect to see? Random, there it is. You can look at the hexadecimal and see if you see any pattern in here or look at the ASCII representation. Where it has a dot, it means it's a non-printable character of the ASCII characters some are not printable such as the control characters. You cannot print a control character in a single character. Delete, for example, how do you print delete? So it's random. There's our ciphertext, all right? Hopefully Des did what we expected there, encrypted and produced our nine blocks of ciphertext and joined them together. Is it random? Look closely. That's a hint that it's not random. Where's the pattern if it's not random? Look at the rows, maybe a further hint. So we said that there were nine blocks of 64 bits or eight bytes, eight bytes. Two hexadecimal digits is one byte. So in fact, it turns out one row is one block. One, two, three, four, five, six, seven, eight bytes. Two hex digits is one byte. So this first row represents the first block that comes out, C1. The second row is C2 and the last row is C9. The first characters here just tell us the position. It's not a part of the output, it's just showing the position. Can anyone see the pattern? Yes, good. Can you show me the pattern or tell me where it is? Six F E eight zero B C six. Here, the fourth row and in the seventh row, six F E eight zero B C six. If you look at those values, within them they appear random. There's no pattern there, but now we compare it to this seventh block and we see it's exactly the same. That's very, very, very, very unlikely. If you have random characters here. So that is a pattern and that is a problem. Any ciphertext that contains a pattern that we can easily recognize means that it has a weakness in that it gives the attacker a chance to use that pattern to work out some structure in the plaintext. We'd like the output ciphertext to be completely random. What is our weakness here? That's the question. Anyone? Desk works. Okay, the algorithm desk is secure. Okay, all right, brute force attack, it's subject to, but in terms of producing random output, it works. So if we looked at one block of output, look at those bits and they are effectively random. Let's show you the input plaintext again. Can you see? Look at those corresponding rows of the plaintext and the ciphertext. With the plaintext, the fourth row was the text space, secret space. That was part of our message. And the seventh row was the same. And as a result in binary or hexadecimal, we have the same input block. P4 is the same as P7. The result, remember all we did is we took P4, encrypt it using one key and get C4. P7 encrypt using the same key and we'll get C7. When the two keys are the same and the two input blocks are the same, then the two output blocks will be the same. And that's what we see in the ciphertext. The fourth output ciphertext block and the seventh output ciphertext block are the same. The weakness is in this way that we combine the output blocks. We just concatenate them together. It's called the mode of operation. This one is very simple, we just combine them as is. And that reveals a weakness in this approach. If we do that, we can get still patterns in the overall output ciphertext. The desk algorithm is secure, but the way that we combine the blocks is not secure. So what we need is another way to combine blocks such that even if the input blocks repeat, sorry, wrong place, even if we have secret and secret as two different or two input blocks, the same input plaintext, we need to get output ciphertext which is different. And that's what we call a mode of operation, the way to do that across multiple blocks. This mode of operation is insecure, very easy but insecure. We will just complete, we'll decrypt. And I'm just gonna copy and paste the command because it's very similar to decrypt. We just change e to d and reverse our input and output. And I'll call the output receive dot text. So this is the receiver, they get the ciphertext as input. They must know the key, the same key is used for encrypting. They must know the initialization vector as well. And they'll decrypt and we'll just look at the received file. And it's the same as our original plaintext. So the decryption works in this case. If we decrypted with the wrong key, instead of five four at the end, say five three and we look at the output, I'll use x, x, d to show the hexadecimal form. So receive two is what if someone received the ciphertext encrypted with one key and then we try to decrypt it with a different key, the wrong key. What do we expect? We'd expect random, unrecognizable output in this case. And indeed it is in this case that using the wrong key even though the key differed by, well just one bit in fact. Four became three, the key was very similar, the output is completely different, random. Using the wrong key will give us the wrong output and recognizably wrong in this case. We see it's not English message. So OpenSSL will have a few homework tasks which require you to use that, not too hard, I'll give you the commands, but just to generate some, to encrypt some messages and to later generate some keys for public key cryptography. So let's talk about the modes of operation because I think we can do some of them quite quickly and then in the last five or 10 minutes we'll come back to the speed of encrypting and brute force attacks. So we'll come back to this slide just towards the end I think. Actually I changed my mind, let's stay on this slide. Finish it because late on Tuesday afternoon let's stay with the simple stuff. This last slide here compares some attacks on block ciphers and really to measure attacks with respect to speed we need to know how many operations we need to apply to perform the attack and how long it takes to apply an operation. How long does it take to encrypt something or decrypt? I'll decrypt again, you see how long it takes. It's basically instantaneous, we cannot measure it easily here. So we'd like to know how long does it take a computer to encrypt or decrypt? In most algorithms, so with symmetric key algorithms encryption and decryption take about the same time. They're very similar in the operation. OpenSSL has its inbuilt speed test where it will take an algorithm and do many encryptions over a period of time and tell us some results of how long it took. I hope I've got it right, wrong. OpenSSL speed test on des. What it does is it tries des for three seconds at a time on different size input blocks. So the first thing it did was for three seconds it encrypted random inputs. Each input was 16 blocks. I'll stop it there, it keeps going for a while and just explain. For three seconds, it uses des and in this case it didn't use ECB, it used another mode, CBC. Just a more secure one than ECB, much more common. And it encrypted random blocks, each was 16 bytes long. Our use of des we encrypt as a 72 byte input. In this case it's encrypting 16 byte inputs. And it measured how many it could do. It did, what's that, about 10 million, 9.6 million encrypt operations in three seconds. So that's about in one second about 3 million or 3.2 million encrypts per second. So that's just a quick indicator of how fast my computer can encrypt. And we could do, on different length inputs we could see also how long it takes. Basically it's a linear in that if you double the length of the input you'll double the time it takes to encrypt. So in this case with a small block I can do about three million, a little bit more than three million des operations per second. If I left that running it would show me some summary statistics, but we don't need that. Just about three million per second. How long will a brute force attack on des take me? On my computer, just my laptop, let's approximate. Three million per second. How many keys do I need to try? With des, single des, two to the power of 56 in the worst case. That many keys, but I can do three million per second. So the number of seconds is that many. So that's how many seconds it will take. We can convert to minutes divided by 60. Convert to hours, convert to days, convert to years. Seven hundred and sixty years it will take my laptop to break des, okay? So when we say that des is subject to a brute force attack well maybe not on your computer you'd need a lot more resources than a single computer. Or, and we'll show an example, awesome dedicated hardware that's built just for doing brute force attacks on des. So my CPU in my laptop is built for doing general purpose operations. You could build hardware that is just tailored to do des decryptions. What about AES? AES is considered a secure algorithm today. We'll do a quick speed test. And with AES you can choose from different key lengths. 128 bits is the lowest, the smallest key length. And we again have modes of operation. CBC is one of them. So AES is a different cipher. We'll just do a few or the first, we'll stop it there. On our same size input with AES I got, what's that? 11 million operations in three seconds. So slightly faster than des. Des was about nine million per three seconds. Here we've got 11, so almost four million per second. This is 128 bit key. So I could get my calculator and try two to the power of 128 divided by four million per second and see how many centuries it would take me. But it turns out nowadays your CPU has some instructions built in that is tailored just for AES. So most CPUs today have some, so if you think of the instructions that are available on the CPU, there are some that are just for encrypting with AES. So what we can do is we can try and use those instructions. Currently it's doing all in software. So all the encryption is performed in software but I can tell OpenSSL to try and use some of the hardware capabilities and see if it's faster. It's the same but I need to add an option. Doesn't matter what it is. I've found out what it is. This will tell my computer or tell OpenSSL, don't try and do everything in software. Try to use some of the special features of the CPU that provide AES encryption and it's only for AES. Let's hope it's faster, was it? That's 68 million, okay? So that's six or seven times faster, six times faster than just using the standard operations of the CPU. So you can build your hardware that is dedicated for encrypting and you can get a large increase in speed. So CPUs today include AES operations. So this went from 11 million in three seconds to 68 million in three seconds. Still with 128 bits, 68 million in three seconds is about 22 million per second. Two to the power of 128. Seconds to minutes to hours to days to years. That's the number of years it would take my computer to do a brute force on AES with 128 bit key. AES, the key length of 128 bits is considered not subject to a brute force attack. The key length of 128 bits is considered sufficient for most practical reasons. So yes, much more secure than DES, which only has a 56 bit key. It's to do with the key length in this case, not the algorithm. What this table summarizes is some comparison between several different algorithms, DES, triple DES and AES with two different key lengths. Remember when we compare attacks, there's either brute force, which purely depends upon the key lengths, and crypt analysis, which uses or tries to find some weakness in the cypher to do an attack, like our meat in the middle attack. And in that case, we make a trade-off. Crypt analysis tries to reduce the time it takes to do an attack, but at the expense usually of either having more memory and or requiring more known information. And that's what this table lists. The way to read it is that with DES, the best known method on single DES is brute force attack. There are no significantly faster attacks. And the key space with 56 bit key, the key space is two to the power of 56. So the time measured in number of operations is two to the power of 56. So we don't give an absolute time in seconds, we measure it in the number of operations or order of magnitude. Of course, the time depends upon your computer speed. If we had my laptop, it was 700 years. If we had 100 PCs, then we could increase the speed at which we decrypt and reduce the time. With triple DES, the man in the middle attack is possible, but it's not as successful as on double DES. And there's a man in the middle, sorry, meet in the middle attack on triple DES. If we have a key of 168 bits, it reduces the time down to effectively trying 111 bits. Remember with double DES, we had a key of 112, but the meet in the middle attack reduced the time to about equivalent to 57, two to the power of 57. And the same concept applies here. But to do that attack, you need a large amount of memory, two to the power of 56 is the order of magnitude for the memory, and you need some known data, not much in this case. There's another attack by some person called Lux on triple DES, which takes slightly longer than the meet in the middle attack, four times longer. It requires more memory and it requires much more known data. So just examples of two different attacks in this case. With respect to AES, there's some known attacks in theory. With AES, 128 bit key, brute force would take two to the power of 128 operations. This attack by clique attack takes equivalent of two to the power of 126.1 operations. Again, about four times faster. So instead of my billions and billions of centuries, it's divided by four. But this attack requires some memory and a lot of known data. It requires the attacker to know two to the power of 88 combinations of plain text, cipher text pairs, which is practically impossible to know, and similar for AES 256. So when people analyze the strength of algorithms, they usually compare them on those three metrics. Time, memory required to do the attack, and the amount of data that is known by the attacker in advance. Questions on that slide before we have one last example. How am I gonna speed up? This was my computer. This is the number of years it takes to break AES 128. How am I gonna speed it up? Sorry. Use more computers. Because on an attack on a key, we can try them in parallel. On one computer, I can try and equip some set of the keys. On another computer, the other set of keys. So we can parallelize this problem. Therefore, the more computers, the less time. So yes, I could get the 100 or 200 lab computers here at SIT and run my attack on them. And I reduced this time by a factor of 100, but still not possible to break. What else? More computers or faster computers? I just use my laptop, maybe get some hardware which is dedicated to breaking AES. And these last few slides, the last 10 minutes, give some examples of attacks on both DES and AES. Again, you have these slides there. So we'll first look at DES. Remember DES, 56 bits. In 1998, the EFF developed some hardware that did break DES. So that's, what's 17 years ago, they developed hardware which cost less than 250,000 US at that time, and it could do about 80 billion keys per second. My laptop did at what, two or three million keys per second. My laptop did three million per second. This hardware 17 years ago could do 80 billion keys per second. So you can imagine if there was dedicated hardware today, it could be much faster. So in that time, it solved DES, that is it found a key in 56 hours. So although my laptop cannot break DES, today it's not hard to find hardware that will. In 2006, a company tried to improve upon this or this was one of the attempts. So what they did is they used FPGAs, two programmable gate arrays. So some dedicated hardware that they programmed, designed and programmed just for breaking DES. And they had a, basically they had a product. It had 128 FPGAs. So this picture shows how many there are there. 16 or 20 FPGAs, they had a total of 120. And per FPGA, they could do 400 million keys per second. So times that by 120. And they could break DES in nine days about and only cost $10,000. So the cost comes down. At that same time, in 2006, a typical CPU was a Pentium 4, which could do about two million keys per second. What about today? Well, my slides haven't been updated for one year at least. 2013, it's not much different this year. How fast do computers increase? Well, Moore's law is one measure that says that, so Gordon Moore come up with this rule, that the number of transistors we can put on a CPU doubles every about 18 months, one and a half years. Now, it's not perfect, but let's use that as a guide saying that every one and a half years, the speed of our computers double. So I buy a computer today. I buy a computer in one and a half years time. It will be twice as fast as today's computer. Or the other way, I buy a computer today. I spend the same amount. No, I buy the same power computer in one and a half years. It should be half the prices today. If the speed doubles, we can get the equivalent speed for half the price. That's what we'll use as a rough guide. If you use that as a rough guide, then you could calculate that desk would take about $300 US to break. That was last year or 2013. So assuming you can halve the cost of hardware every one and a half years for the same speed, you can cut it down to a manageable price. So desk is breakable. What about AES? So this same company that built one of the previous products applied similar approaches for AES. They had some hardware that had 128 FPGAs programmed just to break AES. So to do AES encryptions and decryptions fast. It cost about $100 per FPGA. It could do 500 million keys per second. They also had some power measurements. And if we apply those numbers, using a brute force attack, it could do 500 million keys per second using another cryptanalysis attack, almost a billion keys per second. Brute force of AES, two to the power of 128 keys. So using their hardware, it costs about $15,000 US and you can do about 64 billion keys per second. So expanding that, well, for $15,000, it would take you 10 to the power of 20 years using that hardware. If you had more money, you could buy more of those devices. If you had $15 million, you could buy a thousand of those devices. And therefore you reduce the time by a factor of 1,000. Factor of 1,000 takes us from 10 to the power of 20 down to the 10 to the power of 17 years. If you had a $15 billion, it's down to 10 to the power of 14 years. So still, with $15 billion, this is just some rough calculations, still takes you 10 to the power of 14 years to brute force AES. And it's not much different if you use the more advanced attack, okay? It's still approximately the same. So even today, if you have essentially all the money in the world to buy all the computer resources you can, you're not gonna break AES 128. What if we want to encrypt something today with AES 128? And I want it to be safe for the next 15 years. I don't want someone in 15 years time to be able to decrypt it, okay? I encrypt today with AES 128. In 15 years time, someone finds my file. I still don't want them to be able to decrypt it. So let's predict. Again, assuming that we can halve the cost every one and a half years, in 15 years time, that's a factor of, that's 10 times we can halve the cost. Effectively, we can reduce it to, by a factor of 1,000 in 15 years. That is, if you had $15 billion to spend in 15 years time, you could break AES 128 in 100 billion years. If you use AES 256 today, it would take someone 10 to the power of 49 years. So this is demonstrating the brute force attacks no matter how fast your computer are not possible, okay?