 Block cipher operation is about how to use our block ciphers, like DES, AES and others, but how to apply them to input plain text which is longer than the block. So our blocks, for example, for DES are 64 bits long, but of course we want to encrypt something which is more than 64 bits. So one obvious approach is to apply DES on each block of input plain text and get output cipher text, but there are more advanced and more secure approaches, and that's what this topic is about. And generally these approaches are called modes of operation. So there are different modes of operation that we can use for different ciphers. We saw an example list last week, so when I did some encryption on the command line we saw the impact of using one mode of operation. We'll repeat an example, a different one, but illustrate using two different modes of operation and how one of them is not very good. And you don't have this, but I'll just explain as we go along what I'm going to do. I have a picture. I have a picture I want to encrypt. So the SIT logo. It's a bitmap. What's a bitmap? It's a format of a file, and what can you describe that format? It's binary, yes. It occupies a lot of space. Why does it occupy a lot of space, or why would a different format not occupy a lot of space? It uses no compression. You can think it's a raw form of the image. I think we know images are pixels. I don't know if I can zoom in far enough to see pixels, so we can see that if you keep zooming in, you see an image is really a sequence of pixels. So we have a resolution, so a cross and down, and a pixel at each point, where a pixel is just a color. So in this case, each pixel is a particular color value, and to store that in a digital form you store usually three values, red, green and blue. So I'm not sure, I think it's maybe 8 bits per pixel, or maybe 16 bits per pixel, sorry, not per pixel, per color. So 8-bit color would be each pixel is represented by three 8-bit values, and those three 8-bit values tell us the color of that pixel. Not so important, but just be aware that this is a raw form of an image. So I want to encrypt it. I want to take this image and encrypt it and send the encrypted image so no one knows what the original photo was or image was. So because our bitmap is really just the pixels that represent it as binary, of course we can encrypt it, we can encrypt any digital file, but we could also look at the encrypted form as a bitmap, because really encryption takes those bits representing the colors and changes them to other bits, which would correspond to different colors. If I encrypt this file and then view it as an image, that is view the encrypted form, what do you think it will look like? Can anyone imagine what it would look like if I encrypt it? What would you see if we looked at the encrypted image? Very messy, more scrambled, scrambled, okay? I think it's hard to describe, we'll see in a moment, we'll encrypt it and have a look. Now, for this demo example to work, be aware that a bitmap has two parts. There's a header that describes, so a few bytes at the start of the file that described that this is a bitmap, and then the rest, this one's three megabytes, so the remaining three megabytes are the actual pixels. So what I'm going to do is encrypt this file, take the ciphertext, and when we encrypt it, we actually encrypt the header, and for this demo to work, I don't want to encrypt the header, so I'm going to replace the header. It turns out I found out it's 54 bytes at the start of the file I'm going to replace, but that's just a small trick to make the picture viewable. Let's encrypt first and see what I mean. Let's close that. What will this command do? Generate a random number, 8 bytes long, and output in hexadecimal format. 8 bytes is 64 bits, which is the key length that we need for, I'm going to use des, just as a simple example. And it turns out, and the lecture today will introduce these different modes of operation, and they use not just a key as input, most of them also use an initialization vector, so we'll explain that today. But I'll need two random numbers. There they are, I'm going to use them. And now let's encrypt. Encrypt using des, and I choose the mode of operation. And the most basic mode of operation, and we've seen it before, is this ECB, electronic code book. You just take the input plaintext, break it into blocks, encrypt each block at a time. And the output of each encryption is combined to produce the ciphertext. We concatenate at the end. We'll see a picture of it later, but let's do it. Minus e to encrypt, and I'll output something called ECB because I'm going to show you another mode of operation and compare them in a moment. And the key, so I'll take one of them. And the other parameter is called the initialization vector, and I'll use the second random number for that. And I add the option no padding, we don't understand too much about it. But the idea is that we will not add any padding at the end if it's a different size to fill out the space. But it's not so important in this case. Okay, encrypted, let's try and look at it. First, let's look at the files. The length of those two files, so the input SIT logo was about three megabytes, this number. And of course the output ciphertext, the encrypted one, the ECB one, is also exactly the same size, we'd expect that, same input. The ciphertext is the same length as the plaintext, especially when we use no padding. In some cases, if we have some padding, the ciphertext may be longer than the plaintext. Now let's try and open that picture. EOG is the eye of known as just my graphics, my image viewer on my computer. And it tells me something's wrong, it won't let me open it, okay? It says that the header is bogus, or it contains bogus data. That is the format of this image, my image viewer doesn't recognize it, okay? That's because a bitmap has a 54 byte header, then the data. And because we encrypted everything, we rearrange those bits in the header so that my software doesn't recognize it. So I'm just gonna do a trick and replace the header with a known good header so we can open it and view it. This part's not so important. I'm just gonna split the file into two parts. The header, the first 54 bytes, and then the tail is the last 3, 3,9,314 bytes, and I've done something wrong. Three dashes, why didn't you tell me? Follow along. And I've created a header before, okay? So this part's just so I can open it in the image viewer. So my software recognizes it. I created a fake header that will work. It's only 54 bytes, let's hope this works. I'll just delete the old ones, which we don't need anymore. And now we have our proper encrypted image, ECB.BMP, which has the right header. So when I open in my image viewer, it will actually display. What's it gonna look like? What do you expect? Scrambled, okay? If we encrypt something, the output should be random. So in terms of pixels, we should get a random arrangement of pixels or colors. So each pixel should be a random color. Let's not look at it yet. Let's encrypt using a different mode of operation. So we did it in one way and I'll do it again, but change it a little bit. In both cases I'm gonna use desks, same key, same initialization vector, same input plain text, but I'm gonna use what's called a different mode of operation. It's a different way to combine each block. The first one was called ECB, the second one is called CBC. And our lecture slides will explain both of them, but let's just do it and see what the result is of using two different ones. I need to replace the header on the second one as well. So now I have the input plain text, our SIT logo and two different ciphertexts. One was using desks with the ECB mode of operation and one was using desks with a different mode of operation called CBC. And again, we expect to get some random looking output which in terms of colors, each pixel should be a random color. Let's have a look at them now and compare. So there's our original plain text. This is using CBC. Okay, so when we think of random colors, this is what you get, right? So this was using the second approach, CBC. If you look at each pixel and you look at the color and we could even look at the binary form and we would see it's just random zeros and ones which create one of the possible colors in that system. So all it is is just noise in terms of an image. So that's what we'd expect. That's good. If we encrypt something, the output ciphertext should be random. We can visualize random in this case via colors. What about using the other approach? That was CBC. The first one was ECB. There's our logo. That's ECB. This is the ciphertext from encrypting our logo using a different mode of operation and using the very basic mode of operation. Is it good? Why is it not good? It's not random. We can see some structure in the output ciphertext. Any ciphertext that has some recognizable structure is not good. The encryption did not do its intended job. And it's not because of desks. Desk works fine. It's because of this mode of operation called ECB. And we saw it last week. ECB just takes each block of plain text and encrypts it and then joins or concatenates the output ciphertext blocks. The problem is that our input image has many blocks on input which are the same. For example, many white pixels in a row. They correspond to a block. And when we encrypt them, we get the same pattern output. And that repeats many times. So we get repetitions in the output. And it doesn't work very well in this case. So this is just one other example that ECB is not good with large input plain text. So people design different modes of operation. CBC being a very common one. So let's more formally look at those different modes of operation. There are many. And most of the modes of operations work for different ciphers. My example, I use them for desks. But they could also be used for AES and other ciphers. Often the modes of operation are independent of the actual cipher being used. So we can combine them. We will look at two or three today, but there are others. And in some cases, there's other better ones, but just some simple ones that we can describe. And a couple of them are commonly used. We'll not go through all of them. The idea is a guarantee to get no pattern in CBC. Very close, yes. Unless there's some very specific cases with the structured input plain text short values, we'll see the operation that why it would mix things up more than ECB. We don't have hard guarantees sometimes, but we can say with high confidence that it's going to work as expected. Just a reminder, the idea is to take a block cipher on its own, takes a fixed-length B-bit input and produces a B-bit ciphertext. Like desks operates on 64 bits. AES also. So when we want to encrypt plain text longer than B-bits, we need to break the plain text into blocks, maybe pad if necessary. Padding would be, let's say, the last block, only has 30 bits. But our cipher uses 64 bits, so maybe we can add some zeros at the end just to fill it out to get the full 64 bits. And then apply the cipher on each block. But there are different ways to do it, and they're called modes of operation. ECB is short for electronic code book. The idea of you just look up the value in a book, that's the idea. And we saw a picture of similar... What we do, if we have plain text input, we break it into n blocks. P1, P2, up to Pn. So that's our plain text input. All we do is we use our cipher to encrypt each plain text block, P1, using our key k, and we get the ciphertext C1 as output. Then P2 is encrypted using the same cipher, the same key, and we get C2 as output. We keep doing that for our n input plain text blocks, and the result, those n ciphertext blocks are concatenated together, joined together. So take the plain text, split it into blocks, encrypt each block, and join each of the resulting blocks to get the ciphertext. We saw an example last week also when we encrypt a short message. If there's two plain text blocks, which are the same, P1 is the same bits as P2, and of course the key is the same, then the ciphertext will be the same. And that's our problem in using ECB. That's this picture. We used ECB. There are many instances when the input plain text block was the same, so we get many output ciphertext blocks the same, and that arises in some pattern in the final resulting output ciphertext, and we can actually visualize the pattern here. So it didn't work very well at all. So the obvious approach is not secure. It's very simple. I will not go through much. The decryption, you just need to make sure that you get the original plain text back. So decryption in this case is that you take the ciphertext, each block, C1, you decrypt using your cipher, for example, DES, and the same key K, and you'll get P1. So that's the inverse operation in this case. So let's look at some other modes of operation which are more secure than ECB. So the problem with ECB is with a long input message, repetition in the plain text will cause repetition in the ciphertext. That's bad. It's okay if we have short messages so that there's a very small chance to get repetition in the plain text with short messages, so it's not a problem there. But with anything long with multiple blocks, it's not good. So CBC is a common mode, and that's the other one I used in my picture example, cipher block chaining. Let's look at that. Again, we take our plain text message, split it into n blocks, P1 through to Pn. Here we introduce a new input value, IV. IV is sure for initialization vector, vector because it's really just a sequence of bits, a vector of bits, we can think of it, and it's for initializing the chaining that happens here. So it's common in other modes of operation, in fact, in other cryptographic operations, an IV or initialization vector. How does it work? Take our first plain text block, P1, XOR, this is the exclusive OR operation, XOR that plain text with our initialization vector. That will give us another value, and we take that value and encrypt that output of the XOR using our secret key, we'll get C1 as output. The next plain text block, P2, we XOR that with the previous ciphertext block, not with the initialization vector again, but with the ciphertext that come out from the previous iteration in this chain. So we take C1, XOR it with P2, and then encrypt the output of that value, and you get C2, and you keep going. You take the output ciphertext block from the previous iteration and use it as the input to the XOR in the next iteration for the next plain text block. Right, this is just the exclusive OR across the bits of the IV, say with desks, when we're using 64-bit blocks, it'd be 64-bits of P1, XOR with a 64-bit initialization vector. We'll get 64-bits out. Now apply desks and encrypt those 64-bits. We should get a random output with our strong cipher, the output here will be random. So C1 is random. Now XOR C1 with P2, and then encrypt that and so on, until we get our n ciphertext blocks and just combine them to get our resulting ciphertext. There's some chaining happening in that one iteration depends upon the previous iteration. We connect them together. That's where the chaining name comes from. What if there are two plain text blocks which are the same? What if P1 equals P2? The same sequence of bits. Will the ciphertext blocks be the same? That was our problem with ECB. If P1 was the same as P2, since we encrypt the same input plain text using the same key, we'll get the same ciphertext C1 and C2. We don't want that. This avoids that problem. If P1 is the same as P2, what do we get? P1, XOR with the initialization vector. We encrypt that, we get some output C1. P2, which is the same as P1, XOR with C1. The only way that C2 and C1 will be the same is if the initialization vector and C1 are the same. If IV is the same as C1, then C1 and C2 will be the same. If they're not, then C1 and C2 will be different. To get the same output from this encrypt stage, we must have identical input. So at this point, the input is IV, XOR, P1. At this point, it's C1, XOR, P1, if P1 and P2 are the same. So the only way that the inputs will be the same is if the initialization vector is C1. So what's the chance that the initialization vector will be the same as some random ciphertext C1? Very rare, very unlikely. Especially if we choose the initialization vector to be random. In fact, we don't need to in this case, but we will for secrecy. So it's almost impossible that C1 and C2 will be the same in this case. So it's not guaranteed, but practically impossible for them to be the same. So that's the benefit of chaining together. That is, two different inputs will not lead to the same outputs, because the second input depends upon the output from the first one, which should be random. And the reason we need an initialization vector, because you see in general, the general approach is the input plaintext block, XOR with the previous ciphertext. In the first step, in the first step, we don't have a previous ciphertext. So we use the initialization vector that initializes that first iteration. Questions on CBC? We, yes, we need to wait. So the iteration two, we must wait for iteration one to complete to do that. Can we do better? So you're right, that is a limitation of this. With ECB, to calculate P2, sorry, this is decryption, one side back. To calculate C2, you only need as input key and P2. You don't need to wait for the calculation of C1 to complete. So effectively, encrypting with ECB, you can do in parallel. You could be encrypting P1 at the same time, let's say on one CPU or on one core of your CPU, and at the same time, be encrypting P2 because the inputs do not depend upon each other. So we can perform these operations in parallel. If you had, say, a quad core computer and you were using all of those cores, you could be encrypting four blocks of plaintext at a time. With CBC, you can't do that because to encrypt P2, you must wait for the output of the plaintext P1 to be encrypted. So you can't run it in parallel and that's a performance problem of CBC and some of the others. Just to make it clear that why the chaining helps, let's consider the case. The case of using CBC where P1 is the same as P2. Our two input plaintext blocks are the same sequence of bits, see what we get. We take P1 XOR with IV and then encrypt. So the first step is let's say we get X is P1 XOR with IV and then we encrypt X. And then we encrypt X. So encrypt the result using secret key K and the output of that encryption is C1. Plaintext XOR with the initialization vector. The result of that X, I'm calling, we encrypt that result using our secret key and our cipher, DES or AES or any other cipher, block cipher, and the result is C1. This was in the first iteration. Now for the second iteration, we take our plaintext. What's our plaintext in our second iteration? P2, but in fact in this case, let's assume P2 and P1 are the same. So I'll write it as P1. So we're doing this step now. We've just done P1 XOR IV encrypted and we get C1. Now we do P2 XOR with C1. But in this example, let's say P2 is the same as P1. So we'll get P1 or P2 XOR with C1. Gives us out, maybe I should give it a number. Sorry, X1, our different X value, X2. And then what do we do to get C2? We encrypt using the same key K, X2. This is the operation on the second iteration or on the block P2, where P2 equals P1, just for this example. Now the question is, does C1 equal C2? With ECB, it was the case that plaintext inputs are the same. With ECB, the ciphertext outputs are the same. In this case, does C1 equal C2? Or better, under what conditions? When does it equal C2? C1 is encrypting X1 with key K. X1 is in fact P1 XOR with IV. C2 is obtained by encrypting here with key K, same key. X2, where X2 is P1 XOR C1. So now, under what conditions does C1 equal C2? The same keys, P1 XOR something, P1 XOR something, it's when those two somethings are the same. If the initialization vector is the same as C1, then C1 equals C2, which is what we don't want. But the result C1, how is it obtained using encryption? So we can think C1 is really a random value. The chance that our initialization vector is equal to that random value is very, very low. So there's a chance, but it's practically impossible that IV will equal this random value C1. So practically impossible for C1 to equal C2 in this case. So that's why CBC doesn't give two ciphertext blocks the same when we have two input plaintext blocks. Any questions on CBC? Yes, there is a question, it's in the quiz, okay? So the quiz that you're gonna do, can we use two different keys? No, we don't in CBC. That's achieving something else. If we use two different keys, then effectively we have a different algorithm and we're using a double the key length, okay? So that's not what we're trying to do here. We're trying to use just the one key and the same cipher, but do it and have it work on a larger plaintext input than a single block. So there will be a question on CBC or one of the other modes of operation in the quiz, but it's only on short plaintext blocks, like three or four bits. So you need to do these operations so you'll get some practice in the quiz or you'll practice beforehand. Decryption, always remember decryption must be the operation that gives us the original plaintext. We take an encryption, the plaintext, XOR, encrypt, so sorry, wrong way. To decrypt, we take our ciphertext, decrypt using des or our other cipher, same key, and then XOR with our initialization vector to get P1. Remember a property of XOR is that, what is it? We go in the opposite direction, we get the same result. A, XOR, A, XOR, B, XOR, B equals A. Or A, XOR, B, XOR, A equals B. So check those properties of exclusive OR and you'll see that if we exclusive OR the output of our decryption with our initialization vector will get our original plaintext back because this output of the decryption here corresponds to, if we go backwards, think going up, C1, decrypt, corresponds to this point. So XOR, this value with IV gives us plaintext P1 back. Maybe I stated that property wrong. A, XOR, B equals C, C, XOR, A equals B. That's the property that we use here. If A, XOR, B equals C, then it also follows that C, XOR, B equals A. And similar, C, XOR, A gives us B. So if we do an XOR operation and get some output C, if we take that output C and XOR with one of the inputs we'll get the other input. Try it. Try XOR on your truth tables of zero ones and you'll see that that's true. And it's because in this case, what is C, A, XOR, B? C equals A, XOR, B. So if we substitute that, A, XOR, B, XOR, B again, the B's cancel out. I'm sure you've done this in second year. You may just not remember. XOR has this nice property that the inverse is itself. We'll look at briefly one or two other modes of operation. CBC is commonly used today. It's still used mainly for file encryption. So it's one of the options that is used and considered secure. There are a few other options. So if you want to encrypt a large file using DES or AES, then CBC is one common option. The initialization vector is usually kept secret from the attacker. So it's actually a new secret value. And when I did the encryption on the command line, you remember I generated two random values, the key and IV. When I encrypted using DES, CBC, in this step, I used a key, it's random value I generated earlier, as well as initialization vector that I generated earlier. So we'd generally create that as a random value and we'd keep it secret. So now we actually have two values to exchange with our partner for this to work. What about some others? Let's jump to the counter mode and then we'll go back to the other feedback modes because the counter mode's easy. Counter mode is very simple. We just encrypt a counter. In each iteration, we increment that counter. So let's say counter one is set to zero, so 64 zeros if we're using a 64 bit block. We encrypt that counter value using our secret key and our cipher. We get some output cipher text and again, if our cipher is good, then the cipher text that comes out of this encryption should be random. Encrypting something should produce a random output. We take that random output and simply XOR with plain text P1 and again, the one-time pad tells us if we XOR some plain text with a random value, we'll get a random output. That was the security of the one-time pad depends upon that. So we take a structured counter, structured at can be zero in this case. Encrypt, we get some random output, XOR with our plain text, we get C1. To handle P2, we increment the counter. So counter two is the value say one, if we started at zero, one, two, doesn't matter. But we just increment, encrypt the next value in the sequence, get some random output, XOR with P2 and get cipher text. Very simple in this case, all we do is increment the counter and encrypt that and XOR and XOR in terms of operations is quite fast to perform. This is generally considered secure, it works. What's an advantage of this compared to CBC? Why can this be better than CBC? It doesn't need to wait. To do plain text P2, you don't need to wait for plain text P1 to be encrypted. There's no chaining between the iterations. So you can again do things in parallel or do things in advance. So while you're, again, if you have multiple cores on your CPU, on your computer, then you can be encrypting counter one and at the same time on a different core or a different CPU encrypting counter two. So do them in parallel and then the XOR as well. So you can implement this much faster if you have the ability to do so on the hardware. So it's commonly used in situations where they need fast encryption, like streaming data. Maybe you're sending data from your computer across a network and as it's generated, it needs to be encrypted. So this has the advantage is that we can encrypt some things in advance, the counter values in advance and as the plain text is generated, just XOR it with the output of those encrypted counters and we'll get our cipher text and can be sent. So performance is the advantage here. Look at decryption. What's the difference? Nothing in terms of the algorithm. Encryption, we take the counter, encrypt, then XOR with P1. Decryption, take the same counter, encrypt and XOR with C1. Again, this is using that property of XOR and we'll get the original plain text. So this is another advantage is that encryption and decryption are the same operations. And in fact, we don't use the decryption mode of our block cipher. That is, say for AES, for example, encryption in AES is different than decryption. There are some slight different operations. In this case, we don't use the decryption mode of the cipher and that can be an advantage when we don't need to waste the effort or the implementation effort on using the decryption mode. Whereas with CBC jumping back, to encrypt, you use the encrypt mode of your cipher. To decrypt, you use the decrypt mode of your cipher. So differences in terms of implementations, counter mode. And it's commonly used as a stream cipher like when we want to stream bits across the network encrypted. So it has the performance advantage there. Useful for high speed requirements. And it's good in terms of implementations. Any questions on counter mode? Again, quiz question on counter mode. I think the quiz questions may cover those three, ECB, CBC and counter mode. So I suggest when you take the quiz, have these slides there so you can look up the algorithm and just try the steps. Maybe you want to try an example in advance though. We'll go through one more. Cipher feedback mode. What's the difference between a block cipher and a stream cipher? Again, maybe in the quiz. What's the difference? Block cipher versus stream cipher. So far we've talked mainly about block ciphers, but we said something about stream ciphers in one of the earlier lectures. Maybe look for the slide that says the difference between a block cipher and a stream cipher. Just to remind yourself. What's a stream cipher? Stream cipher. The easiest way to remember is the block operates on larger plaintext pieces at a time. A block usually is on 64 bits, 128 bits. A stream cipher is usually on one byte, sometimes just on bits. But the implementation is that a stream cipher usually generates a random value and exhores that with the plaintext. And in fact, a counter mode really generates a stream cipher. It uses the block cipher here, like DES or AES, but the overall effect is a stream cipher in that we use our block cipher to generate a random output. Cipher text is like a random number. And then just XOR with the plaintext. And again, the advantage is in performance. All I do is generate the output of each encrypt block as plaintext is generated by my computer. And I want to send it across a network to stream it, for example. Then all I do is my computer takes a eight bits of plaintext or longer or shorter and exhores with the corresponding bits here of the output and gets our cipher text. And XOR in terms of implementation is very, very fast. So hardware can do that very quickly. So a very small delay in encrypting using counter mode and similar stream ciphers. CFB, cipher feedback mode and also output feedback mode also convert our block ciphers into stream ciphers. CFB, we take an initialization vector, IV. Encrypted using DES or AES or our other block cipher. Let's say we get 64 bits out. We take the first S bits, S maybe eight. We discard the remaining bits because what we want to do is encrypt just a small sequence of bits of plaintext at a time. S bits in general, or is that an example? Let's say S is eight, the block is 64, so we discard 56 bits. So this is using a 64 bit block as an example, but only encrypting eight bits of plaintext at a time, which is like a stream cipher. And we just exclusive or the plaintext with the output S bits here and get C1. And there's some feedback that is that C1 comes up. This is a little bit different. Our initialization vector, we can think of as stored in a register, say 64 bits. Then we shift it along to the left. So the initialization vector, we take it. And in the next iteration, we shift it to the left. The last S bits, so that the end on the right are replaced with C1. And the left most bits are shifted and thrown away. So a shift register takes these values in here and moves them to the left. Those on the left will be discarded. Those on the right will be replaced with, or the empty ones on the right will be replaced with C1. This generalizes that B and S, as an example, B could be 64 bits, S could be eight bits, a common implementation. Then we do everything the same again. Encrypt, throw away the right most bits, take just the left most S bits, XOR with P2. We get C2 and C2 will come into our shift register and push everything along. Again, we're using the ciphertext from a previous block as an input to the next stage so that we don't get the same ciphertext output. And as an additional thing where we're just using some of the bits that come out from the encryption, really for performance reasons. If we want to only encrypt some bits at a time for speed, then we just select those S bits that we want to encrypt. This really makes a stream cipher. Questions on CFB, this one maybe, I don't think it's in the quiz, there's no detailed example in the quiz, but just to understand it, you may wanna try it on a simple example to see how the shift works. Let's draw that, I think that may have confused some people. Let's just explain the shift register part of it. Let's say IV was some random eight bits. Instead of 64 bits for a small example, let's say IV was these eight bits. Then when we applied our encryption block with the key, we got some output and then we XOR with the plaintext P1 and we get C1 as output. Let's say C1 is just two bits and it turns out to be one one. So we'll not do the actual encryption, I'll just use an example where we know the input initialization vector and after the first round we get C1 to be one one. Then what happens in the next round, the shift register, we're gonna encrypt with key K, we take the initialization vector, we're gonna take these six bits, we're going to discard the first two. Those six bits will move along to the left and the last two bits in the input are taken from here. That's how the shift register works. That is these eight bits are shifted to the left by S positions in our example S is two bits and we get those six bits and the last two bits are replaced with C1. So C1 feeds into the next iteration, we encrypt and then continue just illustrating the shift register which can be confusing. So again, each iteration uses the output of the previous iteration. So we have some chaining in this case, we refer to it as some feedback and we have converted a block cipher like AES or DES, this E step in our picture into a stream cipher by just selecting some of the bits to use for the XOR. And the idea of encrypting only a small bit, small set of bits at a time is it's faster. We don't have to wait so long. That's the decryption. There's a variation of that called output feedback mode. Similar, we encrypt a value XOR with P1 and the feedback in this case, instead of C1 going into the next stage, the output of the encrypt goes into the next stage. Maybe hard to see but here in CFB, what goes into the next stage, C1. With OFB, what goes into the next stage, not C1 but the step before the XOR, the output of the encrypt goes into the next stage. This has some minor benefits in terms of if there are errors in the transmission, the errors are not propagated so far but only useful in certain communication links. Maybe the one thing that's worth introducing here what's the name of the input to the first encrypt, nonce, what's a nonce? We've mentioned an initialization vector here but now it's called a nonce. So it has the same role as the initialization vector, it's that first value that we need to get started in this first iteration because each iteration takes the input from the previous one but of course the first iteration, we don't have a previous one so we have some initial value to use. Here it's called a nonce. Same, it's also referred to as initialization vector. What does nonce mean? Nonce means a number used only once, number once. So that's the idea here. We choose some number, it may be random, it may not be and we only use it once. And a nonce comes into play in different security mechanisms we'll see through the course. So just remember, nonce means some number we use only once. Sometimes we'll choose a random number, sometimes it can be a sequence number and we will not use that sequence number again. We can increment it. But in this case it's, you can think of it as simply as the initialization vector. That's all I want to say about modes of operation. There are others, but I think the main three that we've mentioned a bit more on, ECB, not secure because the input plain text repetitions lead to output ciphertext repetitions. CBC is commonly used and counter mode, we went through a little bit more depth than the others. It's also used especially in network communications. The others are used and there are others as well. Some of the other, the remaining slides which will not go through, give further examples. Questions on cipher modes of operation then we shall continue on to the next topic.