 So again, our symmetric block ciphers operate on a small block of bits at a time. 64 bits, 128 bits are common. The modes of operation are ways to use that same cipher on a larger input, larger than the block size. ECB is the basic approach and what you would expect in a very trivial approach. You take your plaintext, say a megabyte, you break it into blocks that match your cipher. So my plaintext P is broken into blocks of P1, P2, up to Pn. Then I use my cipher, AES, DES, whatever. I use my cipher to encrypt each block of plaintext using my key, my chosen key. And get ciphertext C1 as output. Then I use the same cipher, the same key to encrypt and I get C2 as output. And I do that for each of the input P's, P1 to Pn. I get C1 to Cn out. The output resulting ciphertext is just the concatenation of those C values. So that's the basic approach. Split your plaintext into blocks, encrypt each block one at a time. Same key, same cipher. Ciphertext is a combination of the output ciphertext blocks. The problem with ECB is that you can get repetitions in the output ciphertext. And you may have seen that in some of your quiz questions. Actually I don't think you'd used ECB if you may or may not have seen the repetition. But if you have two blocks which are the same on input, because we're using the same key and the same cipher, we'll get the exact the same ciphertext blocks output. If two blocks are the same on input, then the two blocks in the ciphertext will be the same. So let's say you have a large file and you want to encrypt it, you break it into blocks. If it turns out that there's some repetition in the file, then there'll be repetition in potentially in some of the blocks and repetition in the output ciphertext, which is bad from a security perspective. Any repetition in the ciphertext is some structure in that ciphertext. And it makes a potential opportunity for an attacker to exploit that structure. To work out, okay, there's some structure in the ciphertext work backwards to find out the corresponding plaintext. So ECB, two blocks are the same on input, we'll get the same output ciphertext. So it's not good from that perspective. So other modes of operation are used and these all work for different ciphers. It doesn't matter if it's AES, DES or something else. And the two you saw in the quiz was CBC, cipherblock chaining and counter mode, CTR. Let's just have a quick look at them. Cipherblock chaining, we chain the output of one step to become the input of the next step. So we take our long plaintext, break into blocks, P1 through to PN. And we start with another value, our initialization vector IV. We choose some other value. So we have a key chosen plus an IV. We use that to start this encryption. And with CBC, the approach is take your plaintext block, XOR with the IV value, then encrypt the answer of that. The output ciphertext is C1, but that C1 is fed into the next stage. So we don't use the IV again, that's used just once to initialize. The ciphertext is fed into the next phase, P2 is XORed with C1, then encrypt. So we're not encrypting directly upon the ciphertext, we're encrypting the... We're not encrypting the plaintext, we're encrypting the plaintext XORed with the previous value. And then we keep going in a chain like that. So this is a way such that if we have two plaintext values which are the same, P1 and P2 are identical, it's most likely that C1 and C2 will be different. Because P1 XORed with IV is going to be different from P2 XORed with C1. Even though P1 and P2 are the same, that we XOR them with different values. Here we XOR with the initialization vector, here we XOR with C1, which with high probability will be different from the initialization vector. So two input plaintext blocks will produce different output ciphertext blocks and that's our goal here to mix things up on the output. That's a common mode of operation use. I think in many encryption algorithms or products, if you don't specify, usually they'll use CVC. So there are others, but this is a common one. What about XOR? Exclusive OR, we'll see it again when we look at stream ciphers in a moment. Take your plaintext, XOR with a random value is a form of encryption. And it's equivalent if you have a good random value, equivalent to a one-time pad. So XOR is a good operation. Note the ciphertext should be random or random looking, random appearing. Because the idea of encryption takes some structured plaintext, encrypt and gets some random looking ciphertext. XORing this random looking ciphertext with our structured plaintext P2 should produce some random looking output, which is good for dispersing the structure from the plaintext. Encrypting that should give us more randomness in the output. So XOR is a common operation used in encryption. We'll see it in these modes of operation and in other in the details of ciphers. Note for decryption you need to go sort of in the reverse steps so that you get the original plaintext back. And I think in the quiz you had to attempt some of these. In your case you use that small 5-bit block cipher. So the table that I gave you, the table I gave you, you use in this block here. So you took, actually I gave you decryption I think, you took your ciphertext, you took your key if you're using CBC and you look up in the table for that ciphertext using that key, what was the original plaintext? And you got the output here, then you XORed that with your initialization vector, which was given in the question. And then you got P1. And then C1 was fed into the XOR in the next stage. There are other modes of operation and the other one you saw in the quiz was the counter mode. Let's go back, sorry. CBC, cipher block chaining. One stage depends upon the output of the previous stage. You look at the second stage here. To encrypt, let's say we know all the plaintext values, to encrypt P2 we must have C1. In terms of an implementation it means this must be done in serial. We cannot implement it in parallel. Because to encrypt P2 we need C1. And to encrypt and to get C1 we must first encrypt P1. So we cannot encrypt P1 and P2 at the same time. With ECB we could. With ECB if we have P1 and P2 let's say I have two cores on my computer. I have a quad core processor. I could send P1 to be encrypted on one core and P2 to be encrypted on a different core. And they could happen in parallel at the same time. Because a P2 encryption doesn't depend upon the output of the encryption of P1. So we can implement this in parallel depending upon how many processors we have. With CBC we cannot. Because to do the encryption here we need the result of the previous phase. So we cannot put it in parallel. So that's a disadvantage in terms of performance. If we want to encrypt things quickly we cannot implement CBC in a parallel mode. Counter mode is another approach. It's very simple and it has the advantage that you can encrypt in parallel. Quite easily. You choose a counter, an initial value. So another IV let's say zero in binary. You encrypt that value with your key and then XOR with the plaintext. The plaintext block and you get your psychotext. For the second plaintext block the counter two is just counter one incremented by one. So if counter one was value zero counter two would be value one. That's a counter we just keep incrementing. Where the initial value of counter one is your IV. Remember even though the counter is predictable. Encrypting the counter value with your key produces a random output. Some psychotext. We cannot predict the value. And XORing that random value with the plaintext produces random looking output, our psychotext block C1. So very simple in that we just encrypt a counter and XOR that output of the counter with a plaintext. An advantage compared to CBC is that we can implement this in parallel. There's no dependence upon the second block compared to the first block. So what I can do is I take my plaintext blocks. I generate my counter values because I know them in advance. Counter one is going to be zero, counter two is going to be one and so on. And all I do is on one core or one CPU encrypt the first block. And at the same time on the other CPU encrypt the second block. So they can be encrypted at the same time in parallel. And we'll get our plain, our psychotext out. And we can do that for as many cores as as many CPUs as we have or as many entities that we can execute in parallel. So this has an advantage in terms of performance compared to CBC. CBC and counter mode are considered practically just as strong as each other. They're both considered secure. And CBC is more commonly used because it's been around longer, but counter mode is starting to be used or is being increasingly used. And there are other modes of operation. Some are generic for all ciphers, some are specific to selected ciphers, some are specific to AES, trying to take advantage of AES structure. Effectively with counter mode what we do, take some fixed predictable input, encrypt it, and the process of encrypting produces a random output. That's the idea of encryption. Take some structured input, encrypt and get some random ciphertexts output, random looking or pseudo random. And then we do that for each phase. To encrypt our plaintext we take that random output here and XOR with P1, take this random value XOR with P2 and so on. So really all we're doing is taking our plaintext block and XORing with a random value. And it turns out that's what stream ciphers do. So this is a block cipher, but stream ciphers use the same concept. Last week we spoke about random numbers and that random numbers are important to computer security. Generating them is not easy, we need some algorithm to generate random numbers. And a block cipher is an algorithm to generate random numbers. Our encrypt block here takes some counter as input and a key and the output is a random sequence of bits, or a pseudo random sequence of bits. And same here. So XORing that pseudo random sequence of bits with a plaintext is a form of encryption. And it can be implemented very fast. We'll show some examples of different block ciphers in use later. Just notes, counter mode encryption, decryption, what's the difference? Almost nothing. So the same algorithm, it's just encryption P1 here, you get C1 out. To decrypt, C1 here, P1 out. You can use the same code, the same software, the same hardware to implement encryption and decryption with counter mode. It's just the reordering of those, that input. Then let's look at stream ciphers quite briefly. So we're skipping this one. We can use block ciphers like AES, DES and so on to as pseudo random number generators. If I need a random number for security, I can encrypt some value with a block cipher. And there are different ways to do it. One is using counter mode. We take some counter. And here we're using it in the opposite approach. We have some value, we XOR and encrypt to give us our bits here, so we have a key. So we can do it in other ways, output feedback mode is one that we skipped over in the slides, but another mode of operation. And there are other ways to use, and this was an example of using triple des for generating a random sequence of bits. Stream ciphers effectively do what we just saw with counter mode. We take our plain text, think of it as a stream, a continuous sequence of bits. So imagine you are using Skype or a voice over IP application on your computer. You're talking and the microphone takes your voice and converts, the software converts it to bits, bits that represent your voice. And as you send them across the network, you want them to be encrypted. So you wanted an encrypted voice pool. So think of the bits coming in here as the bits representing your voice, the stream of input bits, continuously coming in. You have a key, you have some pseudo random number generator. It's called a byte generator here because it's generating a byte at a time, but it generates random numbers. This is the seed to the pseudo random number generator. It produces a random number as output, represented in binary. We XOR that random number with the first, in this case, byte of your plain text. The result of the XOR is your ciphertext. So if this is your voice coming in, that is, you're talking on the computer, the microphone sends it to a codec which generates some bits representing your voice. Then the encryption software XORs those first eight bits of your voice with some pseudo random number. The output eight bits of a ciphertext which is sent across the network. And that continues to happen. As you keep generating input bits, you just keep XORing with the next random number in the sequence and keep going. Keep sending a stream of ciphertext. And the encryption is easy. Note XOR. If you XOR the plain text with this value K and get C to decrypt, we use XOR again. Take C, XOR with the same K, gives us the original plain text back. So at the decryptor, we have the same input key, uppercase K here, generate the same sequence of pseudo random numbers. And XOR the first eight bits of ciphertext with the same lowercase K as was used for encryption here. This lowercase K is called a key stream. It's the key streams used to XOR with the input plain text stream. That's the common structure of stream ciphers. And the difference between different stream ciphers is how they generate random bytes. There are different ways to do it. So algorithms have effectively different pseudo random number generators. One of them, we'll come back to that, RC4 is a commonly used example of a stream cipher. It has an algorithm shown on the following sides, but we will not go through it in this lecture. There's an algorithm that effectively implements this pseudo random byte generator. And it's relatively simple. And a key advantage of stream ciphers compared to block ciphers is that usually they're faster to implement. So it doesn't take long to generate this random value, and it doesn't take long to do an XOR. In hardware or in software, XOR is very easy, very fast. Whereas if you want to encrypt something with DES or AES, it can be quite slow. So stream ciphers are generally much faster to encrypt than block ciphers. Therefore, they're mainly or commonly used when we need small delay. We can't wait a long time to encrypt our data, like real-time voice communications or real-time communications of some media. So some common applications of stream ciphers is encrypting real-time media. For the stream cipher to be secure, the pseudo random number generator must be good. It must produce a good sequence of pseudo random numbers. A long period. We spoke about our random number generators. The sequence of numbers we generate, there must be a large variety there. We shouldn't repeat those numbers. So a large period is required there. So as random as possible, the output should be. The less random the output is, it should approximate a true random number generator. So some algorithms don't generate as good random numbers as others. That is, it's easier to determine what the next value will be or what the previous value came from. And as with any cipher, we have a secret key. There's a secret key in this case. This key, K, must be kept secret. It must be long enough to withstand brute force attacks. Often simpler to implement and faster than block ciphers. The problem with stream ciphers is that you cannot reuse the keys. You need to use a different key when you have a next set of plaintexts. With block ciphers you can reuse keys. With a stream cipher, if you, let's say you encrypt some voice call using one key, and then you reuse that key the next day and the next day and the next day, you keep reusing the same key with this stream cipher. It becomes very easy for the attacker to get the ciphertext and from multiple ciphertexts work back and get the key. So with stream ciphers it's important to change the key on a regular basis. So often those keys would be generated and updated automatically. And that's about all we want to say about stream ciphers. There's an example of RC4 here. I'm not going to go through it this semester. Note, it's developed by Ron Rivest. Remember the name because he comes up later. He has different key sizes. It's very simple to implement. So simple that you could implement it yourself in a couple of hours. It's a four loop, another four loop, and a loop with a few basic operations. So it's very simple to implement. It has a few weaknesses that people are starting to identify, but for the purposes it was used for it was quite good as a stream cipher. It was used for example in wireless LANs. There's only a few known attacks which are practical. But there are other stream ciphers which are now considered stronger than RC4. We're going to move on, give some other examples and move on to a new topic. But we're starting to finish this topic about our traditional ciphers. Up until now, after going through things like CESA and VisionAir and the classical ciphers, those and then DES, AES are block ciphers. And they're symmetric block ciphers in that both sides must have the same key. And the stream ciphers are also symmetric. Both sides must have the same key. So all of the ciphers we've considered so far have that same characteristic. Symmetric key ciphers. They're symmetry between the keys on both sides, the encryptor and decryptor. The next topic is going to lead us into an alternative approach where we have two different keys at the encryptor and decryptor. And that requires some new concepts to talk about. Before I close this and move on, any questions? Block ciphers, modes of operations, stream ciphers, random numbers. Any questions for the upcoming quiz? So the slides that I skip over, we will not cover in the exam or the quiz. So RC4 for example. And because we missed a lecture, I need to move on a little bit. Or alternatively we can have a make-up lecture. Do you want a make-up lecture? Hands up if you don't want a make-up lecture. I need more than half. So you can't put two hands up, that doesn't count as two. At this stage we don't need a make-up lecture because we missed just one. But we'll see how we go with progress. Let's encrypt. So far we've just looked at algorithms. Of course, if I give you a one megabyte file and you want to encrypt it with desks, you cannot do it by hand. We need some software implementation to do so. And implementing the ciphers and making sure they're implemented correctly is important for security because if you implement the cipher and you make a mistake in the implementation, some bug, then it opens up an avenue for an attack. So when you write your software and you develop a website that needs encryption, you probably won't implement your own cipher. You will not design your own cipher, nor will you implement an existing cipher. You'll probably take a library that someone else has developed that implements the cipher. So many people don't implement their ciphers themselves. They use something that others have used and tested a lot. And one library that's common and open is called OpenSSL. I'll show you a few examples and I'll point to some on the website that you can see more details of those examples. But we'll ask you in some homework to use this software to do some encryption and to solve some problems. The software is called OpenSSL. OpenSSL. It's a standalone application that we can run on the command line. It's also a library in that you can write your own code and link to the operations provided by OpenSSL. We'll use it in command line mode. There are many different things that we can do with OpenSSL. We can encrypt with different ciphers. We can generate keys, random numbers and some key management that we'll see in later topics. There are some different versions that's just to show the version. I'm just going to show a few quick examples of encrypting with symmetric key ciphers. Let's start with some message. So I want to encrypt some plain text. So let's create some plain text. Let's don't look and I'm just creating it long enough so we can use it in the example here. So that's just my plain text and I'm going to write that to a file. Let's call it plain text. So there's our message, our plain text for our example. How long is it? The size of this file is 72 bytes. So that's the size of the file, 72 bytes. There are 72 characters there, one character, one byte in the storage. When we use our ciphers, we're encrypting on the binary input. So not like Caesar where we're going to change h to another letter. We just treat this text as a set of zeros and ones. So 72 bytes in this case. Let's look at those bytes just so we know what we're dealing with. And to look at the binary view of a file, I can see the ASCII contents. To look at the binary contents, we need some special program. I have one called XXD. It will show me the contents of the file in binary. Minus B for binary. It will show me across eight columns, the plain text. And I'm going to have to zoom out a bit. All it does, this program XXD, and I'll zoom back in in a moment, is shows this file in its binary form. Just a sequence of bits. So the first eight bits and the last eight bits here. Let's encrypt. And we'll encrypt using a symmetric block cipher. We'll start with des. Just normal des. And we'll use ECB mode of operation. And to encrypt with des, we need a key. How do we choose a key? I'll need a key for des. How do I choose a key? Someone choose a key for me? How long should the key be for des? 64 bits. Des actually has a 64-bit key. Although only 56 bits are used, des takes a 64-bit key. Someone choose a 64-bit key. Well, we want a random key preferably. I don't want to choose a key that someone can guess. So we've actually, to generate the key, we'll create, generate a random number. So let's generate a random number first. And then we'll use that as the key. And luckily OpenSSL has a way to generate random numbers. It has a RAND operation. Generate a random number. Eight bytes long. Eight bytes is 64 bits. And instead of outputting binary, we'll make it a little bit easier and output in hexadecimal. No need to remember these operations. There's links to a detailed description of them in the website. I'll show you later. Just demonstrating what you can do. Generate a random 64-bit or 8-byte value output in hexadecimal. There it is. 16 hexadecimal digits. Now let's encrypt using that as the key. OpenSSL, ENC to encrypt. And we need to choose our cipher. And the cipher we're going to use is E is DES. And we should choose the mode of operation as well. So ECB, CBC, COUNTER and others we can choose from. To start I'll just choose ECB, the very basic mode. And to encrypt we'll specify minus E, tell it to encrypt. The input we want to encrypt, the plaintext file. I want to produce an output, let's call it ciphertext.bin. Sorry it's wrapping around, but encrypt using DES and ECB mode of operation. The plaintext file output into a file called ciphertext.bin. It doesn't matter about the extensions. And now let's specify our key. And I'll copy the key from the random number and use that. So OpenSSL will allow us to give a key in hexadecimal instead of just binary. Encrypt using DES and ECB, this plaintext using this key producing this ciphertext. Normally with modes of operation we'll also include an initialization vector. It's not needed for ECB but I'll just so we can repeat this later I'll include it here. And it needs to be 64 bits or 16 hexadecimal digits. That's in hexadecimal. That's a bad initialization vector. All zeros, you shouldn't choose that. You should choose another random value. So it should choose a random value here for my initialization vector. But just for this example. Done. Encrypted. The output ciphertext 80 bytes. Input plaintext 72 bytes, output ciphertext 80 bytes. What happened? Is that correct? What went wrong? What we'd expect is that if I have an input of 72 bytes, plaintext, I get 72 bytes output ciphertext. All of our ciphers take the same length input, same length output. 64 bits in for one block, 64 bits out. Combine the blocks, same length in, same length out. Here it's different. 72 bytes in, 80 bytes out. It turns out that with many ciphers they add some padding in there and even some error detection. To be able to detect if something goes wrong. And that's what these extra 8 bytes have been added in this case. OpenSSL has added some padding in there. It wasn't really needed. So let's add an option encrypt again but say no pad. Let's not pad just to make things a little bit simpler in the output. And now our output is 72 bytes. That's what we should have or we expected at the start. 72 bytes in, 72 bytes out. But in practice we'll often allow padding in case the input is not integer multiple of the number of bits of our block. We need to do some padding. Now let's look at our ciphertext. And it's binary. If you take those ASCII characters and try and view them, they'll produce some strange characters. Let's look at them with XXD. And I'll look at them in binary. I'll zoom out a little bit. Let's look at the ciphertext. There it is. So the binary ciphertext. And it's hard to see of course, but if you look closely, you shouldn't see any structure in here. Or should you? And this is the corresponding ASCII representation of this. Where you see a dot, it means it's a non-printable character. So this is the actual binary after encrypting. Anyone see any structure in the ciphertext? What I'd like is my structured input plaintext, this message. When I encrypt it, I get some random looking output. If you can see structure in the ciphertext, then that's bad for security. Anyone see any structure? Anyone? Alright, here's a hint. There is some structure. There's a problem. Anyone notice it? Maybe look at the ASCII representation of the ciphertext. I'll zoom in a little bit more, sorry. Sorry, I can't zoom in very easily without getting the right-hand side. I'll point it to you because it's hard to see. I've seen it before and it's not obvious. If you look at these two lines of binary and this line of binary values in the ciphertext, you see the ASCII is the same. In fact, if you look closely, the binary values are the same. This line, this 64 bits and this 64 bits are identical. So we have some structure in the plaintext. That's not good. That is bad for security. That's the problem. So was it the fourth line and the seventh line? Alright, you can see some of the bits here. Identical here. Same eight bits, same eight bits, same eight bits and so on. Why? Bonus one mark for the next quiz. For a quick answer. Quick correct answer. Why in the ciphertext do we get some structure? In this case, the structure is a sequence of 64 bits which are identical. Translate. This is the same process. Be more specific. Yep, both plaintexts are the same. Be more specific. The both blocks of plaintexts are the same. Therefore, the output ciphertext is the same because of the same key. But there's one more step. ECB. I think half a mark each, bonus. Yeah, ECB mode of operation, the same. That's the problem in this case. Let's go back and zoom out. Look at the input plaintext. And remember our blocks are 64 bits so effectively each line is one block input. So with our mode of operation P1 is hollow dot space T. P2 is his space is space O and so on. Look at the fourth block, space secret space and the seventh block, space secret space. The same two blocks. So P4 and P7 in the mode of operation are the same. Let's go back and just make that clear. We're using ECB as the mode of operation. Although we don't list them here, but P4 and P7 are the same. We encrypt with the same key using des. Therefore, we'll get the same ciphertext as output. And indeed we do. These two blocks of ciphertext are the same. And that's bad. And that's the problem with ECB. When you have same input blocks you'll get the same output ciphertext blocks. And the attacker can try and take advantage of that. So ECB usually should not be used, especially when we have large plaintext input. I will leave it for you as your homework and I'll set a homework soon that it requires you to use OpenSSL. And encrypt some plaintext, encrypt some ciphertext just to get some feel with the software and to see what it can do. And maybe do a little bit of analysis of the outputs in some cases. You can do many more ciphers. We can change to AES, different modes of operation and in fact even symmetric public keys cryptography. Since everyone's so excited about OpenSSL we'll stop there and try a new topic. Any questions before we move on about that concept of the poor security of ECB? Then if you're happy with block ciphers and symmetric key encryption, let's try an alternative approach. This is from one of our earliest lectures. We've seen this before. This is the general model for encrypting for confidentiality where what we do is we take our plaintext input, and in a cipher, take a key, the output is a ciphertext, we send the ciphertext, the decryptor, the receiver, applies the decryption algorithm, a key and gets the plaintext. Up until now, key one and key two have been the same with symmetric key encryption, shared secret key. Key one and key two are the same. There's some problems with that. It can be very inconvenient for some purposes. So people have developed an alternative where there's two different keys. And that's what the next form of cryptography we're going to cover. But to understand some of that we need some refresher, in some cases some new material on some of the mathematics that supports the new form. So that's the next topic that we'll start on today. And it's some very simple mathematics that we'll just cover with a few examples that will set us up for the next form of cryptography. So I call it number theory. It covers a few different things. Some of it should be easy. That is just refreshing your memory. Some of it may be new, but still easy. Just remind you something about prime numbers and division. So this you should follow and if you don't understand, then have a read, ask me a question. Otherwise we'll go through quite quickly. Just remind you of some terms. Okay, division, we all know about how division works, but we can talk about some divisor and B divides A. We can say B divides A if A equals some integer times B. And sometimes we write this, so just the terminology, we sometimes we write this as B and a vertical bar A. So this is the topic on number theory. B is a divisor of A, we can say. And we know about greatest common divisors of two numbers. The greatest common divisor of those two numbers can be found. Anyone unclear so far? GCD, greatest common divisor. So the greatest common divisor of seven and fifteen is seven and fifteen is one, okay? The greatest common divisor of eight and twenty-four, okay? So look at the divisors of eight, one, two, four, eight. Look at the divisors of twenty, one, two, four, five, ten, twenty. And look at the greatest common values. Simple. There are efficient algorithms for finding greatest common divisors, especially large numbers. For small numbers in examples, easy, we can do it in our head. But if you have very large numbers, there are some algorithms for finding the greatest common divisor. We say two integers are relatively prime if the greatest common divisor of those two integers is one. So our example, seven and fifteen, the greatest common divisor of seven and fifteen is one. So we say those two integers are relatively prime. Not prime, relatively prime. So that may be new to some of you. Is eight and, are eight and twenty relatively prime? Eight and twenty are not relatively prime. So if they have a greatest common divisor which is greater than one, then we say they are not relatively prime. That will come important later. And we'll see it in use a little bit later. Prime numbers. Everyone remember prime numbers? What are the first ten prime numbers? Give me a prime number. Seven, okay, give me a smaller prime number. Three, another one. One's confusing, let's not cover one. One's not really considered a prime number. Two is, two's a prime number. Two, three, five, seven. No more even numbers, of course a prime. And then the numbers, how do you define the prime number? Their divisors are one and itself. Okay, the divisors of that number are one and itself. So prime numbers, I think you're aware of, find some integer p larger than one. We define prime numbers larger than one. If and only if its divisors are plus or minus, or really one and p, one and itself. And any integer, any integer, not necessarily a prime, can be factored into its primes. Where some integer a can be written as some, the second prime, or prime two, power to some exponent and multiply by different primes. So any integer can be written as multiplying a set of primes out. And that will become important later. Very simple examples, just to keep going. What is fifteen written as multiplication of primes? Or let's start easier. What are the divisors or factors of fifteen? The divisors of fifteen are one, three, five, and fifteen is a divisor. Therefore, the prime divisors are three and five, less than fifteen, so three times fifteen. What are the divisors of twenty-four? One, one, two, six, eight, twelve, twenty-four. Twenty-four is written as primes, prime factors. How do we write twenty-four as a multiplication of primes? Which means take the prime numbers and multiply them together to get twenty-four. Two is a prime. Twenty-four divided by two is twelve. Divide by two gives us six divided by two, two to the power of three times by three to the power of one. So we can write any integer as if we multiply the prime numbers and select an exponent here, an integer exponent. So in this case it's two to the power of three times three to the power of one times five to the power of zero. We don't write that because five to the power of zero is one times all the other primes to the power of zero. That is sometimes useful. Or simply the prime factors of twenty-four are two and three. So we'll be interested later in finding the prime factors. In this case we found them as two and three. And that's what this equation states. In general we can write any integer as multiplying the primes together where those exponents are integers. Zero or higher. And a list of some prime numbers, the first, or the under two thousand. Okay let's move on. Modular arithmetic. In some of the algorithms we'll use for public key cryptography, the next form of encryption, we'll use modular arithmetic. Normal arithmetic, it's normal arithmetic but we mod the answer effectively. And it has some useful properties when we use it in encryption. So very basics. You know about mod. A mod n is the remainder when a is divided by n. A mod n, n is called the modulus. So n is the modulus in this case. We can say two numbers equivalent or congruent modulo n, equivalent in mod n. If when we take those two numbers and mod by n we get the same answer. So we often write that as A is equivalent to B in mod n. Easy one. What's the answer? Three. Three in mod ten, thirteen and three equivalent or congruent modulo ten. Because thirteen mod ten is three, three mod ten is three. That's all. When we mod by the same number and get the same answer we say they're equivalent in that modulus. Do we need more examples? Not really. Negative numbers we'll ignore for the moment. What's next? So the mod n operator maps all of our integers. So the infinite set of integers into some finite set of zero to n minus one. So when we mod by n, the answer is always between zero and n minus one. That's all we're saying. So it maps it to a particular set to note it as z n. So z eight is zero up to seven. Take any integer mod by eight and the answer will always be in that set of zero to seven. Modular arithmetic performs arithmetic addition, subtraction, multiplication and division within the confines of some set z n. So we talk about a set z eight means the answers of our arithmetic will always be between zero and seven. So when we do 10 plus 15 in mod eight, then the answer is always going to be between zero and seven. So always the answers of the arithmetic operations are always in this set. Let's go through some simple examples. Make sure we don't get some useful ones. Keep it simple and operate in z ten. Yell out the answers. Anyone? Don't all yell at the same time. Okay, this is a hard one. Four plus three again. Seven. Okay. Not bad. Four plus seven. One. Note we're using z ten here. In other words, to be precise, everything is mod ten. Sorry. There's always ten. So I'm not writing the mod operator here. We're using modular arithmetic. In this specific example, z ten, eleven, mod ten. So basically, you just add them with your normal arithmetic and mod y with modular arithmetic. You just add the numbers with your normal arithmetic and mod y ten, mod y ten. How about the inverse? What's the inverse operation of addition? I'll just write here normal arithmetic, not using modular arithmetic. Four plus three is seven. In addition, seven plus three is our operation. Subtraction is the same as adding the inverse. The inverse of plus three is negative three. So if we want to form subtraction, seven minus three is the same as seven plus the inverse of three. The inverse of three or more precisely the additive inverse of three is minus three. So that's the normal concept of a arithmetic system, making things think about the inverse. The inverse from the ad is, we use the same concept with modular arithmetic with subtraction. So we can talk about the additive inverse. A is the additive inverse of b if a plus b is the equivalent to zero and mod n. The same in our normal arithmetic system. The additive inverse of three is the number such that when we add up to three we get zero. Three plus minus three gives us zero. So we say the additive inverse of three is minus three. But in modular arithmetic we don't have negative numbers. So what's the additive inverse of using z ten? The additive inverse of three to three gives us zero. The three and the seven plus the additive inverse of three is plus. Addition subtraction is then adding the seven and mod ten to three. We're not dealing with negative numbers. We can still do subtraction. And we still use the same concept of our normal arithmetic with everything within mod ten. Thinking as adding the inverse. The inverse of three is minus three. The three plus minus three gives us zero. The same concept in modular arithmetic. We can implement subtraction by the additive inverse of seven. Where the additive inverse of seven is the number such that when we add up to seven we get zero. Or we can see what is the five minus three. The negative number is given, we're not keeping it. We have an additive inverse. Zero, the additive inverse of zero is ten to nine of three, right? The whole numbers have means we can always do subtraction in modular arithmetic. Addition, subtraction, next operation multiplication.