 desk. I cannot do it on the board because with 64 bits it's not easy. So I've made up this other four-bit block cipher which is just passing out now. So you should see this. Everyone have a copy? Let's just explain how to read it first, just the first part, the example block cipher. This table, so I've made up a cipher and all the cipher does, remember, is take some plain text and produces some cipher text given a key. Okay, let's go through our example so we can move on to the last topic on block ciphers. Here's a cipher that takes a 4-bit input plain text and produces a 4-bit cipher text output and it takes a 2-bit key. Okay, block cipher. What I've done in this table is shown you the values of the cipher text for given key values. So with a 2-bit key there are four possible keys, 0 0 0 1 1 0 1 1 and in this cipher when we encrypt for example plain text 0 0 0 0 with key 0 0 the output will be 0 1 1 0. That's how to read this table. Here's the plain text, choose the key and we get the corresponding cipher text and of course we can decrypt as well using this information. So that's our example cipher. Instead of using real desks or even simplified desks we're going to use this one to demonstrate why the double desks or in general it's not just double desks, it's this concept of applying a block cipher two times. It's not any better or not much better than applying it just once because of the meat in the middle attack. So let's show how it works. And the setup for this meat in the middle attack is that what's in the table is just the single version of the cipher. The double version is that we encrypt our plain text, we get some output x, then we encrypt that value x with a different key or another key k2 and then we get our cipher text which is our final output. So that's the double version of this cipher. And what the attacker is going to do is try and guess the key. That's the goal. The attacker if in the single version the brute force attack how many attempts? Single version, brute force, maximum number of attempts. Easy. We just need to try four keys okay. This cipher has only got four keys so brute force in either case is easy but just to show the concept. So for a meat in the middle attack for it to work it requires the attacker to have some plain text cipher text pairs known in advance and I've given them two here. So we assume the attacker knows these two pairs. So the first pair plain text 1101, cipher text 1100. They don't know the key. Their goal is to find the key that produced it. Their goal is to find the value of k1 and k2 because when we encrypt we use four bits for our key in the double version. They also know a second pair. We'll use that later. Let's illustrate what the attacker will do to find out the key. Let me find my example. The first step and you can do it. What the attacker does, so consider the first pair and the attacker does a brute force attack on the known value of the plain text. So encrypt the plain text in the first pair. So we're going to do step one. Encrypt PA using all values of the key. In our case we don't have 2 to the power of 56. We have 2 to the power of 2 values. So encrypt this is PA here. This is CA. Encrypt 1101 with all values of the key and see what values you get. So try it. It should be easy and if I can work out how to write I'll follow it on here. So you take your first value and encrypt with all the keys. So k1, remember in our double cipher we use two keys, two two bit keys. Let's call them k1 and k2. So we take our plain text and encrypt using all four keys and see what the ciphertext is. What's the first value? So the output will be the ciphertext, actually CX. Let's get rid of that. I've gone through this example many times but I seem to lose my notes. So we'll try and record what we're doing. What's the value of the first value of X? That's our X. We encrypt PA equals 1101 with key zero. What's the output? So write them all down. And the next one, that's the first step. And then we do it from the other direction. We take the known ciphertext and decrypt using all possible key values. So how many operations so far? We count encrypt and decrypt operations as the same. So four operations or two to the power of two in this case. Two to the power of the number of bits in the key. Now do the same but start with CA, the corresponding ciphertext value and decrypt using all possible keys. See what you get. You try it. Obviously if I don't remember the answers. Corresponding ciphertext is 1100. So the attacker knows that ciphertext and then try the keys. I'll go backwards. We take the ciphertext 1100 and decrypt using key 00. What do you get? Take the ciphertext and using the table above decrypt 0100 and then do it for the other four keys. Other three keys. So you look up in the table to decrypt the ciphertext 1100, key 00. So look in this column, find 1100 which is here and to decrypt our plaintext will be 0100. So ciphertext key gives us the corresponding plaintext. So decryption stage. Do that for the four keys. So we get four more values of x. Which ones match? Now look at the ones that match. 10000 doesn't match with one of the other ones. No. 10010. Yes. 0100. Yes. And 113 possible pairs. So let's note those values. So possible keys we have now k1 and k2. The first pair where we got x1010, the key was of k1 was 01. And k2 was 11 here. And then do it for the other pairs. 10000 and 1110. So how many possible pairs do we have at the start? How many possible keys are there in total? There are 16 possible keys. Because we've got k1 and k2. There are four bits. There are 16 possible values. What we do is we find all these values of x, the brute force on the plaintext. And then do the opposite, or the operation, the decryption on the other, the output ciphertext. And with our double encryption, this value in the middle, if we encrypt our plaintext with k1, we get x. Similarly, if we decrypt ciphertext with k2, we should get the same x. So if we get the same x on both sides, then that suggests or that indicates that the k1 and k2 that we used are possibly the correct key. If we do not get the same x, then it means for sure that k1 and k2 are not the key. We got three possible keys in our case, k1, k2. So the key now, the attacker has cut it down from 16 possible values to three possible values. The key is either 0111, 100, or 1110. So from 16 possible keys, the attackers reduced it to three possible keys. What do they do now? We want to know the exact key. Perform another thing. You're correct? Correct. Perform the same steps using just this set of keys on the other pair of plaintext and ciphertext. Remember in the question there's two pairs known. The attacker, we assumed at the start, knew this pair of plaintext ciphertext and this pair of plaintext ciphertext. And that they have been generated using the same key. That is, this plaintext was encrypted using k1, k2, and we produced this ciphertext. We don't know what values of k1 and k2. That's what we're trying to find. Similar, this plaintext 1001 was encrypted with k1 and k2, the same as what was used here, and produced this ciphertext. So we've got three potential values of k1 and k2. Let's test them on this pair and see what we get. Try them. So you can try, encrypt that plaintext with your first potential value of k1 and k2 and check if you get the corresponding ciphertext. If you don't, you know it's definitely not the key. So try and encrypt using first this pair, and then this pair, and then this pair. Where you're encrypting p, let's say pb in this case, which is the value given in the handouts. What was pb? 1001. So encrypt pb with k1 equal to 01 and you get, if you encrypt 1001 get it as an output, the x value, 0000. And then encrypt that 40 again with k2. And what do you get? 0010. Try it for the other two pairs as well. So this, the first column is x and then c. Anyone get the answer? What's the key? It looks good. See if you can find the key, the final answer. So this is easier, this step. Just take pb and apply the double cipher using this pair. So pb encrypted with 01 gives 0000 and now encrypt this 0000 with 11 and you get 0010. So this is the value of x, the intermediate value, this is the final value of c. Does this match the expected value? No, it doesn't. So we know in fact because this doesn't match the expected value, the expected value, the expected value, we know it must produce 1101. If we encrypt 1001, we must get 1101 as the output. If we don't, we know that that key pair is wrong so we can discard that one. That one didn't work. So do it for the next one. Encrypt our pb with 10, k of 10, we get the output and then encrypt with k of 00 and we get the ciphertext. Is it correct? No, we're out of luck or in luck in fact because we're sure that last one will. Encrypt pb with 11, you get 0111 and then encrypt 0111 with 10 and you get 1101, which matches the value we know. This must be the key. We've found the value of the key now. We only had three possible pairs. We're sure that the first two are not correct because they don't give us the correct ciphertext and because the last one does, we know for sure that this is the key that the normal user used to produce those plaintext ciphertext pairs. So we've discovered their key. Count the number of operations we needed to discover that key. It's not a good example because it's just as many as we did a full brute force. Which one? Which step here? You can do this last step in different ways. You can encrypt the plaintext using the keys and you should get the corresponding ciphertext or you can go backwards, you could decrypt and you should get the corresponding plaintext or you can get them the matching x value in the middle. Yes. So in the first step, in our case, we've got three possible pairs. If we only got one, then we're lucky. We've found the key immediately. So if there was only one pair here that matched, then that indicates for sure what the key is. That's even better. Sometimes you'll get one, sometimes you'll get more than one. If you get more than one, then now you need to cut down of those possible keys which one is correct. So you needed that second pair of plaintext ciphertext. In some rare cases, there may be more than one here. There may be two possible that match and you just do it again with a third pair of plaintext ciphertext. But the probability of matching more than one reduces significantly. It turns out when you have much larger numbers that in most cases in the first instance there would be just one match because you have two to the power of 56 keys. You have two to the power of 56 values here and the possible number of values here are two to the power of 64 because you've got a 64 bit block. So the chance that one of them, more than one pair matches is quite low. So when you drop the full desk, it's even better. You usually find it in the first case. If not, you try another pair. Everyone can break double desk. Any problems? Let's hope so for the exam sake. In this case we had to, in fact we do four operations, another four operations, eight and then, in fact, how many we do here? Another six operations here. We were unlucky in that we had three that matched because we had, I had to do an encrypt, a decrypt, encrypt, encrypt, encrypt, encrypt and there's only the last one that matched. It was the first one and the other, well, we still have six I think in that case. In this case we had a total of, what, four plus four plus another six which is 14 operations. The worst case we'd need if we did a full brute force would be 16. We've saved two in this case. But in most cases, if we expand this to not two bit keys but 56 bit keys, we do two to the power of 56 operations in this step, two to the power of 56 operations in this step and then the ones that match is usually one, maybe 10, 15, another 15 operations is minimal, almost zero. Compared to two to the power of 56, if we have to do, if we get three matching here, that's easy to do. If we get 1,000 matching here, it's still easy to do compared to two to the power of 56 operations. So approximately we need to do two to the power of K, operations here, where K is the number of bits in the key. We did two to the power of two. In desk you'd need two to the power of 56 and then another two to the power of K, for example, two to the power of 56. Whereas single desk you just do it once. In double desk you effectively do it twice to break the key. It takes twice as long to break the key in double desk but that's not secure. If something is insecure at some speed, then another cypher takes twice as long, then we consider twice as long as no big deal. Because we just spend twice as much money and we can still break the cypher because we get two times the powerful computer. So if something's secure at this level, twice the time to break generally is not considered any more secure. A thousand times more time to break or a million times is secure but twice is not secure. So if you can break single desk, you can break double desk. That's the outcome here. Sometimes you need to do multiple steps here. Sometimes you're lucky and you just get one matching. Sometimes you're very unlucky and you may get, of these three, two are correct. So you need to try another pair. In real desk you take very little effort this last step here. You'll see in exams, break double desk. Any questions on how to do it? And that attack is called a meet in the middle attack. Because we encrypt from one side and get the value of x and then we come from the other direction, we decrypt and get the same value of x. We meet in the middle of that double desk. The end result, it's about twice as hard as single desk, which is not so useful. So, extend it to triple desk. Use three operations instead of just two. And that problem disappears, or at least becomes much harder because if we know a plain text, we can go in this direction and get a. If we know the corresponding ciphertext we can go in this direction and get b, but a and b are not the same. In double desk we get the same value of x, and that's how we find the key. But with three operations, we can go from p and try the brute force on k1 and get all the values of a, but they will not be the same necessarily as the values of b. So it does not tell us the key if we go in the middle attack. So triple desk is used in practice. Note that it's used in a slightly different way than what we've seen. It's used, you apply, there's different ways. These diagrams use just two keys. K1 and K2. K1 is used twice. So in fact it's a 112 bit key. K1 and K2, 56 bits each. There's another version not shown here that use three keys. K1, K2, K3 gives you 168 bits. 112 is considered okay in terms of security against brute force attack. We saw that 100 bits in 15 years from just before the break would take too much to break. So 112 is even better. But if you want stronger, 168 bits. And note also they don't do encrypt, encrypt, encrypt, they use the decrypt operation. Encrypt, decrypt, encrypt. It's just a way to make the implementation easier with single desk. You can see here. If you use, if we use this triple desk, where we encrypt, so we use the encrypt form of desk using K1 and then use the decrypt form of desk using K2 and then back to encrypt form. So that's triple desk. If we use the same value of K, that is K1, K1, K1, then it reverts back to normal desk because we see here, if we encrypt the plain text with K1, we get ciphertext. If we decrypt that ciphertext with the same K1, we'll get the original plain text. And if we encrypt that plain text with K1, we get some ciphertext. The idea is that we have triple desk. If we want to use triple desk, use two different keys or even three different keys here. With the same code or the same hardware, to get back to the original single desk, just use the same value of the key here. So someone has an implementation of triple desk. You can use that to perform single desk by just using the same values of the key K1, K1, K1. And you will encrypt your plain text and you'll get the same as if you encrypted just one operation. Just a bit easier in terms of distributing the hardware on software. Because you will not be able to revert back to single desk. That is, let's assume my piece of software implementing triple desk implements as shown here. Then what I do, so I've got a piece of software that does triple desk, three desk. Then if I want to use triple desk, I take my plain text, 64 bits and I supply a 112 bit key. And the software will split that 112 bit key into two values, K1 and K2. And it will use K1 to encrypt the plain text and then take the output and decrypt it using K2 and then K1 again. Or, so option one, I supply a 112 bit key. Option two, I can even supply a 168 bit key. And in that case it would use K1, K2, K3. I'd split that 168 bits into three different Ks. Both of them are considered triple desk. Option three, I supply a 56 bit key. These are two different variations of triple desk. This returns our cypher back to single desk, normal desk. Because what my code does, it takes that 56 bit key and just repeats it here. K1, K1, K1. And because of this sequence of encrypt, decrypt, encrypt, we have encrypt the plain text with K1 and then decrypt it with K1 and you get the original plain text back. So in fact, the first two steps we do nothing. Encrypt and then decrypt, you're back to P. So B equals P. And then encrypt with K1, which is just a single instance of single desk. So it's just a way to use the same code to implement single desk or triple desk and back triple desk using two different key lengths. As opposed to having a different piece of code or piece of hardware even that has to do single desk separately. So if someone sends you some plain text or some cypher text, if it's in single desk, you use this code and pass in a 56 bit key. If it's in triple desk, then you pass in one of the two keys which has been accrued upon and it will decrypt correctly. So it's just a convenience to combine everything into one. If you had encrypt, encrypt, encrypt, it would not work for single desk. You can try it. You'd have to have another implementation of single desk. It's not for security, it's for convenience of distributing and using the code. We've got one or two more example. Other ciphers takes us two to three minutes. Any questions before we move on to that? Quiz was easy. That finishes with desk and triple desk. Triple desk is used today. It's available. One of the reasons to use desk and to expand it to triple desk is because it was a government standard in the U.S. Originally desk was a standard which meant that if you wanted to do business with the U.S. government and you wanted to encrypt, you had to encrypt your data, then in the past years you had to use desk to encrypt your data. It was supported. It was the only one supported or the main one supported by the U.S. government and therefore it became popular. So it made sense to make use of the same algorithm and triple desk has been used as well. The problem with triple desk is that it's three times as slow as single desk because we're doing the operation three times. And single desk wasn't very fast compared to some ciphers. So the performance is not so good. So people have come up with other standards and other ciphers. So the same organization that developed or standardized desk, they used triple desk but they wanted to find a faster cipher which is just as secure. And they started to call for designs. So ask researchers and companies for designs of new ciphers in 1997. Eventually some were submitted. So there was some competition. You submit your cipher and people evaluated it. And one called Rindale was chosen and that was standardized as what's called AES, the Advanced Encryption Standard. And that's very common now. We're not going to go through the details of AES. We're just going to use desk as their example. There's some similar concepts. It uses S-Boxes, X-Ord, multiple rounds. Has a 128-bit block size. In fact supports other sizes. Supports different key sizes. 128-bit is the minimum and then higher. And depending upon the key length between 10 and 14 rounds. And in each round different operations like X-Ords, S-Boxes and some different arithmetic to do some operations on the inputs and output. It's widely used now. AES, many of the hardware or file encryption systems will use AES, Advanced Encryption Standard. Many network communications protocols when you encrypt data across say a wireless network you can use AES. And it's generally considered secure. Both the algorithm no known attacks and the key length is sufficient. So that's a common one in use today. We're not going to go through the details. There's a, for teaching there's a simplified AES. You can see in the textbook but we'll not go through that. And there are other block ciphers. Maybe not as common but still available to use. Blowfish, Toofish, Idea, Skipjack and others. They have their advantages and disadvantages. Mainly they're considered secure but the advantages come mainly in terms of performance. Okay, how fast does your code execute to encrypt something? Openness That is, can you use that cipher without having to pay a license to use it? Can you include it in your piece of hardware without having to get a license? Because of patents and so on. So if you want to build your own wireless router and sell it and you want to encrypt the traffic then you need to make sure you use a cipher that is either open or unlicensed, free to use, or you need to pay a license to use a cipher. So that's another issue. Which encryption has been used on a cipher text? In practice some would be detected based upon similar to some software can detect file types based on the structure. But generally you can try if you encrypt something with des and you get some output and try to decrypt with AES it will give you an error. It will show that it cannot decrypt. Because most likely there's not just the cipher text but some extra information that identifies how long it is maybe sometimes what algorithm was used so that you can check whether the cipher text is correct or not. So it depends on the software that's encrypted. In most software I think you could be able to detect what cipher was used. Because the software would attach information to that file or that information and you'll receive the cipher name and the cipher text. But in theory no, it's just a sequence of bits. Cipher text is just a sequence of bits. Because in theory the cipher text is a random sequence of bits so all of the ciphers should produce a random sequence of bits. How do you know which one produced it from the cipher text? You cannot. In practice it's possible in some cases. Done. Block ciphers. What's next? AES uses a block of 128 bits. DES uses a block of 64 bits. The others are similar. I've got a one megabyte file. What do I do? How do I use AES or DES? They only encrypt 64 bits or 128 bits. I've got a one megabyte file. How do I encrypt that with DES? Break the file into smaller 128 or 64 bit chunks and then encrypt each chunk of 64 bits using the same key at a time. What's the problem? The performance is not a problem. We have to encrypt it. We cannot avoid it. So performance is not an issue. I've got a one megabyte file. Let's say I break it. I don't care how big it is. I break it into a million blocks of 64 bits. So 64 million bits at the start. 8 megabytes. I've got a million blocks of 64 bits. So I encrypt the first block with DES using my key. Then I encrypt the second block with DES and get some ciphertext using the same key. So we get one million blocks of ciphertext as the output. Any problem? Repetitions. If there was repetitions in the input plaintext, that file had some parts which repeat inside it. Then there will be repetitions in the output ciphertext when we join them all together. Because if we encrypt one block of 64 bits, we'll get ciphertext. If we encrypt the same block some time later, we've got the same input plaintext, we'll get the same ciphertext as the output. So if we have many blocks on the input and we just encrypt and then combine or concatenate, there's the chance of repetitions on the output. Two repetitions in the output is bad. We want randomness in the output, not structure. So the next topic is how to encrypt a larger piece of input, the different modes of operation. The way to encrypt multiple blocks and combine the ciphertext, they're called modes of operation for block ciphers, block cipher operation. There are different modes, why can't you see that? I can. Different block cipher modes of operation. We're going to go through a few of them, maybe the most common ones. There are others as well. We'll let's see in the next 30 minutes we'll get through two or three and some examples. So it's this concept as we've got a large piece of plaintext, we break it into blocks. The block size depends upon their cipher, so these modes of operation are not just for desks. They can be applied in general to any cipher. So we're not limited to desks now. We encrypt b bits at a time where b is the block size. There are different ways to do it. First one is what we just said. It's called electronic codebook. We break it into blocks, encrypt each block, get the ciphertext, and the resulting ciphertext is just a concatenation of the ciphertext blocks. Describe here. The input is plaintext p. We break it into n blocks. If we had 64,000 bits, 64 bit blocks, we'd have a thousand blocks. So a 64 bit block, the next 64 bit block, and we keep going to the end. So p1 to pn is our plaintext broken into blocks. And we quite simply apply our cipher, our block cipher, desk, AES, whatever, encrypt using k, get a ciphertext block, encrypt the next block of plaintext with the same k, the same key, get c2, keep going, get cn. The resulting ciphertext is concatenation of c1 to cn. The same as the plaintext is a concatenation of p1 to pn. That's generally called electronic codebook. That's the obvious way to do it. And the obvious problem with it is that if there are repetitions in the plaintext blocks, there'll be repetitions in the ciphertext blocks, which is insecure. Decrypt, you can check the decrypt operation, the opposite. It's okay if we want to encrypt a small amount of input, because there's less chance of getting repetitions. So if you've got a 64 bit key to encrypt, then you just need to encrypt using one block. So it's okay for secure transmission of single values of small information. But not good with long messages, because we get repetitions in the ciphertext. So an alternative cipherblock chaining. We have our plaintext. We break it into blocks, p1 through to pn. We choose some initial value. It's in fact called an initialization vector, IV. But think of it as an initial value, an initialization vector. It's a vector. It's a value which is the same length as the plaintext block. For example, choose a random 64 bit value. We XOR the plaintext block and IV, and then encrypt the answer of that XOR. We get ciphertext c1. Then that ciphertext c1 becomes the value that we XOR our next plaintext block with in the next stage. And we encrypt and get c2. And then c2 feeds forward into the next stage. The difference here is that if we have two plaintext blocks which are the same p2 and p3 were the same. p2 is XORed with c1 and then encrypted. If p3 is the same, it's XORed with a different value most likely. Because c2 should be different than c1. So even though the plaintext blocks are the same, our ciphertext blocks will be different. That's why it's better than ECB, Electronic Code Block. So we've got this chaining of the blocks. The second one depends upon the output of the first one. The third one depends upon the output of the second one. And we take the output and XOR it with a plaintext block and encrypt that value. You can work out decryption XOR is commonly used in ciphers. We've seen XOR in the internals of DES. We see it here multiple times. XOR is fast to implement. To XOR two values in hardware and software is fast. Encryption and decryption, these gray boxes are generally slow. So when it comes to performance, the slowest part is applying, for example, the DES cipher. Encrypt here means apply some cipher. DES, AES, triple DES, whichever you choose. Compared to an XOR, the encrypt or decrypt is very slow. That becomes important when we compare some of these modes of operation. Also, what's another property of XOR? When you XOR A and B, and you get C, if AXOR B gives C, how do you get A back? If you take C, if you XOR with B, what do you get? You get A back, don't you? Try. So that's the property of XOR which is useful for encryption and decryption. If you XOR two values and get C, if you take C and XOR with one of those values you get the other value back. Which is like encrypting. Or we can use XOR for encryption. Take our plain text XOR with the key. You get cipher text. That's an encrypt operation. The decrypt operation is the same XOR. Take our cipher text XOR with the same key and you'll get the plain text back. So the nice thing about XOR is that you can use it to encrypt and the corresponding decrypt operation is the same XOR operation. It's the same in both directions. So we see it quite often in here. It's fast and easy to do both operations. Does it work? It works. Okay, that's good. We'll be in problem if it didn't. So we see here we use it to encrypt and the decryption operation take the cipher text apply the decryption of your cipher same key and then XOR with IV again. Because that's the opposite of encrypt. Encrypt was XOR encrypt. Decrypt sorry, wrong way. Decrypt is decrypt XOR. We go in the inverse. We apply the inverse operations. The inverse of XOR is XOR. Let's look at one more model operation and then you can do some examples. So CBC is used to encrypt data, a common approach used. The initialization vector must be known by the sender and receiver and it should be kept secret. So it's another secret value. One more before you do some examples. Cipher feedback mode. Let's not. Let's go to an example. It looks too hard. You've got the example. Do the first two. ECB and then CBC using the table on your handout. So here's the plain text. The table is the of cipher. Use a key of 00. So everyone's the same. When you need to use an IV of 1100 you only need that in some modes of operation. So do the first two. ECB and CBC. So find the cipher text. You can do those quickly. Do it first for ECB. Encrypt the data on your handout with ECB and then do it for CBC. You do it for ECB first. Anyone got an answer for ECB? That's the easy one. I'm not going to do that. Answer ECB. 1010. ECB for the second. 1001. So that's just looking up in the table. We're using key 0. So all we do is we look, find the plain text. Find key 00. Look in the column there and you get the ciphertext as the output. What's XOR? Can anyone remind him? When they have the same bits you get 0. When the two bits are different you get 1. It's not a different. You get 1. When they're the same you get 0. OK. CBC. We can see the problem with ECB. For this example the two plain text values P1 and P3 were the same. And as a result the two ciphertext values are the same. So we see repetition in the ciphertext because there's repetition in the plain text. That's bad from a security perspective. Try for CBC. Where you take your plain text block you XOR with initialization vector and then encrypt. So try CBC and see what you get as the output ciphertext. So take our plain text block XOR with the initialization vector. I chose it to be 1 1 0 0. We get 0 0 0 0. Encrypt this using key 0 0 look up on your table and you get 0 1 1 0 as the output. That's the first value of the ciphertext C1. Then take that C1 and use it with the XOR in the second stage. That is XOR C1 with your P2. Any problems? Once you know the answer do cipherfeedback mode. CFP. So we chain together the stages using the ciphertext from the first one as an input with the XOR or the second plain text block. XOR encrypt. Take C2 up and keep going. And the last one is 0 1 1 1. What are we at? 1 0 0. And note the values of the ciphertext C1 to C4. Any of them the same? Or more importantly when there's the same plain text block do we get the same ciphertext block? Not necessarily in this case no. If we do it's just unlucky. Or it's just luck. 1 1 0 0 was the plain text P1 the corresponding block is 0 1 1 0 in the ciphertext. Here 1 1 0 0 encrypts to 0 1 1 1. So even if we have repetitions in the plain text we don't get those repetitions in the ciphertext. Making it harder for the attacker to use the ciphertext structure to get the plain text. Any questions on CBC? CFB cipher feedback mode This mode is commonly used to turn a block cipher into a stream cipher. Let's do it next time. But let's do another one first. Easy one. The last one counter mode. We'll return to the others next week. Counter mode. You start with some counter value. Let's say 0 0 0 0. Encrypt that value using your key. And then XOR with the plain text block and your ciphertext. For the next stage you increment your counter. So 0 0 0 1. Encrypt XOR with the plain text. 0 0 1 0. So just increment the counter each stage. And encrypt the counter and XOR the output of the encryption with the plain text. And once you up to 1 1 1 1 in your counter go next one back to 0. Loop the counter. No the counter is the input to the encryption. Each stage you increment the counter. Think of it. The counter in decimal is 0 1 2 3 0 1 2 3. Because we have a 4 bit. Oh no we go up to 16. A 15. Sorry. We've got 4 bits. Very easy. Note that there's no connection between stages. If we quickly go back to CBC. Stage 2 depends upon the output of stage 1. The problem with this is performance. Because when we have a large piece of plain text to encrypt the second block we must wait for the first block to be encrypted. It's similar in the other ones. The ones we skipped over. We'll see CFB is similar. The second stage depends upon the output of the first stage. In OFB the second stage depends upon the output or part of the first stage. Which means in implementation you cannot implement them in parallel. Because you must finish one stage before you start the next stage. But with the counter mode the stages are independent. So what you could do in terms of an implementation is let's say you had a quad core CPU. Then you've got 4 cores or 4 CPUs effectively. You have a counter. You know the value in advance. Because it's just 0 1 2 3 and so on. So you could do the encryption this one on one of your cores, this on another core and so on. You can only implement this in parallel. And therefore it can be much faster. Because the stages are not dependent upon the other stages. And it's considered just as secure as the others. Encrypting a counter. We know the counter. But when you encrypt it you get a random value as the output. Some cipher text. And then XOR you get the plain text. XOR with the plain text and the cipher text. Decryption is just the same. Look at the pictures. Encrypt decrypt same. Same operation to encrypt and decrypt. With decrypt encrypt the counter XOR with the cipher text. This makes use of this property of the XOR. If you encrypt with an XOR plain text XOR with some value then you can decrypt with the same XOR. Cipher text XOR with that same value gets the plain text back. So implementation wise and speed of performance. This one's very good. And just as secure as the others. What we'll do next week is we'll return to the two we skipped over with some quick examples on them. They need a bit more time to explain. And then we'll summarize on this and move on to the next topic.