And then we'll come back to DES and our ciphers. So try the practice quiz. And read the exercise and try the two pieces of software that I point to. Because next home or the actual homework, which will be assessed, which will come next week, requires you to use both of these pieces of software. OpenSSL is a library for security operations, encryption and other security operations. So we will use it throughout the semester. So you need to get some practice in using it. It's a command line application that allows you to encrypt things, to do hashes, and different operations that we'll need. VertNet is really some very basic software I've created that uses VirtualBox to create a Linux virtual machine. Because we're going to use Linux to demonstrate some things. And in your homework tasks, you will need to try and all use the same environment so that we can compare results. And I can mark your submissions. So I have a virtual machine that you can set up. And after the midterm, we'll start to use it a little bit more in that the benefit comes in that we can create a virtual network. So we have, say, three virtual machines running on your computer, and you create your own network inside your computer using VirtualBox. So try that. And the instructions are a little bit detailed. And things can go wrong. And the only way to fix them is really if you try them and if something does go wrong, then let me know. And we'll try and fix those problems. The result, so what do you do? If you follow the instructions, you download some software including a virtual machine that runs in VirtualBox, so only in VirtualBox. So it should work on any OS that supports VirtualBox, Mac, OSX, Linux. Follow the instructions. And what you get is a base virtual machine. I have in VirtualBox on mine. And then you run some program that copies the base and creates some nodes for your network. And you can choose a topology. Do I have pictures? I've got a set of topologies. That is topology one is the simplest of networks. One computer is not a network. It's just a single computer. We create a single machine, one we call them nodes. Topology two is a network. With two nodes, so what will happen is it will create two virtual machines, both running Linux, that will run on your computer using VirtualBox. And now we set up with IP addresses and in a network such that they can talk to each other across a simple network. And topology three and the other topologies just get more complex, so topology three is an example with three virtual machines. One we may use after the, or we may use several, up closer to the midterm and after the midterm is, for example, topology five where we may run a web server on node three, a web browser or a client on node one. And then the attacker, the malicious user, may run some software on node two and intercept the traffic between node one and node three. And we'll do some attacks by looking at a node that can intercept the traffic from others. And a few other topologies. So once you set up the software, you can automatically create these topologies. That's what the software tries to do for you, where you just run some command that create a topology, choose a topology, what was topology five was the one we wanted. And it goes away and takes some time. It copies the base virtual machine to create node one. It starts, it tries to set up the network interfaces on the node one, takes some time to boot, to set some parameters, and it will produce some output here in a moment, I hope. It logs into the base virtual machine to node one. And then it creates node two. And does the same, sets up node two for you. So this is doing it for you. And eventually it will set that up and create node three. And then you'll have three nodes, which are just three Linux virtual machines that can run on your computer. And then you can start them and you have a virtual network on your computer. You can log into one of them. And as if you are running your commands on a Linux computer with which is connected via a network to two other nodes. So you need to try this. We'll need it throughout the semester. We've tried it on a number of different computers and it finally works, so try it and then you can start to do some of the tasks. So if I now start, say node one, I would need to start all three nodes, but if I start node one, virtual box brings me up the virtual machine. And I can log in with network, network. And now I'm running on node one, so I can run commands on here. And eventually if I start node two and node three, I would be able to ping and log in to node two and node three. And we can set up whatever scenario we want. So try it. Again, next homework you will need at least one node. I'll require you to use the very simple topology of a single node. That's enough. Turn it off. And if you can then delete them. And if you want to create a different topology, you just run the command that creates a different topology. So that's one thing that you need to do. And the other part is use OpenSSL. And there are some instructions. You have some printouts and some links from the website that give some very basic introduction to using OpenSSL. And I'll show you some examples of that today. So I expect you to be able to try that yourself. I'm not going to provide any more instructions in the lectures, but I can help you if you have problems, especially if you bring your laptop or show me a screenshot if you have problems. In our lecture where we got to was looking at just listing really some of the symmetric key encryption ciphers. Sorry.  If you don't have access to a computer on a regular basis, a laptop, a home PC, then we've installed that software on all the Apple Macs in the other building on the third floor in the Mac lab. It's running on there. So you can just go in there when the lab is free, which is a fair bit of the time during semester, lunch breaks, after hours, some periods during the week. And it's already set up. So you don't need to install anything. You can run VirtualBox and create the topology immediately. We listed some symmetric ciphers. So going backwards, one of the first ones that became very popular was DES, data encryption standard, but insecure because of the key size. 56-bit key means a brute force attack is possible. Triple DES, use the same algorithm, but use it three times with a different key each time. So effectively, the key is three times the length of DES. There are variations where you could have it two times the length of DES. So the keys were 168-bits, or even if you want, for performance reasons, or compatibility, shorter. So no longer subject to brute force attack, but the DES algorithm, although considered secure, was slow compared to other alternatives. So triple DES is three times slower because you apply the algorithm to encrypt the data, and then you would do it again, and then again. So advanced encryption standard was developed to be secure, of course, but also to provide some performance improvements. So it was fast for software implementations, fast in hardware, and in different types of hardware. So it's very commonly used today, advanced encryption standard, AES. And there are others. So there are many ciphers available. They have advantages and disadvantages. And then we said, OK, really there are two types of attacks. Brute force, try all the keys, crypt analysis. Use some knowledge of the algorithm to try and be better than brute force. So use a little bit of intelligence to try and find the key or the plaintext without just trying all possible keys. That's crypt analysis. So the attacks are usually specific to the ciphers. So an attack on DES may be different from an attack on AES. And we will not look at details of crypt analysis. There are different types of attacks. They're very complex. We may see a few examples through the course, like meet in the middle attacks, but there are different techniques to try and break the ciphers. With a brute force attack, the measure of how good the attack is and therefore how secure the cipher is really depends upon the key length. Because the key length determines how many times we need to try and decrypt our plaintext, or decrypt our ciphertext to get the plaintext. With brute force in the worst case, I have a ciphertext. I need to try all keys. Then the worst case is that I try the first possible key. I get some plaintext. It makes no sense. I try the next key. I get some plaintext. It makes no sense. So I keep trying the keys. And the last key I try, I decrypt. I get plaintext. It's correct plaintext. So I've found the plaintext. So that's the worst case. Or I have to try all possible keys. The best case would be I choose a key randomly. And I try it. Ah, I get the plaintext straight away. The average case is I try about half of the keys. Often we measure based on worst case. Average is half. It would take half the time. It's the worst case time. So how many attempts of decrypting do I need to find the plaintext with a brute force attack? Depends upon the key length. So a k-bit key requires 2 to the k operations in worst case. Decrypt with key 1. Try key 2, key 3. How many keys to try? 2 to the power of k keys. So 2 to the power of k operations.  It depends upon the computer speed. Do you have just one computer doing the encryption at the same time? Or can you spread the task across multiple computers, for example? Or can you get a faster computer that will impact on the real time it takes to break using a brute force attack? And I'll show you some numbers in a moment, some typical times. Crypt analysis, again, we won't go into the details, but there are different approaches to try and break the algorithms. And the idea is to be faster than a brute force attack. Brute force is the worst case. So if we can do a brute force, then we can break the cipher. Crypt analysis aims to find the key or plain text faster than any brute force attack can be. If it's slower than a brute force, then it's no use. I might as well just use brute force. So we want to be faster than brute force. So the way that we measure different security attacks on the ciphers is how many operations they take. If a brute force takes two to the k operations, but we have some other attack, which takes less operations, then that's better. That's a better attack, and our algorithm is considered less secure. So the number of operations an attack takes is a measure of how good that attack is, or in other words, a measure of how bad the algorithm is, the cipher. It turns out most attacks on real ciphers, to do them, you need some memory to store the data as you're doing the attack. So another way to measure how good an attack is is how little memory it uses. An attack that is faster than brute force but requires tens of petabytes of RAM to do the attack is not practical. But an attack that is faster than brute force that requires a gigabyte of RAM to do the attack is better. So it's not just how fast is the attack, but how much memory is required to do the attack. So another measure of how good the attack is. And many attacks make use of past pairs of plain text cipher text. And I think we mentioned before talking about the attacker sometimes can discover, or they know about past cipher text, but they've discovered the corresponding plain text as well. They don't know the key, but they know here was a cipher text encrypted using this key, using some key, and the corresponding plain text. So they know a pair of plain text cipher text. They can use that when they have a new cipher text to try and find the plain text for that new cipher text. And many attacks on real algorithms make use of known pairs of plain text cipher text. Usually the more we know from the attacker's perspective the easier it is to perform an attack. And we'll see some numbers about them in a moment. I think we'll go to the demo. OK, did we cover this? I think we've seen parts of it. I get confused. We're teaching this class, and I'm teaching another security class, and we're covering similar topics. So I get confused what we've covered and what I haven't. But from the next topic on, I'll be covering different topics in both the courses. And are we less confused? This shows brute force attack given a key length. Key space is 2 to the power of the number of bits in the key. And some worst case times, real times, given computers at particular speeds. So if my computer can decrypt at 1 billion operations per second, and these are the key lengths, then this is how long it would take to do a brute force attack. And there's an error. This should be five hours, not five seconds. So with a 64-bit key, at 10 to the power of 15 decryptions per second, it takes five hours approximately, not five seconds. It's an error in the slides. You can see from 128 bits onwards, and less than 128, slightly less even, that with a computer that can do 10 to the power of 15 decryptions per second, a brute force attack is not possible. So the weight of defeat a brute force attack is just to make your key length large enough. How fast is a computer? Can we do 10 to the power of 9 decryptions per second? What if I could do 10 to the power of 24 decryptions per second? Let's have a look at some examples. First, and you can try this on your own computer. There are different ways to measure. I'll do it on my laptop, and then we'll show you some other data. This program that you're trying to use, or you're going to start to use, is OpenSSL. And one thing that it does is, well, it provides an implementation of many ciphers, including DES, triple DES, AES. So you can use OpenSSL to take some plain text and encrypt with AES. It also has a nice feature that can do a speed test. It will try and encrypt a lot of plain text, random plain text, and measure how long it takes. And let's say we're using, I want to do a speed test on my computer. I'll start it. What it does is using AES as a cipher, a 256 bit block, AES has different options. CBC will come to later. But what this does is take some random plain text and encrypts using the AES cipher and measures how long it takes on my computer. Gives many details, but the main output, these numbers at the end. And there are different ones and it's not so easy to see, but focus on just one number, this one. What it says is that my computer using AES can encrypt and encrypt and decrypt at about the same speed. So encrypt or decrypt at a speed of 62,000, no, this is 62,000 K. So 62 million plain text per second. Now in this case, the plain text is 16 bytes. 16 bytes, a block, let's go back and remember, a block size of AES, so what we do is we take 128 bits of plain text and encrypt that at a time. So a block is 128 bits, which is 16 bytes. So this is encrypting at 62 million blocks per second about on my laptop. So 62, let's say just generalize and say 62 million encryptions per second, my computer can do. 62 million is 62 by 10 to the power of six. Can we go faster? All right, that's my laptop. I've logged into my computer upstairs, which is a little bit better. Let's run it on there, a speed test, same cipher, and it'll take a minute or so to run. Different CPU, it's maybe a year or two years old, the CPU on my desktop, we'll see the speed it gives. So it just encrypts a lot, measures over three seconds each, all right, 100 million operations per second. In this case, so a little bit faster. Turns out many CPUs nowadays have hardware support for AES encryption. So Intel CPUs have some built in hardware to do the encryption. What was done then was all in software. Using hardware will be faster and to enable hardware I have some option EVP, which tells OpenSSL to use the hardware of the CPU to support the encryption. With the software I had about 100 million operations per second, now I'm using the hardware mode, 500 million. So five times faster by encrypting using hardware as opposed to software. So with my computer, one year old CPU, 500 million operations per second. 500 million, 500 by 10 to the power of six or half a billion, point five by 10 to the power of nine, which sits about here, okay? All right, this is one billion. My computer is half a billion, so half the speed. So if I tried to do a brute force on 128 bit key, then it would take me twice as long as this. So two by 10 to the power of 22 years still, it's of no use. So what can I do to be faster? How can I go faster? How can I speed up by brute force attack? Anyone? You wanna break some cipher? What are you gonna do? GPU, use some faster hardware, okay? All right, number one, buy a better CPU. There are newer ones, generally faster, but not much faster. Turns out the graphics processes on computers nowadays can do a lot of processing in parallel and can be much faster in some security operations. So they, the hardware, get faster hardware basically. So that's one way, generally costs more, okay? So you pay more for that hardware. The other way is to use multiple computers, okay? I use the lab down in the other building where we've got the Macintosh lab and the network lab. About 80 computers in total I have access to. Run the attack, a brute force attack in parallel on those 80 computers. So 80 times faster than using just one computer. 80 times faster doesn't help much though, okay? So instead of 10 to the power of 22 years, slightly less. 80 times faster is still too long. Let's look at some data that people have collected about in different hardware and how fast brute force attacks can be performed. I'm not sure if I've provided, I don't think you have this in front of you, but it's on the website, but it's just some examples, okay? First, some examples about desks. So desks was used for a long time. It's no longer considered secure. So, but used in the 70s, 80s, 90s and still used by some people today. But desks with a 56 bit key, a brute force attack, two to the power of 56 operations. In 1998, the electronic frontiers foundations and people developed some designed and developed some hardware to break desks. So a 56 bit key. It costs them less than 250,000 US dollars, okay? Expensive for you and me, but for an organization that wanted to break, do a brute force attack on desks, not so much. And it did 80 billion keys per second. So this was dedicated hardware created just to break desks. So my computer on AES was doing, what, about a billion or half a billion keys per second. This hardware on desks, a different algorithm, was doing about 80 billion keys per second. That was in 1998. And there was a challenge, break desks, and they solved it in a couple of days using that hardware. About eight years after that, so in 2006, what, that's eight or so years ago, another company or universities in Germany developed some other hardware using dedicated hardware. So FPGAs programmed just to break desks, okay? Designed just to do desk decryptions as fast as possible. And they could do about 400 million keys per second per FPGA, okay? And they actually, so this is one FPGA and they just put a bunch of them together. So they broke desks in about nine days. And it cost about $10,000 at that time. And at that stage, a Pentium 4 was the typical processor around that year. That could do about two million keys per second. So the dedicated hardware, one of them was at what, about 200 times faster than a typical Intel CPU. What about desk today? Well, people forget about desk because it's considered broken, but what could we do? Assuming in 2006, our hardware could do 400 million keys per second per FPGA and cost $10,000. Well, Moore's Law is some guideline that says hardware gets faster over time. It's a bit more complex than that, but you know that CPUs get faster and faster, okay? The technology gets better. And it says approximately the speed doubles every one and a half years. What does that mean? If I buy a computer today for 10,000 baht, then in one and a half years time, if I spend 10,000 baht, the speed of my computer in one and a half years time will be about double of what it is today, approximately. Just use this rough guideline that about every one and a half years, the speed doubles. Which means for the equivalent price, oh, whoa, to get the equivalent speed computer, the price is reduced by half. And you can do the calculations, so between 2006 and 2013, seven years, so every two years, or every one and a half years, it doubles, which means it becomes half as cheap every one and a half years to do the same operations. Meaning it will cost you a couple of $100 to buy hardware to break desks today. Trivial for anyone, okay? So desks is broken. It had a 56-bit key. What about AES, okay? Which is the standard today. And AES allows different key lengths, so AES 128 is common, 128-bit key. The same people who developed this hardware to break desks have improved the hardware to develop for AES, so they've created something called Riviera. Again, it uses FPGAs. And I've looked up some data, and you don't have to know these details, but they've got FPGAs that, about $100 each. You buy that piece of hardware, about $100, U.S. dollars. And it can do a brute force on AES with 128-bit key at about 500 million keys per second, which is per one FPGA. And they also measure how much power it consumes, because power is also an issue when you have a lot of hardware. Of course, you can use multiple FPGAs. For example, I think that their piece of hardware supports 128 of these, not just one. You just plug in 128 of them. There's an attack on AES, a crypt analysis. It's called the by-clic attack. We don't understand how it works, but it's an attack that's slightly faster than brute force. And I've implemented it, and it can do about two times the speed of brute force, so almost a billion keys per second. So that's some hardware that you can get today that will try to break AES. So one FPGA, about 500 million keys per second, and it costs about $100. That device, this Riviera device, supports up to 128 FPGAs. So 128 times $100 is what, $12,800. Maybe there's some extra costs. Let's say the cost of this device is $15,000. So I go with $15,000 to buy this device. It has 128 FPGAs. They're all doing about half a billion keys per second on AES. AES, brute force, there are two to the power of 128 keys that we need to try. With 128 FPGAs, we can do about 64 billion keys per second. Where do I get that number from? One FPGA can do half a billion keys per second. So 128 could do 64 billion times by 128. Half times 128 is 64. So this box with 128 FPGAs can do about 64 billion keys per second, and it costs about $15,000 today. So how long would it take to do all two to the power of 128 keys? 1.7 by 10 to the power of 20 years. Still impossible, brute force. So this is with dedicated hardware, about $15,000. That's how long a brute force attack on AES would take. Let's say I could spend more money. I had $15 million. I'm a company, I want to break AES. I have $15 million to spend. Then I can buy a thousand of these devices. Each one is $15,000, so I buy a thousand of them and get them breaking AES all at the same time in parallel. So I'd be a thousand times faster to break AES, which is what, 10 to the power of 17 years. Let's say I'm a government and I have $15 billion to spend, then 10 to the power of 14 years to break AES. So even at this price, brute force is not possible. That's a brute force. There's some attacks known on AES which are slightly faster. The by-click attack is one of the best known ones. Brute force requires two to the power of 128 keys to be attempted. This attack is slightly faster. It requires equivalent of two to the power of 126 operations, which is what, four times faster, because two to the power of 126 times two is two to the power of 127, times two again is two to the power of 128. So it's four times faster. What's four times faster than 10 to the power of 20 years? Well, it's almost the same. It makes no difference in terms of time. So even with this best known attack, four times faster is nothing when we're talking about billions of years. In fact, this attack, although it's four times faster, it uses a small amount of memory. That's not a problem. Two to the power of 256, so trivial amount of memory. That's not a problem. That's good for the attack. But it requires two to the power of 88 known pairs of past plain text, cipher text. That is, somehow the attacker has intercepted past cipher text values and has learned the plain text, but they don't yet know the key. Now they've intercepted a new cipher text and they're trying to find the key or the plain text. So this attack, in theory, requires the attacker to know two to the power of 88 past cipher text plain text values, which is impossible. You calculate two to the power of 88 and it's a very, very large number. So it assumes the attacker knows all this past information. So the attack, in theory, is possible in practice, the attack on AES, cryptanalysis, is not possible. AES is considered secure. Do I have one more? What about I encrypt my data today using AES 128? 128 bit key. And it's very secure data. I want it to be secure for the next 15 years. If someone breaks it in 10 years time, then that's bad. So I want my data to be encrypted and no one can break it in the next 15 or 20 years. How long would AES 128 take in 15 years time? In the year 2028? Assuming our computer's speed double every one and a half years, then the cost halves every one and a half years. And in 2028, if I have $15 billion to spend, then it will still take me 100 billion years to do a by-clic attack. Assuming there's no better attack developed, the attacks will still not be successful in 15 years time. That's with AES with 128 bit key. AES also supports a 256 bit key. That's the demo I gave on my computer before. That's how long it would take to break AES with a 256 bit key. So again, these values, even if there's a 1,000 times improvement in the speed of computers, doesn't help. 100 billion years down to 100 million years to break it. Even if you have 1,000 times as much money, it doesn't help in the attacks. So brute force and the known attacks on AES are not in practice successful. AES is considered secure. DES is considered insecure because of brute force. So just an example, putting into context with current hardware and with future hardware, still these algorithms are considered secure. Again, you don't have these slides in front of you, but you can find them on the website. It's just an example. You don't need to remember all these values, but just understand brute force, how to determine how long it takes to do a brute force attack. Any questions before we move on next topic? Still in cryptography, but slightly different. So I don't think, okay, I'm going to get my super fast computer with two GPUs and try and break AES. Because unless you have a long time to wait, you're not going to do it. Now, okay, yep. How about we use cloud? A cloud, okay. Also we're not to spend on the buying the hardware, so we just loan the... You loan the cloud. I think the cloud still requires... So you use Amazon. Amazon provides a service where you can essentially rent their hardware for some period of time. You still need to pay for that. They don't give you the hardware for free. It may be a little bit cheaper in some cases, but okay, let's say using Amazon is a million times cheaper than using my own hardware, and it's not. But let's say it was a million times cheaper than in 15 years' time, an attack a million times cheaper would cut it down to 100,000 years to break. Still 100,000 years. Who's going to wait? And using the cloud is just using other people's hardware. You still need to pay for it. It doesn't improve. I mean, the order of magnitude it may improve by, even if it's double the speed, or you have a computer that is double my speed, then you halve the time. Double the speed halves the time. So instead of 100 billion years, 50 billion years of no impact on the end result. Halving the time, reducing the time by a factor of 1,000 still doesn't matter. Okay, so can you make your hardware go faster? For encryption, usually the best way to get the hardware to do the encryption operations as fast as possible is to program the hardware to do it, okay? You saw the example on my PC upstairs in my office. This was a speed 100 million per second when it was just done in software, okay? So using the CPU, normal instructions, the software does it. I mean, using the normal instructions of the CPU. But many CPUs nowadays have special instructions to do AES encryption and decryption. And the second example down here was when I used the special features of my Intel CPU to do AES encryption, and it's five times faster of when you use the normal features. So that's an example of when the hardware is programmed to do encryption, we can be much faster than when it's general purpose hardware. So this was five times faster if you use some feature of a GPU that is programmed to do encryption, then it can be faster, okay? But still, five times faster, what? 100 billion years down to 20 billion years. No, no import. No practical impact. Any other questions? So yes, we can get faster hardware, but the numbers we're talking about, it makes no difference. And that's what we spoke about with those examples. This gives some details, and we're not going to investigate, but some attacks on different block ciphers, which are the best known ones. The best known attack on desk is brute force. The time it takes depends upon the key size, or two to the 56th operation. So we don't measure time in seconds, but the number of operations, really. How long does it take in real time depends on our hardware. Triple desk, the key size is 168 bits, but there are attacks that mean that you can do much faster than a brute force of trying two to the 168 values, and a man in the middle attack can reduce the time down to two to the power of 111 operations, much, much faster. And there are other attacks, so this method by some person, by Lux, two to the power of 113 operations. With AES128, the attack that we gave some data for, AES with 128 bit key requires two to the power of 128 operations in a brute force attack, but this attack brings it down to two to the power of 126.1, about four times faster, but the problem is, in theory, the attack requires the attacker to know a lot of past plain text, cipher text pairs, two to the power of 88 values, and there are other attacks that are the best known ones, at least in the last couple of years. Maybe there are attacks that we don't know about, that some secret government organization knows, but in general, a lot of smart people work on trying to determine attacks on these algorithms, and the best we can assume is that the smart people know about them and have published their attacks, so even if there are some government organizations working on attacks, people still think AES is secure and they're still trusted. Block ciphers, the algorithms we've talked about are designed to operate on either 64 or 128 bits at a time. What they do is you have a large plain text to encrypt, say a one megabyte file. To encrypt with AES, it operates on 128 bits at a time. It takes the first 128 bits, encrypts, it gets 128 bits of cipher text. Then it takes the next 128 bits of the plain text, encrypts, with the same algorithm, the same key, and gets the next 128 bits of cipher text. We talk about blocks that it operates on. Now, if you just split the plain text into blocks of 128 bits, encrypt each one separately, and then just the cipher text you take by combining those outputs, turns out that you can do attacks on the output cipher text. There's things called modes of operation that define the ways in which you, if you have a long plain text, you break it into blocks, you encrypt a block at a time, how do you combine the cipher text blocks on output to get the final cipher text? We would not look at all of them, we'll just give you two examples. They're called modes of operation. These are a list of some common ones, ECB, electronic code book, CBC, CFB, and others. They have benefits in terms of some are more secure than others, some can be implemented faster in hardware, some have some problems with when errors occur. I don't think we'll spend much time on this course. If you want to see that, you need to sit in our security and cryptography course. This is a diagram that shows one common example of these modes of operation where we have a long plain text, we break that into blocks. So the first block, the second block, the third block, and so on. 128 bits at a time, for example. We take AES, that's our cipher. We take the first block of plain text, we perform some exclusive OR operation with some initial value called the initialization vector. So something chosen by the user. We take the output encrypt with AES using our key. We get some ciphertext block as an output. We take that value and use it as an input to the XOR with the next plain text block. Use AES again, same key, encrypt, and get our ciphertext out and take that value and use it as the input. So we do some chaining between the different blocks. We take the output of one encryption and use it to XOR with the input of the next encryption. So we get cipherblock chaining. And the resulting ciphertext is just a concatenation of all the output blocks. I'm not going to explain any more on that. We'll skip over that, but I just had to mention it because you saw in our demo whenever you use a cipher in practice, you need to choose a mode of operation. In my example, I chose to use the cipher AES. 256-bit key AES can use different key sizes. And the CBC, the cipherblock chaining, is the mode of operation. Usually, there'll be some default mode. CBC is common. There are others. But it's really a way to handle large plain text inputs. Another example. Let's move on. Stream ciphers. So block ciphers. We take a block of, say, 64 bits of plain text or 128 bits, encrypt with our cipher, get our ciphertext output, maybe combine it in some way and get our results. Stream ciphers are really designed to be faster, faster to be implemented so they run faster when we encrypt. And what they do normally is operate on one byte at a time. So think of our block sizes as a byte, 8 bits, not 64 bits. And the general approach of a stream cipher is that we have our plain text. You think of a stream, a continuous sequence of bits of plain text. It makes sense when we have, for example, some real-time communications. I'm talking on a phone, and I want the voice to be encrypted. And as I speak, the codec on the phone generates bits representing my voice. Then a stream cipher may take those input streamer bits and encrypt them and sends the ciphertext across the network. So the idea was that stream ciphers can be fast so that when you have real-time applications, when you need small delay, that they don't take long to encrypt. The general mode is that we take our plain text, we have a key, and we have some function that generates pseudo-random bytes. We'll see random numbers later, but just think random values. Somehow it generates random values. And it generates random values, and our plain text is simply x-ord with the random value to get our ciphertext. X-or is very fast to implement, and exclusive-or in hardware and software is very fast. Des, A-E-F, generally quite slow to execute. So an exclusive-or operation is fast and secure. The security of stream ciphers depends upon how to generate these random values, and it's not easy to always generate random values. Nowadays, sometimes there's not much difference in terms of the speed of a stream cipher versus a block cipher. Let's see if we can find an example. On my computer before the demo, using AES, I got 100,000 using the software mode, 500,000 using the hardware mode. A stream cipher is RC4. Let's see if it works. RC4 is an example stream cipher, quite old, but let's see how fast it takes to encrypt using RC4. So 100,000 and 500,000 using specialized hardware. All right, using RC4, using just software, not using the specialized hardware, almost 500,000. So in software, using the normal CPU instructions, RC4, a stream cipher, 469,000 K, in this case, is about five times faster than my AES using just software. Although nowadays, with the special hardware support for AES, this is a little bit slower than AES. So sometimes stream ciphers can be faster than block ciphers, but when you have special dedicated hardware, block ciphers can actually be quite fast. RC4 was used in wireless lands. It's used in some internet applications. It's still used quite widely. There are some limitations of RC4, though, that if it's used wrong, it can be insecure. Just one example. Let's move on. Last 20 minutes, let's look at a new concept. We looked at symmetric key encryption, taking data encrypting, where both entities use the same key. They both use the same key to encrypt and decrypt. That's mainly for data confidentiality. I want to have a file that no one else can read unless you have the key that I encrypted. Let's look at a different service. Authentication. I want to make sure that the file that I receive, or the message I receive, comes from the person who they say they are. I want to check that the source is not pretending to be someone else. How do I authenticate information? There are different ways. Authentication. The receiver wants to verify usually two different things, or it can be two different things. I want to verify when I receive a message that the message has not changed. Someone sends me a message. I receive that message. I want to make sure that no one in between changed the message. I want to make sure I have data integrity. That's one form of authentication, sometimes data authentication. Authenticate the data I receive. The other thing is I want to make sure that when I receive a message, and the message says this is from Dr. Tanarak, I want to make sure that it's actually from him and not from a student pretending to be him. I want to verify that the source is who they claim to be. We use similar concepts to do both of these, and there are different ways to do it. The four main ways. We can use symmetric key encryption, the techniques we just spoke about. I'm going to explain how to do that in a moment. So we can use the AES, we can use DEF, we can use RC4, we can use the normal ciphers to provide this service of allowing the receiver to verify the message that they receive. But there are other approaches, which sometimes are faster or more convenient. And we'll talk about message authentication codes, MAC, and hash functions. So we'll talk about how we can use them. And related to them, later we'll see public key encryption, digital signatures. So always think now, you receive a message. How do you know that the message hasn't been modified and that it comes from someone, or comes from who they claim to be? How do we use symmetric key encryption to do that? Here's the case. The source message, M, is sent to the destination. And remember the goal of the destination is to make sure that it came from the right person and it hasn't been modified. So the source takes the message in crypts that say using AES, and some shared secret key K. They give the ciphertext, they send the ciphertext across the network. So mathematically we think of the ciphertext as we encrypt the message using key K. The receiver decrypts the ciphertext, so ciphertext is the input, D is the decryption operation, takes the same secret key K, and gets the message back. This provides data confidentiality in that if someone intercepts this, if someone listens in and they receive the ciphertext, if we have a strong cipher, they shouldn't be able to get the message, because it's encrypted. And we assume now if we have a strong cipher, if an attacker doesn't have the key, then what can they do? With AES they can try a brute force attack, try all possible keys. We know it takes too long. Try some other attack again, it takes too long. So an attacker cannot read the message in this case. But does the receiver know that this message came from, let's say, call them A and B? Does B know that the message came from A and it didn't come from someone pretending to be A? Do we provide authentication with this? And how? Yes? Good, because this is what the slide's about, how? Okay, good. The assumption of symmetric key encryption is that, okay, I haven't labelled them, this is A and this is B. User A, user B. Symmetric key encryption assumes A and B have the shared secret key K. Okay, only A and B know K. If someone else knows it, it's not secret. So user A encrypts with K, sends the cipher text, B receives the message and they know the only user A is the only other person that has the key K. So if this message successfully decrypts using key K, then B knows it must have been encrypted by someone who knows K. And the only other person who knows K is user A. If user C tried to send a message pretending to be from user A, tried to send a message to B, so user C sends a message, they encrypt it with some key. But they cannot encrypt with this key K because user C doesn't know the key K. So they encrypt with some other key. If B thinks the message is from A, then they'll decrypt with the key shared with A and it will be unsuccessful in the decryption. Let's see if we can draw that, maybe it'll make more sense. See what an attacker can do and see why the attack would be unsuccessful. So let's label the users. So we have A sending a message to B and what do they send? In the normal case, they send a message using the same notation as before. They send the cipher text, which is in fact... Let's call the key, instead of K, let's call it KAB, subscript AB. That's the same as the previous diagram where A has a message, they encrypt with some key and send the cipher text, the encrypted form of that message to B. Where the key, KAB, denotes the key shared between A and B. Only A and B know this value. B decrypts. So the operation that B does, the message came from... So the source, who's the source of this message, is A. From B's perspective, they receive the message from A, so therefore they use the key... What key do they use? Well, the key that they've shared with user A, KAB, and therefore to decrypt, they do the operation decrypt, the cipher text with KAB. So B receives a message, the message says it came from A, therefore B uses the key that it has shared with A, KAB, and decrypts the received message, C, using KAB, and since C was encrypted with KAB, B will receive the message. I'll get the original message back. It was successfully decrypt. That's the normal operation. Now let's see what an attacker can do. And I will not call them C, because we already have a C in here. Let's call them D. No, we have a D, we have an E. Let's call them F. Even better, M for a malicious user. Let's consider the case that we have, of course, A, B, and we have some other users, M, the malicious user, the attacker. And instead of A sending the message to B, it's in fact the malicious user sending the message to B, pretending to be A, a masquerade attack. What do they send? No, let's do something different, sorry. Oh, no, we'll do this attack first. So they send ciphertext. Why did I use M? Let's call them M-A-L, a malicious malm. They have some message they send to B and they want it to pretend to be A. So they encrypt the message with some key. What key do they use? They choose some key. Let's call it the key of the malicious user. Send it to B. B receives a message. B thinks the message is from A. The source from B's perspective is user A. It doesn't know it's from the malicious user. That's the attack. Therefore, what key does B use to decrypt? Anyone? I'll go back to the first case. Yep. Malicious user? No. I don't know they're a malicious user. The scenario is that in the first case, B receives a message from someone. In the message, remember the emails last week, I received an email and the from address gave someone's name. So I receive a message and the from address says A in this first case. The source is A from B's perspective. I think this is from A. Let's check. I think it's from A. Before to decrypt, I will use the key that I shared with user A, which is on B, I shared with user A, K, A, B. That's the key I've shared with user A. So I decrypt the message I received, the ciphertext, using that key. And in this first case, it would be successful decryption because the ciphertext was indeed encrypted with that same key. If a message is encrypted with one key, it will only successfully decrypt with that same key. So in this first normal case, this decrypts and we get the message as the output. That works. But in the attacking case, what happens? B receives a message. The message says from A. So from B's perspective, the source is A. Therefore, the key I will use to decrypt is K, A, B. I think it's from A. I am B. Therefore, use the key that I shared with A. So what I do is I take K, A, B, and I decrypt the received ciphertext. So I receive some ciphertext message. I decrypt using K, A, B. Will that decrypt work successfully? Will I get original plaintext out as the output? No, because in fact the ciphertext was created by encrypting the message, some plaintext, with a different key. The key of the malicious user pretending to be A. And the nature of our encryption algorithms is that if we decrypt with the wrong key, then the output will not make sense and we'll be able to detect that this is the wrong key or the wrong message. That is we can detect if the key is wrong. If we decrypt with the right key, in this case the right key was the key that was used for encryption, we'll get the plaintext. So what happens in this case, B tries to decrypt and sees there's an error. Usually the software will say when we decrypt with the wrong key, it will say error, did not decrypt. And B will detect, okay, did not decrypt, something went wrong. Maybe there's someone pretending to be A. In this case there is. So for a malicious user to pretend to be A in this case, they need to know K, A, B. But our definition is that K, A, B is only known by A and B. If malicious user knows key A, B, then they can pretend to be A. But that defeats our idea of a shared secret key. K, A, B should be known just by B and A, not the malicious user. So in fact, symmetric key encryption provides authentication. The receiver can verify, did this message really come from A? Or did it come from someone pretending to be A? Because if it really came from A, it will successfully decrypt with the key we shared with A. If it came from someone pretending to be A, then it will not successfully decrypt. Complex, but an important point of how we can use symmetric key encryption. Any questions about that? Try and get your head around the concept there, because it's used throughout different schemes for authentication. And we're working on some assumptions. So one assumption here is that a shared secret key is indeed secret. K, A, B is only known by A and B. If other people know it, then our system fails. The other thing we assume is that if a message is encrypted with one key but decrypted with... and then the ciphertext is decrypted with a different key, then that will return an error. That will say error, something went wrong. And you will try that with OpenSSL and other software. If you decrypt with the wrong key, usually the software will say something's gone wrong. You'll see how that's done. But it's normal that that can be detected. Therefore, we can prevent... or we can detect if a malicious user sends us a message pretending to be someone else. So we cannot prevent them from sending the message, but we can detect if they do send the message, which acts as a deterrent. So when I received those emails last week, then what I really needed is some way to authenticate who really sent the message. Although I looked at the from address of the email, I thought it was from that person, but in fact it was from someone else pretending to be that person. One way I could detect that it's from the wrong person is to require the sender to use some form of symmetric key encryption of the message. So that's one way to authenticate. The problem with this, it works, it's fine. It provides authentication. Sometimes it's too slow to encrypt the entire message. We don't need to encrypt the message. Sometimes we don't care if someone sees the contents. We just want to make sure that we can verify the sender. Like our email. I don't care if the message is seen by others. I just want to make sure that the person who sent it is who they say they are. So sometimes we don't need encryption to show an expensive cost in terms of performance. So there are other ways to do the same authentication but as an alternative to encryption. So symmetric key encryption can be used for authentication. However, often we want to use some other approach because symmetric key encryption is mainly for confidentiality. It can provide authentication as well. But there's some overhead of using it. It reduces the performance. So there are other methods built just for authentication. Message authentication codes will go through next week and hash functions will go through next week. So we'll look at how else can we perform authentication. I think let's stop there on that rather complex part. So what will you do before Tuesday? You will do the, you'll try the online quiz to make sure that you know what's going on with the original lectures. So try the security concepts. Again, not assessed, just try it. And more importantly, you'll do exercise one in. And the main things, try and set up this virtual networking using virtual box. You can get it set up and we'll use it for the rest of the semester. And if you don't have access to a computer, then use the computers in the Mac lab that are already set up. And if you have problems with it, the best thing is to take a screenshot of the error or what happened and email it to me or to come and show me on your laptop and I may be able to suggest the solution. Some things will go wrong. And once you've set it up, start a virtual machine, start one of the nodes and you run OpenSSL. And the instructions for running OpenSSL, again, you've got some in your handouts and linked on the website. Some examples and demos of running OpenSSL. Still got three minutes, good. One last demo then. Let's encrypt something. We have some plain text message in a file. Let's just quickly use OpenSSL to encrypt it. OpenSSL and it's quite complex command so I provide some examples. Encrypt, choose the cipher. Let's use des as the first case. You can choose any cipher. Des is insecure but just as an example. And we need to choose the mode of operation with des. The mode I've chosen is ECB. If you don't choose it, if you don't specify, there will be a default value chosen. What's my input? My plain text message is the input so we specify the input message, dash in. And the output cipher text, we specify to go into some file. Now, when we encrypt, even though it's an input text message, it won't be text as an output. You can call the extension whatever you like. Just call it dot bin for binary. Enter. All right, we need a key. And the way the software works is that if you don't provide your own key, it will allow you to choose a password. Ask you to verify the password you typed in so I typed it in, it didn't show. And it will use its own algorithm to take that password and generate a key. So it generates a key from the password encrypts and then we have the cipher text as the output. So my input plain text file and the cipher text as an output, if you try and look in the cipher text, it's a binary random characters so it doesn't make sense to look at the ASCII form. You may need to use some special software to look at the cipher text, say in binary form or in hexadecimal. XXD is one example that does that. So there's my cipher text in hexadecimal. Doesn't make sense in ASCII. It's random characters. So we want to decrypt. The operation is still encrypt but we use an option dash D, the opposite, decrypt. We want the same algorithm. The input now is the cipher text and the output, let's call it the received message. In decrypt the cipher text, I need to provide the same password. I type it in and I look at the received message and it should be the same as the original message and it is in this case. So I start with a plain text message, just some text message. I encrypted and got some cipher text, some random characters it looks like. Then I decrypted the cipher text and, where, here. Decrypted the cipher text and put the output in receive.txt which of course is the same as the original plain text. The message decrypted should be the same as the plain text. And it doesn't have to be a text file. You can encrypt any file. You encrypt a DVD image. You encrypt a word document. Any file that you like you can encrypt in this approach and you can try some different options. So those instructions, you've got some printed in your lab manual, in your lecture notes and the links to them are on the course website. You'll see links to those exact instructions for doing that. Try them. And next week we'll continue with different parts of cryptography authentication.