 The classical encryption techniques that we've introduced are just there to illustrate some of the concepts used in encryption. The classical techniques were first, the Caesar cipher is maybe 2,000 years old. And the other ones used in the maybe the vision air cipher in the 1900s, early 1900s, early last century. So they're quite old, before computers. So now we have computerized algorithms. We're going to operate everything, not on English characters. We're going to operate on binary characters. So we're going to operate on zeros and ones. So all of our examples from now on, we'll be looking at bits. And we're going to move into the real ciphers, the one that have been used, I guess, over the last 40 years and up until today. And we're going to use DES, the data encryption standard as a detailed example. I'll then mention a few other ciphers. And these are real ciphers being used for computer-based encryption. And we're going to focus on block ciphers. So let's talk about what we mean by block ciphers. In fact, we can split our ciphers into two types, block ciphers and stream ciphers. First, what is the difference in simple view? It's the amount that they encrypt each time. Our encryption algorithms don't encrypt the entire file at once. They operate on usually a fixed length of bits or bytes. And the difference between stream ciphers and block ciphers, one part is that stream ciphers usually operate on a small number of bits at a time. Block ciphers on a slightly larger number of bits. A stream cipher normally encrypts either one bit or one byte at a time. So we take a byte of plain text, encrypt it, and then apply the same encryption algorithm on the next byte. And the same algorithm on the next byte. And keep going to complete our encryption of a file or a stream of data. A block cipher, we'll see on the next slide, does the same thing, but it operates on slightly larger set of bits. Usually 64 bits, 8 bytes, or 128 bits. So it's the length of input which they operate on. But the algorithms used to do the encryption have been designed slightly differently such that the stream ciphers, the aim was to do the encryption fast. So a stream cipher encrypts a stream of one bit or one byte at a time. So you can think, we've always got data we want to encrypt. It's coming in, a stream of bits are coming in to our encrypting device. And the stream cipher needs to encrypt those bits as fast as possible so that the cipher text comes out. And people design the algorithms to do the encryption such that it was fast. Fast compared to the block ciphers we'll see in the next. And the common approach that was used for stream ciphers and still is, is that we have plain text coming in. I think a continuous stream of bits coming in to encrypt, we have a key. We have some algorithm that generates from that key a random stream of bits called a cryptographic bit stream. But essentially takes this key and generates random numbers as output. So to encrypt, we take the plain text bits, the random number represented in binary and exclusive all the values, XOR. And what comes out is a cipher text. The benefit of this approach, if you have a good algorithm to generate random bits from a key, is that exclusive or is very fast to implement in hardware and software, okay? So when we have plain text coming in and we want to encrypt it in real time, maybe we want to encrypt a voice call as someone was speaking. They're generating bits for them from their voice. They speak into their speaker on their phone. Their phone converts that to bits. And then the software needs to encrypt those bits before they're sent across a network. Then that needs to happen quickly so that there's small delay to get the data to the other side. And using an exclusive or here is, is one of the fastest things that we can implement for in our computer. So the design was to be very fast. It depends upon this algorithm for generating random numbers. And we have a topic on generating random numbers, and it's not as easy as we may think sometimes, okay? And it will depend upon not having to reuse the key many times. So we will not study stream ciphers yet. When we return to random numbers, we'll look at how to generate random numbers. XOR is easy. So we'll return to that. But the idea, encrypt fast. Usually a bit or a bit at a time. If you remember your computer hardware or basic computing concepts, you'll remember XOR, exclusive or, and we'll see that if we encrypt using exclusive or, the algorithm to decrypt is also an exclusive or. That is, if we take some value XOR with a plain text and we get the cipher text, to get that plain text back, we simply XOR with that original value that we used. And we'll get the exact correct plain text back. So that's one nice property of XOR. We can use it for encrypt and decrypt. But we're not going to talk about stream ciphers today. We're going to look at the other approach, block ciphers. Usually operate on blocks of data, 64, 128 bits long. And we apply an encryption algorithm on that block of bits, again, using a key. And we get a block of cipher text that come out, same length as the input plain text. So we need to look at what is this encryption algorithm. The design of such algorithms was made such that they generally slower, or at least in the past, were slower than stream ciphers, but had a few less limitations in terms of the security and the key reuse. And we compare them later. So block ciphers were really designed for encrypting files. You have a file on your disk, you want to encrypt it. The time to encrypt is not a big issue. You don't want to take days, but it doesn't matter if it takes one second, half a second. Whereas with a stream cipher, when you're encrypting real time data, the delay is very important. So the design was to be different in delay, the time to take to encrypt. We're going to look at block ciphers today and the next couple of topics. And we'll return to stream ciphers later when we look at random numbers. It turns out today with hardware and software speeds, many block ciphers are about the same speed of stream ciphers anyway. So you can use block ciphers to do real time encryption. So we're going to look at block ciphers. And what a block cipher does is if we have a plain text message, let's say a one megabyte file we want to encrypt, we don't encrypt all one megabyte The time we split it into b bits of plain text, chunks of b bits in length, where b will be a parameter of the algorithm, we'll see the first algorithm of des, we'll see b is 64 bits. We encrypt the first b bits of plain text and get b bits of cipher text. And then we encrypt the next b bits of plain text of our file and get some more cipher text and keep going until we finish all the blocks in the file. And we have a set of cipher text blocks. And then we join them together. And the simplest way to join them together is just to concatenate those values. But there are some other ways to join them together. So in this topic, we're going to not focus on encrypting a file, but encrypting b bits at a time. So we just look at the algorithm, we take b bits as input, a block, or n bits. So we say we have an n bit block cipher that takes n bits of plain text in and produces n bits of cipher text out. We also have a key, say a key of k bits length. If we have n bits of plain text, then there are two to the power of n possible different plain text blocks. And the table down the bottom gives an example of that. If our block length is two bits, just for a simple example, then there are four different blocks that we could have to potentially encrypt. That is, the possible values of plain text are 0, 0, 0, 1, 1, 0, 1, 1. If we have a two-bit cipher, a two-bit block cipher. If we have a three-bit block cipher, there are eight potential plain text values that come in. Two to the power of n here, that's all. So we'll see desk, for example, is a 64-bit block cipher. It can take two to the power of 64, or it takes a 64-bit input. There are two to the power of 64 different possible inputs that can come into it. And it produces 64 bits output, which is a cipher text. For encryption to work, the algorithm that's used needs to be reversible. That is, we need to be able to decrypt. It's no good if we can encrypt, get some cipher text, and then given cipher text, the key and the algorithm, we cannot get the original plain text. We must get the original plain text back. That's what we mean by reversible. And the two tables show an example. The left one is a reversible mapping, just an example where, let's say we encrypt using some key plain text 0, 0. If the cipher text is 1, 1 with our algorithm, if we encrypt at a different input, 0, 1, we get cipher text 1, 0, and so on for the last two, that's a reversible mapping, because if you have the cipher text and you decrypt using the same mapping, then you'll get a unique plain text as output. The right-hand table, that's not the case. If this is the mapping, and then you have the cipher text 0, 1, and you want to decrypt 0, 1, what's the output? What's the plain text? If you decrypt 0, 1, what's the plain text using the right-hand table? And 0 or 1, 1. We don't know. That's all. Reversible mapping means that we must get a unique value as output. So the right-hand table is not a valid mapping, or not a valid encryption algorithm if we do this. So we must have unique values here so we can decrypt. Let's look at the total number of transformations, but we'll use a different example to get to that number, 2 to the power of n factorial. Let's consider a block cipher. Let me bring it up. And I think you have the printout. In your lecture notes, you have this example, or if you don't, you will see it's quite simple. An example of an ideal block, two-bit block cipher. So to start with something we can write down, let's say we have a cipher that takes two bits in and produces two bits of cipher text out. Then with a two-bit block cipher, there are four possible plain text inputs. 0, 0 through to 1, 1. So I've listed the plain text inputs in this left column here under P. And when we encrypt, what we do is we perform a mapping. We map the plain text to a cipher text value, and that mapping is determined by a key. So what I've listed here, and I've had to split it across two sets of rows, is that for this plain text input on the left, 0, 0, 0, 1, 1, 0, 1, 1, a potential mapping is listed under K1. That it's possible if we take plain text, let me get an easier one to see, let's explain the picture and explain the concept with that. So we have plain text values that come in. What's the cipher text that comes out? Well, here's one potential mapping. So we have some algorithm. We don't know what the algorithm is yet, but it takes plain text in, produces cipher text out. One possible mapping is that we get these values out. If we encrypt plain text, 0, 0, cipher text, 0, 0 comes out. That's one possible mapping. The second column listed under K2 is another possible mapping. We encrypt, 0, 0, we get a cipher text out, 0, 0. But if we encrypt plain text, 1, 0, what comes out is cipher text, 1, 1. That's another possible mapping in that column there. And then I list all possible mappings, and it goes up to the right-hand side. There are 24 different possible mappings. And you see if you look at each of those mappings, they are different. That is, the ordering of 0, 0, 0, 1, 1, 0, 1, 1 differs in all of these 24 possible values. So if we implement a cipher, a very small cipher in this example, which takes two bits in, we could implement it just as a defining these mappings. And what I do, in K1, right. So the first column that is under K1, you notice that the cipher text that comes out is identical to the plain text. It's a valid mapping. So yes, if you use that mapping all the time, then that's not so good. But in theory, that's one of the possible mappings that's valid. Right, if we were to use this algorithm, we may say there are some mappings that you should not use. We could say the one with K1, that's a special case, don't use it. But in theory, it's one of the potential cases. But yes, you see that it's not a good one if we use it all the time, if we use that. If we have, so one of the 24 here, we know we get the exact same plain text, or the cipher text is exactly the same as the plain text. If we have a larger block size, we'll see that, yes, again, one of the mappings will be the same. But one of many, and the chance of getting that can be very low. The point with this example, there are 24 possible mappings, or 24 arrangements of those four values, 0, 0, 0, 1, 1, 0, 1, 1. And you know that from your basic statistics, or high school mathematics, it's the number of permutations. With four values, the number of ways we can arrange them. It's four factorial. If we had eight values, say a three-bit block cipher, 0, 0, 0, 0, 0, 0, 0, 1, and so on, so we had eight values, the number of mappings or arrangements we can have would be eight factorial in that case. Here we have four factorial arrangements, four times three times two times one, 24 arrangements. So what we could do to implement this block cipher is just to say, implement this as a table, a lookup. The mapping is determined by the key we use. So what I say, I've got some plain text, 0, 0, to encrypt. I choose a key. Let's say K5. If I choose K5, then to encrypt 0, 0, what comes out as cipher text is 0, 0. If I chose a different key, K17, for example, what would come out with the same plain text is 1, 1. So the way that we would use this, choose a key, encrypt our plain text, just looking up the table. What's the problem with our small example here with two bits, we see there are not many possible arrangements. And many of the times, in this case, one quarter of the keys produce the same plain text, or the cipher text is the same as the plain text. That is, with keys 1, 2, 3, 4, 5, and 6, if I encrypt 0, 0, I still get 0, 0 as output. That's not so good. We would like the chance of getting the same output as the input to be very low. Here it's 25% chance of getting the same output there. How could we make that chance lower? That is, given a plain text, get a different cipher text output, larger block size. And it's hard for me to draw if there are three bits, then there are eight potential values that come in. The number of arrangements is eight factorial. So there are many different possible arrangements. So the chance of choosing one that produces the same output as input is lower. So this suggests that we should use a larger block size. Two bits is too small. We use a larger block size, and people have come up to the design, this is one of the reasons block sizes of 64 bits are used. It's considered a reasonable trade-off. We'll say that later that we want to keep it small for other reasons. But for security, generally we need a large block size to encrypt with 64 bits. Let's write down those numbers. Here we had the block size was two bits. The number of possible plain text values is four, two to the power of two. And the number of possible arrangements, mappings, was 24. And the mapping can be selected by the keys. So in that case, we can say that the number of possible keys in this one is 24, or four factorial. If we increase the block length to three, we'd have eight plain text values and eight factorial possible arrangements, or keys. Calculator needed, 40,320. That is, I'd have to list 40,320 columns there instead of the 24 if I want to list all possible arrangements just with a three-bit block cycle. And if I choose one of those arrangements, well, no, that is the maximum number of possible keys that are available in that cipher. There are 40,320 possible keys because the key determines what the mapping is. If we increase the block size, let's say 64 bits, which is a realistic value used today, then the number of possible plain text that can come in are two to the power of 64, which is about 10 to the power of 19, right, 19 zeros, approximately, 10 to the power of 19. And the number of keys, the number of mappings, is two to the power of 64 factorial, which is approximately factorial. My calculator doesn't handle that number, OK? 10 to the power of 19 factorial, my calculator, my computer cannot calculate that. It's such a big number. My computer can, I think I tested before, 200 factorial is 10 to the power of 374. 300 factorial, it won't calculate. My calculator's not that powerful. It will give up. So 10 to the power of 19 factorial has got no chance. But it's a very big number. So the number of possible keys is very large, which is good. So this is a good block size in that we take 64 bits in, we get 64 bits out. There are many possible keys. And that's what we like in our ciphers. So the brute force attacks, the attacker can't guess a key. So it's good to have many possible keys. So we could design a cipher, what we call an ideal block cipher, by just defining a set of mappings. We design or implement as a table in software or hardware, say, if we have this plain text's input, these 64 bits, and if the user chooses this key, then we look up in the table and we say, what comes out is this 64 bits of cipher text. We'd look up a table in a similar concept to this. Implementing, and that would be secure, that would be a suitable cipher to define it as a set of tables from a security perspective. But implementing it is very hard. If we want to have 64 bit blocks, then we have two to the power of 64 possible values. So if we have a table that we need to store, there are 10 to the power of 19 rows in that table, which is, I think, millions of terabytes. If we want to store this table in memory on a hard disk, then we need millions of terabytes just to store that in our computer. And our computer that wants to encrypt something needs to look up that table of millions of terabytes and then find the right value and that returns the cipher text. Well, we can't implement that. We need too much storage space and to do the lookup would take too much time. So in theory, we can implement a cipher as a lookup to find the table of all possible mappings and then look up the cipher text given the key and the plain text. In practice, if we do it that way, we cannot implement it in reasonable space and reasonable time. Another practical limitation is the key length. This is the number of possible keys. There are 24 unique mappings. Therefore, we can have a maximum of 24 possible keys. We've said that with symmetric encryption, user A and user B must know that key. And they both must know the same value, so somehow they need to transfer it. Let's say we've got a magic way to send a key in secret across a network. So we need to send it across the network. How many bits do we need to send? So in the first case, if there are 24 possible keys, what's the key length? How long should a key be in bits? There are 24 different values. How many bits do we need to represent the key? Not two, not three. There are 24 values. Well, I'd need, if I had four bits in my key, I could represent 16 values, two to the power of four. I'd need five bits. With five bits, I can represent 32 values. I need to be able to represent 24 values. So my key length should be at least five bits. If my key length with five bits, then I can represent in binary the number zero through to 23. I can encode those decimal numbers in binary. I could say, okay, key zero, we encode as a five bit number, key 23, or the 24th key, we encode as a five bit number. That is log base two of 24. And then we want the ceiling of, well, not this, round that up essentially. Five bits. Four bits is not enough. Five bits is sufficient to do 32. That's fine. With that cypher, with a two bit block size, we have a five bit key necessary. So we could send that five bit key to the other user, okay. If it was three bit block length, we have how many possible keys? Well, log base two of 40,000. Again, I need my calculator. The number of bits needed to represent 40,000 possible values. Log of 40,320, what about log of two? About 15 or 16 bits, okay. With 16 bits, we can represent 64,000 different values. So that's enough to represent our 40,000 values. With 15 bits, we go up to 32,000 values, not enough. Again, that's reasonable. That's fine. If my key length is just 16 bits, two bytes. Very short, two bytes, I can send in a message to someone else as the key. And I can store that key on my hard disk. Two bytes takes up almost zero storage on my disk, fine. Our block size is 64 bits. Then we have two to the power of 64 factorial possible keys to represent that, all those values we need approximately. Well, log base two of two to the power of 64 factorial. That's how long the key should be to represent that many values. My calculator won't calculate that because it cannot calculate the factorial. But an approximation, or it's a little bit higher, but an approximation is that it's about, or it's a little bit less than 64 times two to the power of 64. N times two to the power of N, N is the block length. Which is what? That is my key, when I store it on my disk or when I send it to someone else, it must be about 64 times two to the power of 64 bits long. 64 times two to the power of 64 bits long. Convert to bytes, I'll divide by eight. So that was the number of bits, about 10 to the power of 21 bits in length. Divide by eight to convert to bytes. Divide by 10 to the power of 12 gives us what? Terabytes. Gigabytes is 10 to the power of nine. Terabytes is 10 to the power of 12. That's how many terabytes I need. That is my key that I'm going to use to encrypt should be about 147 million terabytes long. I need to save that key on my disk because I need to remember it so that when I can receive a message and decrypt and what's more I need to somehow give that key when I choose it to someone else. Maybe send it across a network or write it on a piece of paper and pass it to them. How do I communicate 147 terabytes to someone else? Not possible again. Our key length is too long. If we want to use this approach of using a table lookup where we just define a mapping based upon the key, then there's a number of practical problems. The key length is far too large. 147 million terabytes. So we need about 147 million hard disks to store your key. And we'll see later a good thing with keys. We should change them quite often. So we need to change them on a regular basis. So it's just not practical there. We can't store the table in our hard disk either. So this approach of using the mapping is called an ideal block cipher. It's the ideal way to do it from a security perspective, but from an implementation perspective, it just won't work. The numbers are too large. Key is too large. The storage space for the table is too large. Any questions on these calculations before we go back to our slides? We calculated, given a block size, how many possible plain text values there are? Fine. How many possible arrangements of those plain text values are there? How many permutations, which determines the number of keys or mappings? And then given the number of possible keys, we need to be able to represent that key as a binary number. So we calculated how long should that binary number be to represent one of those keys? Because somehow we need to get the key to someone else and store it on disk. If the key is too long, like 100 millions of terabytes, then we cannot use this approach. We cannot use a 64-bit block cipher because the key length is too large. But if the block size is too small, we have problems in that we'll always get the same block and we'll get many repetitions. And repetitions are bad when we encrypt because it gives some structure in the output. And we'll see that some more details of why the block size is too small today. So we want a large block size for security, but we want a small block size to make it practical to have a small key length. So an ideal block cipher doesn't quite work. We need different designs. We need a design that allows for a large block size, up to say 64 bits, and allows for a small key length. Maybe again, 64, 128 bits. So that was an example of an ideal block cipher where we just map our inputs to outputs. And the example, I think, is enough. There's a few slides to explain it further, but that example makes the point that we want to have the problems with an ideal block cipher. We want to have a large block size because if you have a small block size, you get many repetitions. You get the same output all the time. And it makes it easier to do attacks if you use a small block size, like two or three bits. But if you use a large block size, we get a very large key. And we can't transfer that to someone else and we can't save it, so implementation becomes a problem. Hence, ideal block ciphers are not used. People have designed different approaches to deal with those trade-offs. That's just another example of ideal block cipher. So people have designed different approaches that try to be just as secure as an ideal block cipher, but much more practical to implement. And there are different designs. But one of the key design approaches was created by a guy called Feistel and he designed a general approach for block ciphers and it's used in a number of different ciphers that are used today or have been used in the last 30 years. It's called the Feistel structure. And we will go through one example of its application in what's called the data encryption standard. So Feistel's idea was to, rather than use an ideal block cipher, allow for a short key, right? 64 bits maybe, 128 bits, but short enough to save on disk and to send to someone. But to get the same strength as an ideal block cipher or close to. And what the design does is take some simple ciphers and applies the multiple times and repeating ciphers using different operations. And we saw with classical ciphers the two operations are transposition and substitution. We look at the Caesar cipher, Vigenere is a substitution cipher and then the rail fence and rose columns were examples of transposition ciphers. So these two basic operations are used in the Feistel structure where you take, you apply a very simple small cipher, small key length, small block size and maybe do a substitution. And then you take the output of that and do a transposition. And a transposition is also known as a permutation. We'll see that name used more commonly soon. And then you do it again. Another substitution and another transposition and do it multiple times with the idea that the output that comes out, the final cipher text, is just as secure as if you used an ideal block cipher. We will not go through the design, the general design in detail, we will see the example of it when we go through DES. So there's a few points about the approach of the Feistel structure but just be aware it was a way to design block ciphers and is used in many different block ciphers today. But they have a few variations of how they apply it. The key point is it applies substitutions and transpositions repeatedly. Doing that, the idea behind that is to introduce diffusion and confusion. And it's easy to introduce confusion into the lecture so we will not define them yet but we'll go through an example and then we'll try and explain what diffusion and confusion are. They're concepts that are important in ciphers. So rather than looking at the general Feistel structure, we will go through one example that uses the Feistel structure. Different schemes have different parameters, different block size, commonly 64 bits or 128 bits, different key lengths, 64 bits in the past days, now 128 bits and 256 bits are recommended. And the number of times you repeat the substitutions and transpositions, the number of rounds that we go through differs. So we'll see in desks and then in another cipher what those parameters are. And this is a time to highlight a key trade-off in ciphers. We want them to be secure. Our ideal block cipher would be secure if we implemented that but we want to be able to use them in a convenient manner. So performance is another trade-off and ease of use. So always it will come up. To get more security, we'll usually compromise on performance. That is it takes longer to encrypt or it's more to store and disk, more to transfer across the network. So a key trade-off that we have to deal with. We can't just increase the security with no losses. So let's look at the data encryption standard, desk. Desk is a symmetric block cipher. It takes 64 bits of plain text in and produces 64 bits of cipher text out. The key length for desk, and this will be a confusing thing that you need to remember, the key length is actually 64 bits. But eight of the bits are not used in the encryption algorithm. So sometimes you'll see the key length of desk referred to as 64 bits and other times we'll refer to it as 56 bits because eight bits are sort of unused. So we do take 64 bits in for the key but we throw away eight of those bits. They're actually used for a parity check. So from a security perspective, there's only 56 bits that the attacker needs to guess. So a brute force attack needs to just guess 56 bits. It's considered one of the most used encryption systems in the world. Even though it's no longer used, it was used for a long time. It was designed in the 1970s in the US by IBM and they developed an algorithm called Lucifer and they had input of the National Security Agency in doing that and eventually became a standard in the US. The National Bureau of Standards or now the National Institute of Standards and Technology in the US said, this is the algorithm that all government departments must use to encrypt their data. And because all the government departments do, all the companies use the same algorithm so that they can interoperate and other countries use it as well. So desks become widely used. The principles of desks are used in other ciphers as well. So we will go through how desks works but we can state now it's no good anymore because the key length is too small. With 56 bits, it's easy to do a brute force attack on it today. In the 1970s, no, a brute force attack wasn't possible but today with current hardware and software, then trying all possible keys, it's possible to do that in the matter of with some hardware hours or days. So from that perspective, it's not no longer used but the same algorithm has been used to make it more secure by using larger key lengths. Triple desks will go through or say that just apply desks three times using three different keys and some other algorithms also use the desk design. So we're gonna go through in detail the idea used by desks. The problem is we can't do any examples on by hand with 64 bits. It's hard for me to write down 64 bits and then do an operation on it. Takes too much time and I'll make too many mistakes. So to see how it works, we're gonna use an educational version of desks created by some people to just illustrate the concepts called simplified desks as desks. It's not used in practice, okay? You never use simplified desks. It's just used in teaching so that you can see the idea of how desks works and we can follow through some simple examples. So we'll go through simplified desks which is really just a shrunken version of real desks and then we'll come back to the real desks and say how it differs from simplified desks. And we'll encrypt some data with simplified desks. So let's look at the algorithm. Simplified desks takes eight bits of plain text in and eight bits of ciphertext come out and has a 10-bit key. It's longer than the plain text block just to make the steps in the algorithm work correctly. And it does some operations with the plain text and gets some intermediate output and then it repeats all of those operations again. So we say it goes through two rounds. Real desks goes through 16 rounds. It repeats 16 times. We start with a key and we generate some what we call subkeys or round keys. That is, we'll generate some keys that we use in different phases in the encryption. So there's a key generation algorithm. There's an encryption algorithm which we'll go through. The decryption algorithm is essentially the same as encryption but we go backwards, we'll see that. So what we'll do, we'll go through a key generation, use an example and then encryption to see the different operations used. This tries to capture those three algorithms all at once. In the middle are the steps used to generate keys from our original user chosen key. That is, the user chooses a 10-bit key. Then they apply some steps which we'll go through what they are. There's P10, shift, P8, shift, P8. The output of those two steps are two other keys which we call two subkeys or two round keys. K1 and K2 in the diagram. Why do we generate two subkeys? Because we said the encryption involves two rounds, two phases of do something, then repeat it and we'll use a different subkey in each round. RealDest does similar, it generates 16 subkeys. Every round it uses a different subkey but you start just with one original key. To encrypt, we take eight bits of plain text in, we do some operations, IP, F of K, using key one, a swap, the same F of K using key two and some last operation, we get ciphertext. To decrypt, we start with the ciphertext and we do the same operations as encrypt, almost. In encrypt, we start with this first IP operation. We'll explain what IP stands for shortly. To decrypt, we do the same, we apply the same function, we apply the same swap here, the same function again and the inverse operation and we get plain text. If you look closely, the blocks for encrypt and decrypt are the same. IP, F of K, swap, F of K, the inverse IP. The only difference is that we use K one and K two in a different order. For encrypt, we use K one, then K two. To decrypt, we first use K two and then K one where those values are the same. Let's go through it with an example. We'll refer to these slides as we go through the operation so I'll flick back through them. The example we're gonna go through is this one. That is, we're gonna take those eight bits of plain text. The user chooses the key, which is a 10-bit value. I just chose a random key here. And we're gonna encrypt that plain text and hopefully at the end of the example, we'll end up with those eight bits of cipher text. That's what we'll try and do. I'm gonna write it down. We'll go through each step and you can write it down but if you look, I hope I included at the end of your, at the end of the slides a printout of the example. Maybe I'll have a look. Because it's sometimes we, it's easy to make a mistake in writing down the bits. On page 95, you'll see the example we go through. The first thing we do, before we do any encrypting, we have to generate the sub keys or the round keys. We start with our original key, our 10-bit value and we're gonna from that generate two other keys and then use them in the encryption and decryption. So let's do the key generation steps first. So we start with the user chosen key. We start with what the key will denote as k and the value that we chose, those 10 bits, we chose them randomly, one, zero. And just to make it easier to see the bits or have a little bit of spacing. So that's the key that the user chooses. It's the same one on the slides, I hope. Yes, 10-bit value. And we need to generate two sub keys from that and the way that we do that is using these operations, P10, shift, P8, shift, P8. So we need to explain what they are or in more detail shown here. So this is the key generation algorithm. We take 10 bits in and the way that the arrows are marked, they show the number of bits we'll do and each will pass between each step. We apply an operation called P10. P stands for permutation in this. We do a permutation of those bits. Permutation is another word for transposition or rearrange. So what P10 means, we take 10 bits in and then we mix them up. That's, we do a permutation. That way that we mix them up is defined and fixed. We always mix them according to the same rules. So P10 is actually defined, we'll see on the other slides. It says move this bit to this position, this second bit to this position. So when you see a P, later we'll see P8. It's also a permutation. Remember from classical ciphers, substitutions and permutations. LS is left shift. So in binary we can shift the bits left. LS1 is to left shift by one position. Take your bits, shift them to the left where the left most bit becomes the right most bit. It wraps around. So like in hardware, we can do a left shift on our bits but the left shift takes five bits in and produces five bits out. So in fact, what we do is the output of P10 we split into two halves. P8 is a permutation. The shape of this box means that we're going to take 10 bits in and produce eight bits out. It's gonna throw away two of the bits but rearrange the rest. Left shift two is do a left shift by two positions to the left. Take our five bits, move them to the left. So left shift is a permutation as well. P10 and P8, the two P8s are permutations. Let's go through them. So we're just mixing up the bits. P10, I have to jump back between the slides is defined here. So it's defined in the algorithm. It's fixed, it never changes. The attacker knows what it is. The way to read it, we have 10 bits that come in. We label them, we can think the first bit, the second up to the 10th bit that come in in order. What comes out? The first bit moves to this position. The third bit of the input becomes the first bit on the output. The 10th bit on the input moves to the sixth position. That's all that's defining here. We take 10 bits in and we mix them up. How do we mix them according to this permutation? So let's do that on our 10 bits. We've got 10 bits coming in and in this case we'll make it clear, we'll say that let's label them. One, two, three. So there are our 10 bits that come in. When we apply the permutation P10, using the key as input, P10, it's going to produce bits that come out and from that slide, the third bit on input is going to move to the first position. The third bit on input moves to the first position. So that is a bit one. We'll be the first bit in the output. The fifth bit moves to the second position. We see the five here means the fifth bit from input becomes the second bit that comes out and the fifth bit was a zero. Zero comes out here and we keep doing that for the rest. What's the next one? Two is it? Bit two becomes the third one, which was a zero. So we're just mixing up these bits. Bit seven, which was also a zero. Bit four, we'll only draw this once. We will not do it for all the permutations but just to highlight the approach. Bit four was a zero. Three, five, two, seven, four and then the 10th, 10, one, nine, eight, six. Bit 10, nine, bit one from all over here. It's a bit messy. Eight and six. Bit 10 was a zero. Bit nine was a one. Bit one was a one. Bit eight is a zero and bit six is a zero. Please check that when I make a mistake, let me know. What we're doing is mixing those first 10 bits up. Defined manner, defined by p. Same way that the rail fence for the rows column cypher mixed up our letters. The rail fence that we wrote them in three rows, for example, and read off, it just rearranges that will permutates the bits. Yeah? No, p 10 is fixed. So p 10 is defined as part of, in this case, simplified desks and the same in real desks. There's a p, I can't remember the number but there's a permutation which is defined and always used this way. So the, whenever we take these 10 bits in, we'll always, in the first step, get these 10 bits. We'll always mix them this way. So we see that's very simple and you may question, well, is that secure? We're just mixing up and the attacker knows how we mix them up. So very simple operation, but we need to question, is it secure? Well, we'll see on its own is not secure because the attacker can, if they know the output, they know the permutation, they can easily find the input. They can go backwards. But when we combine it later with some other operations, the substitutions, we'll see that the final output is considered secure because the attacker cannot go backwards. So this is the idea of combined simple operations. Yep. I switched them, did I? One and nine. Right, okay. One becomes before nine. Right, okay, correct. I put nine before one but I was lucky and they both bit ones, all right? So, good. Find my mistakes. We get these 10 bits. We do the next phase of the key generation which is we split it into two halves, the left half and the right half. And in each half, we'll have five bits, do a left shift by one position on each half. Left shift, just rotate the bits, wrap around where necessary. That is now we consider in two halves, two five-bit inputs. We'll do a left shift by one position on each half. Left shift just means that the second bit becomes the first bit, the third bit, the second bit. And the first bit on input, we'll wrap around and become the last bit. So note that we do it just on those five bits, not on all 10. And then we do a left shift on the second half. So we move the bits to the left, so it'll be 1100, that's these four bits, and the first zero will end up at the right-hand side. So now we have two five-bit outputs. What's next? Join those two five-bit values, pass them into P8. P8 is another permutation. So we're just rearranging the bits. Left shift is also a permutation. What is P8? Go in the right direction. Sorry, wrong way. P8 is defined here. It's actually select and permutate. And as we start with 10 bits in, one through to 10, bits one and two are discarded. We just take the last eight bits and rearrange them according to this fixed definition of P8. So let's do P8 on those 10 bits. You do P8 and tell me the answer. The first two bits are going to be discarded and the last eight bits are going to be rearranged. And that the sixth bit, then the third bit, then the seventh bit will come first. Six, three, and seven. And if you keep going, four, eight, five, 10, nine. Bit four, eight, bit five is a one, and 10 and nine are both zeros. That is the output of P8. And importantly, that is subkey K1. Or the round key K1. It's going to be using round one of our encryption algorithm. So that's the value of K1. Keep going. So we just did P8, and the output of P8 is K1. But what we do to get K2 is we take the previous inputs to P8, do a left shift by two positions, and then do P8 to get K2. So let's quickly do that. So we'll keep drawing here. We take this five values and do a left shift by two positions. So we're going to continue with these five and do a left shift by two, and that's easy. This one will move to the middle position. Left shift by one, two positions. And similar, we'll do a left shift by two positions on the right five bits, and we have three zeros, and the two ones will end up at the end. And then take those 10 bits and do P8 again. The first two bits will be discarded. We rearrange the last eight bits and see what you get. P8, six, three, seven, four, eight, five, 10, nine. Bit six, bit three, bit seven, and four, bit eight, five, and the last two bits, 10 and nine, and that is K2. All we've done, we've taken our 10-bit user chosen key and rearranged it according to some fixed algorithm to get two subs, not so hard. That was the easy part. And note that the operations we did were all permutations or all transpositions. There were no substitutions there. We always just took the same bits in and moved them around. Left shift is a permutation, P8 and P10 are permutations. We're gonna use K1 and K2 in both the encryption and they are used also in the decryption. So if you receive ciphertext and you need to decrypt, if you have the same key, you'll generate the same two subkeys, K1 and K2. So we use it together. So let's do an encryption using our plaintext from the example and let's have a look at the encryption algorithm. Here's the details. We've got 10 minutes to finish our encryption. We'll get started, but as an overview, we start with eight bits of plaintext. We do an initial permutation. IP means initial permutation. So again, it's a permutation, it's fixed. Then this dark gray box is denoted f of K. So together we say that's some function. We take the eight bits in and produce eight bits output. This is what we call our round function. This is one round of our algorithm. And the input to that round would be K1. When we finish that round, we swap the halves, SW swap or switch, that is we have two halves of bits and we'll swap them. And then we do the same round function and the second gray box that's here. So exactly the same inside the gray boxes. So they're the same functions here, but in the second round, we use K2. When that's finished, we do the inverse initial permutation. Initial permutation is defined, the inverse. We'll see what that is, you'll see what it is. And then we get eight bits of ciphertext out. So what we'll do in the example is we'll get to, we'll go through the round function once, we'll get to here and then I'll leave it to you to do the round function the second time. Take eight bits in and initial permutation and then we split the eight bits into two halves. We'll take the right half and then apply these more operations on that right half, EP, XOR and others. Let's try it. We'll use K1 and K2 during this. Our plain text, I'll just denote as P. The data that the user wants to encrypt, we've chosen some values, eight bits of plain text. We do an initial permutation and like P8 and P10, that is also defined. Where is it? Here it is. Initial permutation, just a permutation where the second bit becomes the first, the sixth bit becomes the second and so on. Rearrange those bits. Two, six, three, one, bit two, bit six, bit three, and bit one, and then four, eight, five, seven. Bit four, eight, five, and seven. The initial permutation is done before the main function and the opposite is done at the end just before we get the ciphertext. In real desks, similar, there's an initial permutation, you do 16 rounds and then you finish with an inverse initial permutation. We split it into two halves, so we'll note that we'll talk about the left half and the right half. We will not use the left half yet. We will take the right half and do some operations on that. What do we do? The right half, the right four bits, so the line through it with the four means we've got four bits here. We apply these steps, EP, expand and permutate. Four bits in, eight bits out. So we're gonna duplicate the bits but also rearrange them at the same time. Expand and permutate. We take four bits in, one, two, three, four and what comes out, four, one, two, three, two, three, four, one, so each bit is duplicated on the output of EP. Four, one, two, three. Note we're working on the right four bits, one, zero, zero, one, four, one, two, three, bit four, bit one, two and three, four, one, two, three. And with those same four bits on the right half, two, three, four, one, bit two, three, four, one, four and one, bit one. This is actually the start of our function. So here was the start of that gray box where we do F, that function using K1 as input. After the expand and permutate, we've got eight bits. We XOR with the key. Eight bits, exclusive OR with K1. K1 we generated in the previous algorithm. So we write down K1 and do an XOR. And here's our first different operation. Key generation use permutate, left shift, which is also a permutate. Expand and permutate is a permutate. It's a rearrangement of bits. XOR is a substitution. We're not just rearranging the bits, we're replacing bits with other potential bits. So this is our first substitution, exclusive OR here. So XOR our value with K1. So if we remember K1 from before, K1 was one, zero, one, zero, zero, one, zero, zero. And we XOR those values. Exclusive OR, what do you get? Remember your exclusive OR. If they are the same, you get zero. If the bits are different, you get one. The same, we get zero. Same, different, different, same, same, different, different, different. We get our eight bits out. And then we split that again into two four-bit values. So that was a substitution. Well, how do we know? Well, it's definitely not a permutation because the input with these eight bits were four ones and four zeros. The output has five ones and three zeros. So we didn't end up with the same bits just mixed up. Sometimes it's hard to tell. It was some replacement of bits there. So that was a substitution operation. And the next operation is also a substitution and we use S-boxes in the same way that the permutations were defined. We defined, we defined a special technique a way to replace some bits with other bits to a substitution. And these are a key part in the real desk design and even in other ciphers. What we do, we start, consider the first four bits, zero, one, one, zero. I'll write it again over here. We, and let's look at the slide where it's defined, the S-boxes that we're up to. We just did the XOR. We've got four bits on the left, four bits on the right. The four bits on the left are going to be fed into S-box, S-zero. The four bits on the right are fed into S-box, S-one. We're going to power on through for the next 10 minutes and finish this example and then we'll take a break after that. Let's do the S-boxes. S-zero and it's defined on this slide. We have four bits in. I think bit one, two, three, four. The S-boxes, S-zero and S-one are matrices and they are defined, right? So four by four matrices, they are fixed. Everyone knows what the values are and the way that we use them is that the first and the last bit of the input determines the row of the matrix and the second and third bit determine the column of the matrix. We look up that element and that's the output. Let's consider with our example the row, the first and last bit, zero, zero. Row equals zero, zero. Column, the second and third bits, one, one. Or you can think row in decimal zero, column three. If we index our matrix starting at zero, so we have zero, one, two, three. Rows, zero, one, two, three columns. Then we look up the element which is in row zero, column three. Row zero, zero in binary, column one in binary. Look it up in the matrix of S-one. What do you get as output? Oh, sorry, S-zero, S-zero. Row zero, column three. S-zero, row zero. The top row, column three. The last column, output, one, zero. This value. Note that we index starting at zero. Row zero, one, two, three. Column zero, one, two, three. Row zero, column three, output, one, zero. Yep. Okay, so our input here, we have zero, one, one, zero. The rule is that, yes, the first and last bit tell us which row number. Row zero, zero in binary, or in decimal, row zero. Sorry, convert. And the column is the middle two bits, one, one. Or if I convert to decimal, one, one is three. Okay, so it depends on how you want to think about it. In binary or decimal? So in decimal, that will be zero and three. We just convert. So row zero, column three. Which is the fourth column, we start index at zero. The output will be this element. And it's fixed, it's always that value for that element, one, zero. Do it for S-one. With S-one, you take the other four bits. You take these four bits, apply into S-one, the different matrix, and see what you get. With S-one, we take the input as zero, one, one, one, row, zero, one, the first and last bit, column, second and third bit, one, one, or in decimal, one and three. Look it up in S-one. Row one, column three. Row one, which is the second column, column three, the last column, one, one comes out, this element. We've not discussed the design of them yet. We'll come back when we talk about this. Why is it like this? We have four bits. We're at this point. We pass into P-four, rearrange those four bits. P-four is defined, two, four, three, one. Rearrange those four bits. We have four bits, one, two, three, four. Rearrange where we have two, four, three, one. Bit two, four, three, and one. So we treat those four bits together. We get zero, one, one, one. X-all with the left half from the original input. Where'd it go? That is, all of this started with these four bits. We haven't done anything with these four bits, so let's use them now. Take these, and X-all with our four bits that we have currently. That's the left half. This was the right half expanded and permutated here. One, sorry. One, one, zero, one. Sorry, one, one, zero, one, zero. X-all, exclusive-all, one, one, zero, one. Almost there. Grab the right half. Grab this half, the original right half. One, zero, zero, one. Now we have two four bit values. Swap them. Swap the sides. Actually, this is a swap operation, which is quite simple. These four bits will become the last four bits, and these four bits become the first four. That was actually, and then I think we've done all operations necessary. Let's summarize what we did, then we'll have a break. We started with the initial permutation. We took the right four bits, expand and permutate. X-all with the key, K-one. Use the two S-boxes, S-zero and S-one. We get four bits out. Apply permutation P-four. X-all that with the original left half. We get four bits out. Take the original right half, and we're actually finished the round now. We have eight bits that come out of the round. Before we do the next round, we swap those two halves. And then we repeat it all again, starting from the expand and permutate. You see what's inside the gray box is the same. We do the same steps, but we'll use K-two. We'll get eight bits out. We'll do the inverse initial permutation and get ciphertext. So we got to this point. To finish, what you do is now you start the round function using K-two. When you finish that round function, then you'll do the inverse initial permutation, and you'll end up with eight bits, the ciphertext, and the eight bits you should get just by luck the two halves are the same. And to give you a hint, so we can have a break, the inverse initial permutation is your homework. Find it. What is it? And to give you a hint, the end of that function, the input is this. The end of function, the round function using K-two, you'll get these eight bits. Then you'll do the inverse initial permutation and then you'll end up with the ciphertext. So your homework, if you don't understand the steps, you can do them for round two, which is actually the same as round one, and then do the inverse initial permutation and we get ciphertext. A lot of details there. Let's have a break and then maybe in, well, at 10.50, 10.50 we'll come back and talk about why it's designed this way. The advantages and disadvantages. In 15 minutes.