 So, let's just illustrate the concepts. For this cypher, we have a five-bit plaintext block coming in, a five-bit plaintext cyphtex block coming out, and a three-bit key. So, we could draw that, just draw it up the top saying that our simple cypher, can someone give it a name, give our cypher a name, Bob, okay. The plaintext comes in and our cypher, I need some space, sorry, Bob, that's the name of our cypher, it's not desk, it takes a key in and produces cyphtex that comes out. The length of those, in our case, are five bits, the key is three bits, and the cyphtex is five bits. That's the single version of our cypher, Bob. That's the normal operation. From the perspective of a brute force attack, what's the worst case time to break, Bob? So, we do a brute force, what's the worst case number of operations I need to break this? Eight. Why eight? Two to the power of three. Our key is three bits, we have eight possible values, two to the power of three possible values. Not if I replace Bob with desk on our drawer, but let's say, we just changed the algorithm. Do you remember the key length or the effective key length in desk? The effective key length, 56. The actual key that you choose is 64 bits, but eight, or eight of the bits are unused in encryption. So, we'll say 56 bits here, because in practice, the attacker needs to try and find those 56 bits only. So, with 56 bits with desk, a brute force worst case, two to the power of 56, that's a six. We'll just keep track of both of them. We'll go through the simple example and compare. So, that's the normal case. Of course, our simple cypher is subject to a brute force attack, and in fact, desk today is considered subject to a brute force attack. 56 bits is not long enough. So, the concept of a double cypher, double encryption, we take our plain text in, we apply our cypher, we use one key to encrypt that, we'll get a value that comes out, we'll denote as x, some intermediate value, and then we take that, encrypt that again. But this time using a different key. Same cypher, different key, and get cypher text out. Still, same lengths for our simple cypher Bob, five bits of plain text. X value will also be five bits, C is five bits. The keys each are three bits. So, just apply the cypher twice. Note, if we take a plain text, we get some x that comes out. X should be random with respect to the plain text. That's the idea of the encryption. That is, we'll get a different value out. Then we encrypt that different value. We should get another random value output. So, we'll get a secure cypher text. Now, we use two different keys. The chooser chooses those two keys. So, effectively the user chooses a six bit key. They choose a six bit random value. The first three bits will be used for the first step. The second three bits used for the second step. Let's call this double Bob. We've applied Bob twice, brute force. What's a brute force attack on double Bob? Two to the power of six operations. Again, the attacker has to guess both values of K1 and K2 if they want to do a brute force. So, six bits to guess. Two to the power of six operations. Similar with double desk. How many bits? Well, we expand our key from 56 up to 112 bits. We just use two different keys or two random keys. With double desk, a brute force would take two to the power of 112 operations. And if you look up, if you go back to that table, we gave some example times for brute force attacks. You'll see that with computers today, that's probably not possible. If we try to do calculations of how fast computers are, if you had thousands of computers, it's still going to take many years to do a brute force attack. So that's the idea. Make a brute force attack not possible. Let's see why we can try a different attack to still defeat double desk. And the attack is called meet in the middle. What we will do, we will assume that the attacker has a pair of plain text ciphertext. That is, this attack requires the attacker to have a little bit of extra information to work. The assumption is that the attacker knows from some past encryption by the user, they know plain text and the corresponding ciphertext. So knowing a ciphertext is easy. Intercept and you learn the ciphertext. But we also assume that they know what was the plain text for that case. They don't know the key, but they know one pair of plain text ciphertext where the ciphertext was obtained using the Bob encryption algorithm using some secret key, K1 and K2. We want to find K1 and K2. How can our user or our attacker know a pair of ciphertext and plain text without knowing the key? What we need is somehow that, let's say we can learn ciphertext easy, intercept. How do we learn the plain text? Well, the idea of encryption is we can't learn the plain text if we don't have the key. We don't have the key. How can we assume that the attacker knows the plain text? Well, it may be some, in some cases, possible. Sometimes the ciphertext is encrypted and it only needs to stay encrypted for a certain period of time. Maybe the plain text is released publicly later. Okay, so let's say I encrypt a message. I send the ciphertext to someone. The message only makes sense for one day. After two days, it doesn't matter if someone knows what the plain text message is. So the attacker may discover this old ciphertext corresponds with this plain text value. A simple example of that. Let's say the plain text message is the coordinates of where the military is going to bomb some place, okay? So the headquarters of the military send the exact GPS coordinates. You need to bomb this location. They send it to the plane that's gonna bomb them and they bomb that location. The attacker, of course, they don't send the coordinates in plain text. They send them encrypted so that if someone intercepts, they can't learn where they're going to bomb that location. So the attacker sees the ciphertext. They can't find the plain text, fine. But tomorrow, after they know that that location was bombed, they know the ciphertext and they know the coordinates of where it was bombed because it was actually bombed. So now they know the corresponding plain text with that ciphertext because that information was only really valid for up until the time that the bomb was hit the ground. So that's an extreme example but there's other cases where it's possible for the attacker to learn the plain text, even if they don't have the key. So let's assume that they do. And I'll give you a pair. Let's... We'll use our table to do the encryption. Our meet in the middle attack. This attack assumes that the attacker knows a plain text ciphertext pair. And I'll give you one. And in fact, in practice, when we apply this attack to real desks, usually not just one pair that they have to know, they may need to know a set of pairs, okay, more than one. And at the end, we'll analyze and see how many. Let's give you a second one just in case we need it. This is known by the attacker. Another pair. What that means is that the attacker knows that when P1 is encrypted, we get C1. When we use keys K1 and K2, but we don't know the keys K1 and K2. The goal of the attack is to find the keys K1 and K2. They also know using those same two key values, encrypting the value of P2 gives C2. So this is learnt by the attacker in advance. They need this to be successful. Given that, now they start the meet in the middle attack. And it's quite simple. What they do, given one of the pairs that they know, say with the first pair, they take the plain text P1 and they do a brute force on that plain text using the single version of the cypher, Bob, and find all possible potential values that come out of that. That is what they're going to do in the picture is they know P1, they're going to encrypt P1 with every possible key. They don't know K1, so let's try all possible values. We'll get multiple values of X coming out, potential values, not necessarily the correct one, but possible values, and we'll store them. And then what we'll do is we'll take the known cypher text, C1, and go backwards. That is, we know what C1 is, we know what P1 was that we started with, we don't know K1 or K2. After we try for all possible values of K1 on P, we get potential values of X, then with the cypher text, C1, we decrypt that with possible values of K2. And the idea is that if we know that P1 produced C1 as output, if you encrypt P1 with the correct key, you'll get some X value, and if you decrypt C1 with the correct key, you'll get the same X value. It must be the same because otherwise they wouldn't have produced that correct pair. So what we do is, once we know the potential values of the X in one direction, we work backwards and see if we find a matching X from the cypher text. If we do, then that's a potential key pair. If it's not a match, then it's definitely not the correct key. So we'll try that. The first step, a brute force attack on P1, using our cypher bob, and the key K1 is three bits, so we need to try eight possible keys. So the meat in the middle attack, we're going to start with P1 and encrypt with the eight possible keys. I'll list them. We know what they are. And we're going to get eight intermediate values of X. So look up in the table. Given plain text, 011, 01, key 0, 0, 0, what comes out for our cypher bob? Simply look up in the table, write it down, and then do it for the other keys. So we need to try it for all possible keys here. This is a brute force on the single version of our cypher. Quick, won't take long to find the answer. Eight values of X. How do they know the plain text? There are some examples where the text is owned and because the message was only secret for a short period of time, then maybe the plain text is released later. Maybe the plain text was a message to say, buy these stocks in Apple, buy a thousand shares of Apple at this time, at this price. That was encrypted. Once they are bought the next day, then it's no longer to stay encrypted because if someone sees that you've bought them after you've already bought them, you may not want to keep them secret. You want to keep it secret before you buy them so that someone doesn't know you're going to purchase stocks, for example. So some information, the plain text, is only need to be secret for a short period of time. If that's the case, then the attacker may discover that plain text. What do you get? Write down your values. Look up your table and find out the values of X, which is just the ciphertext that comes out of our bit block cipher. Eight keys. What was our plain text? 01101. 011. Here's our plain text. Encrypt with the first key and we get this value as output. The second key, the next column and so on. So we just get these eight values as output here. Let's write them down and I'll give them values. I'll say it's X, the first value of X11. We'll give these eight potential values of X. This we'll call X18. Keep track of how many operations we do because at the end we need to count how many operations do we do in total or in a typical case and compare it to brute force attack. Here we've encrypted our plain text eight times. So the number of operations is eight or two to the power of three. It depends upon the key length here. Now we give these eight values, we store them in memory. So we have to save them. And then the next step is that with the corresponding ciphertext C1 we decrypt that with potential key values. We know C1, it was given to us, five ones. So decrypt with the potential keys, see what we get. This was X1, we're going to get another X value here, X2. What we do is we take this ciphertext, decrypt with our first possible key. We don't know what the value of the key is, we try this one. What do we get? Look up the table. Five ones decrypted with key 000. We did it before. So decrypt those values as you go. Find the cipher page 107 and decrypt the value 1111 with the key 00. What do we get for the first value of X? 10001, we did that before. Let's just check that. The key was 300, the ciphertext, five ones, which is here. Decrypt this and you get 10001. And then we do that for the next key. This is the X value, X21, we'll denote it as. And you keep going with the other keys. You'll tell me if I write down any errors. This is our last value. So the first stage, encrypt the plaintext with all possible keys. The second stage, take the corresponding known ciphertext for that plaintext that we started with, C1, and decrypt that with what we did with all possible keys. We'll come back later and sometimes we may not need to do all possible keys in the second phase, but we will do that. So in our block model, what we did, P1 encrypted with eight keys, get potential values of X, X1, so X11, X12, up to X18. With C1, decrypt with all possible keys, K2, and get X2, X21, X22 and so on. And we know if we've got the correct K1 and K2, then the X values should match. X1 should equal X2. Because we know that X is the intermediate value when we encrypt to get the ciphertext. So this tells us what are the potential values of K1 and K2. And it's quite easy to see. We look at the values where the X are the same on both sides. Does this value X11 match any of these? See if you find this value in this set. Actually, we'll do it the other way. We'll try with X2 first, because that's what's done in practice. Does 1, 0, 0, 0, 1 appear in the first set of X values? No, it's not there. Okay, so the next value. Does this appear in the first set? Check carefully. No, it's not there. The third one? No. Fourth one? Are we unlucky today? Fifth one? Yes, that's there somewhere. There's a match there. We know that if we've used the right keys of K1 and K2, the potential values of K1 are those that we used when we obtained X1, and the potential values of K2 are those values of the key we used when we obtained X2. So we know if we've used the correct values of K1 and K2, the X values must match. Here we find a match. Any other matches? Which ones? The last value of X2 matches two different places, and that's possible. All the others don't match, which means that the potential values of K1 and K2, well, there are three potential values, three pairs. K1 could be the value we used to get X12, 001, and K2 could be the value we used to get X25, which was 100. So that's a potential key pair. We're actually looking for the entire six bits, but I'll write it down as a pair of keys. K1, K2, we're trying to find. The first potential values are 001 and 100, but there's other potential values, 011 with 111, and the last one, 100, 111. So the attacker now knows that the keys used by the user are one of those three pairs. We want to know exactly which one. How do we find out? Try to print a new message. Well, in fact, I gave you a second one because I knew that's what we would need here. If the attacker has a second plaintext ciphertext pair, like the one given here, they can check which of those three potential key values, if we take our plaintext 2, 11001, encrypt with potential value of K1, you get X, encrypt that with a potential value of K2, if you get this ciphertext value, then you're very confident that it's the correct one, maybe not for sure. If you don't get it, you know it's not the correct key. Try. See which of these three potential values are correct, or which are incorrect. If there's only one left over, that's the correct value. That is, encrypt P2 with K1 and K2001, 00100, potential value. Try. It's useful to look up. Start with 11001, P2, and we'll try these first potential values of the keys. If we use K1 as 001, what does the value of X become? Encrypt this value of the plaintext with this key, what's X? If you look up in the table, all zeros, five zeros, good. Now take that X value and encrypt it with the value of K2. 11, what's K2 is the other value in the pair. We're using this pair first, we'll try that. When we do that, we get ciphertexts and 110011. Does that match the expected value of ciphertext? Yes it does. So this key pair that we just tried is a potential correct key pair. We don't know for sure, maybe there's still others that are also potentially correct. One way to find out is to try the others. So do the same with the second key pair, 011, get a value of X, and then the second one, 3 ones. And to be complete, we'll try with the last one. All we're doing here is encrypting using our lookup table. Using the table of the five bit block supper, we know the plaintext in, we know the key, find the output, and then take that as the plaintext in the next step. With the key, find the output, and see what you get. And then check whether the ciphertext values you get out match the known correct value. The known correct value was given in our pair. We know c2 should be this value. Well we got it here. Here we get 10111 out, we try key 111, and you get 10100 out. This is the wrong key pair. We know for sure now that this key pair is not the correct one, because it doesn't give us the right ciphertext value. And we try the last one, and we get a ciphertext value that also doesn't match, and that gets us to the end. We now, of those three potential key pairs of k1 and k2, we tried them all using our second known plaintext ciphertext pair, and we found that two of them don't work. Only one of them works, and that tells us that the correct values of k1 and k2 are the first pair. k1 is 001, and k2 is 100. That's the answer. We found the key for the double version of our cipher bob. Count the number of operations we did with a single version of bob. How many encrypts or decrypts did we do? In the first phase we did a brute force attack on the key. We did eight operations, two to the power of three. The next phase we actually did another eight operations, this time decrypt. But generally with ciphers, encrypt and decrypt take about the same time with block ciphers. So we count them as another eight operations. So we've got 16 operations. And then in the last set of checks, we did one, two, three, four, five, six, another six operations. Another six encrypts or decrypts. Just to check those three pairs. So a total of 22 operations in this case. We have to do these eight. We have to do a brute force here, two to the power of three. We did it again, but going backwards, another two to the power of three. And in this case we have three potential pairs, so we need to do another six to check. We won't always get three potential pairs. Sometimes we'll get just one, and therefore we don't need to check. We've already found the correct key. Sometimes we'll get more than one, so we'll need to check. So the main contribution to the number of operations is doing the first two steps. We have to do the brute force here, two to the power of three always. What we can do when we look at the real desk is that we don't even need to do all two to the power of three here sometimes. What we may do is if we find, let's say in this case, if we found the first matching pair after five operations, then check that with another pair. And the probabilities work when you have a large number of keys like desk, when there's many possible values. The probability that the key pair that we find works for two or even three plain text ciphertext pairs is very, very low if it's incorrect. That is if we find a match, very high chance we've got the correct one. Here because there's only eight to choose from, it's possible to get different possible values. But with desk, the chance of getting multiple and then doing it again and getting multiple is very, very low. So we can actually cut down the number of operations by stopping once we find a correct pair. Even if you do them all, two to the power of three plus two to the power of three plus another six here. So we've got two to the power of three, two times at least. There's meat in the middle attack. Let's write down some of the numbers to compare with brute force. On our version of double bob in that case it took us two to the power of three plus another two to the power of three plus in our case another six, 22 in that case. Our brute force on double bob would have took 32. So we've done better than doing a brute force attack. Brute force tried all 32 keys, two to the power of six. 64, well done. Two to the power of five is 32, even better. Brute force requires two to the power of six operations, 64 operations. We did it in 22. We only checked when we have multiple potential values of the key. Like in this case we had three potential values. So we did two to the power of three. We did another two to the power of three operations. Now we have three possible values. So we checked those three only. Another six operations. We'll come back to that in a moment. Let's summarize the numbers. So with a brute force on double bob it would have took 64 operations. Here, meet in the middle, in our specific case took 22. We're about three times faster than a brute force attack, a third of the number of operations. So that's good. That's where this attack is better than brute force because we can find the key in less time. Double desk. We must do a brute force attack on the single version. So there's two to the power of 56. And then worst case we need to do another two to the power of 56. Similar here. We did two to the power of three of encrypts from one direction. Two to the power of three of decrypts from the other direction. So we do two brute force attacks. Plus some others. In the same here we had plus six. How many do we plus here depends upon how many matches we get. Here we had six. There were three matches. If we have a thousand matches here we have plus 2,000. But compared to two to the power of 56, two to the power of 56 is billions and billions. So the number that we plus on the end is in most cases almost zero. So small. Plus something. Which is approximately if this is very small compared to two to the power of 56. What do we get? If this is zero so two to the power of 56 plus two to the power of 56. Two to the power of 57. Two times two to the power of 56. Brute force on single desk takes two to the power of 56 operations. Brute force on double desk takes two to the power of 112 operations. Meat in the middle attack on double desk takes about two to the power of 57 operations. It's about two times slower than breaking single desk. In other words if you can break single desk in one day you can break double desk using meat in the middle attack in two days. Which is insignificant from the attacker's perspective. If I can break something in one day then if I want to break double desk in one day as well I just spend twice as much money on my computers. So that's why we say that the double desk is not much more secure than single desk. It's about the same. Two times better. So that's why double desk or double encryption in general is not just for desk. Double encryption like this is not a good approach. It doesn't help. It doesn't help by much. So the meat in the middle attack means that we shouldn't just do double encryption to extend the key length. You can try triple encryption. One then another then another. And it turns out that that does make it harder for the attack. And because you can't go back from either end points because there's two X values in the middle. So first let's summarize our meat in the middle attack. In terms of number of operations what we do a brute force on the first key value K1 and then a brute force on the second key value. So equivalent to two brute force attacks. And then possibly a few other operations just to check but usually very small number compared to a brute force attack. So it takes about two times as time to break as a brute force attack on desk using a meat in the middle attack. Now there's some ways to improve that the brute force attack on K2. Again with desk you usually don't have to try all two to the power of 56. Because as soon as you find a match you can confirm that match with another pair and you very high probability that you've got the correct key pair. So in fact usually it's closer to just two to the power of 56 here. Coming back to our specific example. What's the problem with our meat in the middle attack from the attacker's perspective? What do we need to know or what do we need to do to make this attack work? We know that the user hasn't changed his key so that's okay. We assume that the attacker, the normal user is using the same key for every plaintext that they encrypt. We'll come back to that later. A good policy therefore is to change your key. But here they're using the same key. What's the problem from the attacker's perspective? For this to work the attacker needed to know a pair of plaintexts I for text. They needed to know two in our case. So there's one issue. Somehow they must discover this plaintext, ciphertext pair in advance. So this attack depends upon the attacker knowing some information in advance. So that's one limitation. Another maybe more practical limitation is that when they do first brute force on K1 they give these eight values of X. What they must do is they store those eight values because when they're doing the next brute force they compare the generator value of X2 with those eight values of X1. Go through and check, see which one's matched, and if you do get a match you've got a potential key pair. With DES, the number of X values, how many? X1, how many do we need to store? With Bob we store two to the power of three values of X1, that first column. With DES we'd have two to the power of 56 values of X1. So with DES we'd need to store two to the power of 56 values of X1. Then when we go through to find X2 we compare with those two to the power of 56 values. Next one, compare and find the possible matches. The limitation here is the storage. Two to the power of 56 values, how many bytes? Store two to the power of 56. In DES how big would X be? In our cipher X was five bits, a five bit block. In DES it uses a 64 bit block. Two to the power of 56, 64 bit blocks. We need to store them on DESC or in memory. 64 bits is eight bytes times two to the power of 56. That's the number of bytes that we need. Megabytes, gigabytes, terabytes. Only 576,000 terabytes. What's above terabytes? Pedabytes, isn't it? P, I think above T. But a hard disk we measure in terabytes. So we need about half a million hard disks. All right, one terabyte hard disks to store this information in an attack. Here's a practical limitation of the meat in the middle attack. You need a lot of storage space to store that first set of answers and then compare against them. Approximately. And we must know multiple, usually multiple plain text cipher text pairs. So for the attack to be successful, the number of operations is twice as many as a single desk brute force attack. But we must store a lot of information to do the attack and we must know multiple plain text cipher text pairs in advance to be successful. Even though that storage space may be considered not practical today, there may be ways to reduce it or to cut down on how much we store. And this is the double desk is not considered a good design because of the meat in the middle attack. And this was known and people therefore designed triple desk. Encrypt, encrypt, encrypt three times. And you can't take the plain text and the cipher text and go back to get the same point. So you can't meet in the middle in that case. So triple desk is considered secure.