 In this lesson, we'll be talking about another way to implement a mono-alphabetic substitution cipher that doesn't rely on addition like the Caesar cipher. Instead we'll be looking at what we call multiplicative ciphers. So instead of using the Caesar cipher where we added a key to each character value, let's look at what would happen if we instead multiplied by a key value instead. So here is our plaintext alphabet with corresponding numerical representations. And let's multiply each of those values by three. So in this example, our key would be the value of three. If we can see that these numbers get rather large, bigger than 26, but we know that's not a problem, we've seen that before with the Caesar. So we'll mod all of them by 26, and we can see the first few characters work just fine. We get ADG, JMP, SVY, kind of incrementing by three until the end of the alphabet. And then when we mod 27 by 26, we get one, and we wrap back around. Not perfectly, we don't go back to A, but we're offset by one, giving us the ciphertext character of B, and then so on down the line for the next group, and we get to the end of the alphabet, and we mod by 26 again to get the last little piece there. If we can see that this is a valid mapping, multiplication gave us a one-to-one relationship between the plaintext letters and the ciphertext, no repeats. But let's try it with a different key. If instead we had chosen the value four to be a key, and we multiplied everything by four, you might already see a problem here. All of our ciphertext-intercripted character values are even, and if we mod by 26, they're going to stay even. Remember, we're just kind of reducing by multiples of 26. So the first handful of characters seem fine, the ones that are already zero to 24. But when we get to the second batch, well, actually, things still look pretty good. No repeated characters. Notice this third batch here. When we get to the letter N in the plaintext, when we mod by 26, we get back to zero, a little too early. There's a lot of other ciphertext letters that haven't come up yet. And in fact, when we do the last batch, we see, well, the first half of our mapping is the exact same thing as the second half. This is considered an invalid mapping. For each character in the plaintext, we're supposed to go to just one and only one character in the ciphertext. But we can see here that that is not the case. We have repeated letters in the ciphertext that go back to different letters in the plaintext. And there's no way for somebody who received a message that was encrypted with this key to know if they have a letter A in the ciphertext, whether it came from the letter A or the letter N in the plaintext. This is not going to work. So why did it work for one and not the other? Let's take a look at some other key values to save us time. Let's just take a look at maybe what we've got three and four already up here. If we'd used a key of two, that would be an invalid mapping. Key of six is invalid. Key of eight is invalid. Key of 10 is invalid and key of 12 is invalid. Well, let's check out these odd members over here. Key of five was good, seven OK, nine's all right, 11 works. I'm feeling pretty good. Oh, key 13 does not work. In fact, key 13 seems to fail in spectacular fashion. We only have two letters used in the ciphertext A and N. So let's dig a little bit deeper. Maybe let's try the remaining values for keys. Well, here we are again, key 14, 16, 18, 20, 22, 24 do not work. The remaining odd ones do. So we're able to figure out here that for the valid multiplicative ciphers, keys for a 26-letter alphabet that are valid are one, doesn't actually encrypt the message, but mathematically it's fine, 3579, not 13, 1517, 19, 21, 23, and 25. What we don't know is why those are valid keys. Take a moment and think about what it works with these numbers or what properties do these numbers have and what properties did the keys that didn't work have. See if you can make a guess. And to help us maybe solidify that guess, let's look at languages with other alphabets. So if we look at the Italian alphabet, it only has 21 letters. And I did this work prior, so you can trust that it's correct. The valid keys for those multiplicative ciphers, so alphabets of 21, are one, two, four, five, eight, 10, 11, 13, 16, 17, 19, and 20. And their invalid keys are 3679, 12, 14, 15, and 18. Notice we're not listing zero as an invalid key in any of these. Zero is going to be an invalid key for any multiplicative cipher. If we multiply the plaintext number by zero, you're always going to get zero. You got no shot at it working. So we're going to kind of leave it out of the conversation. It's implied. If you look at the Nepali language, it has 64 letters in its alphabet and we got a long list of keys here. Our address works out to be all of the odd numbers, one, three, five, seven, nine, 11, 13, all the way up to 63. And the invalid keys are all the even numbers there. Russian has 33 letters. Technically it's 10 vowels, 21 consonants, and two modifying characters. And if you consider all 33 of those as letters, we get the valid keys listed on the screen here. Notably absent are 369, 11, 12, 15, 18, 21, 22, 24, 27, 30, and so one more example, the Hawaiian alphabet, modern day Hawaiian alphabet, consists of 13 letters that are on the screen, which includes that single tick at the end. The valid keys are all of the numbers. There are no non-zero invalid keys for Hawaiian. So maybe update your guess and we'll get a conjecture here that maybe we can prove in just a moment. All right, here's our conjecture. If our key, which we'll represent with letter K and the size of the alphabet, which we'll represent with letter M, share some common factor other than one then K is an invalid key. Let's see maybe why that's the case here. So let's choose a key of six and an alphabet of size 26. We can see that K and M share a factor of two. So instead of writing as K equals six, let's write it as K equals two times three. And instead of writing N equals 26, let's write it as M equals two times 13. We call this the prime factorization of these numbers. And there's actually a theorem in mathematics called the fundamental theorem of arithmetic that guarantees that every integer can be written as the product of its primes. This is often used when we're looking for common factors between two numbers. If we'll write it as the product of their prime factors, it makes it easy to identify which prime factors they have in common. So here we can see it's two. When we look at the values for M, that other factor, in this case 13 should always be guaranteed to be smaller than M, which makes sense if we split up M to be the product of two other numbers that aren't one, those numbers must be smaller than 26 if they're going to multiply to equal 26. So that 13 is guaranteed to be smaller than M itself, which means that if we go over to 13 in our plain text, which is the letter N, let's look what's gonna happen when we multiply by K here. We're gonna get 13 times six, which is the same thing as 13 times two times three, which is the same thing as 13 times two times three. Multiplication order doesn't matter. So if we kind of take that 13 and two and multiply them together, we get 26 times three, which means that, oh, look at that. Then whatever number we get is going to be a multiple of 26, which means that when we mod by 26, we're going to get a zero. And lo and behold, it is true. We would have got 78, 78, mod 26 ends up being zero. We end up getting the letter A much too soon. We would not want to see the letter A again anywhere on this mapping. But if you think about it, maybe I just got lucky? No, I don't think so. Let's try it again. Let's try it with a different alphabet with a K of 12 and an M of 21. They share a factor of three. So let's go over again, look at that non-shared factor from M, which is seven. Seven is guaranteed to be somewhere between one and 20. It has to be. So if we go there and we multiply again by our K value, by rearranging the factors, we are guaranteed that we're going to have a three in our key, because that's the shared factor, which means we can guaranteed group it with the non-shared factor in M of seven, which means that we're guaranteed that this product is going to be a multiple of M, 21, which means that we know with certainty that this product will be zero and be mod by M. Let's take a look at an example where we have a K and an M that don't share any factors. So we have a 13 letter alphabet, so M is 13 and let's try a K value of five. So if K and M only share the factor of one, then there is only non-shared factors left. So if we go to the non-shared factor of M, like we've been doing, we're actually have to go all the way out to 13, which doesn't actually exist. And if we were to go out there and do five times 13, since that must be a multiple of M, it's the only factor, the only factor of M besides one is itself, when we mod by 13 to figure out what letter shows up there, we'll look at that. It's A again, which actually makes sense. We have not repeated. We've used every letter in the plain text alphabet as a cipher text letter before we repeat, which is what we're hoping for. So I think we've done a good job explaining why our conjecture must be true. Let's call it a result. So we could summarize our work as saying, given some multiplicative key K that we're going to use for an alphabet of size M, K is a valid key if and only if the greatest common divisor between K and M is one, meaning that the only shared factor, the largest shared factor, and in this case, the only shared factor, between these two numbers is one. And that actually leads us to a definition. Numbers that have that property in mathematics have a special name. So we could say if any two numbers A and B share no factors other than one, meaning their greatest common divisor is one, we can call those numbers relatively prime or also co-prime. We'll see that these types of numbers in this relationship is extremely important for our work in cryptography, especially around operations that are fundamentally built upon multiplication. Now let's take a look at how we could use a key to decipher a message that was created using a multiplicative cipher. So here we've got our mapping from plain text to cipher text again, using a key value of three that one worked out okay. And we've got our cipher text now, we just kind of flipped it a little bit with its corresponding numerical values, if you want to bring that back to the plain text alphabet. Well, let's see what we can do. Since Caesar we were able to add a key to in cipher and then subtract that key to decipher, addition, subtraction, inverse operations, it might be a first natural guess to say, well, I multiplied by three to encrypt, let's divide by three to decrypt. But what we're gonna see here is that mod that we did in between the mod by 26 to wrap around these numbers is gonna throw a little issue here into this process. Everything's going great for those first letters where modding by 26 didn't actually change the value, but as soon as we get to b, which has a numerical value of one, and we divide it by three, we've got issues. We divide one by three, we get one third, and one third is not integer. And our entire system for converting between letters as numbers is built on the fact that every letter has an integer representation. One third does not correspond to a letter. And in fact, if we were to follow this through for all of the remaining characters, none of those numbers are divisible by three, meaning none of them have integer representations, meaning none of them have a character that we could map to. This is a problem. The good news is we have a solution. Instead of dividing by k, we can borrow a trick we learned from the Caesar cipher. We could actually multiply by the multiplicative inverse. So as I mentioned, we did this with Caesar. We saw that we could subtract by the key value k, or we can add by some other key that we called the additive inverse. So let's see how that might work with multiplicative inverses. First, let's review real quick from Caesar. So when Caesar, we did our plain text p, we added on k, and then we added on our additive inverse, which we decided in an earlier lesson that we could compute by doing 26 minus k, pretty easy to do. And that would give us a plain text value of, or sorry, a value of p plus 26. So we take p, add k, add on the inverse, we get to p plus 26. We might be thinking, mm, that's not back where I started. Did I really undo the encryption? But remember, when we mod by 26, p plus any multiple of 26 is equivalent to p itself. So we really are back to plain text again, assuming we mod by 26 after we're done adding on the additive inverse. And remember, additive inverse, when we're talking about any two additive inverses means they simply sum to zero in the mod that you're working in. So in our case, mod 26. So that could be in numbers like three and 23. They don't actually add to zero as an equation, but if you were to add those together, get 26, and then mod by 26, they are in fact equivalent to zero. And we can see that here. So let's see how this would look like with multiplicative inverses. Multiplicative inverses mean that if you multiply them together, they multiply to one, or in this case, are equivalent to the number one and whatever modulus that you're working in. We'll keep thinking about a 26 letter alphabet for now. So if I were to take my plain text number and multiply it by K, I want to multiply it by the inverse of K and by the inverse, I mean, I want it to multiply with K to result with an equivalency with one. If I do that, I'm essentially multiplying P by one, which means I'm back to plain text again. So how do we find these special values of K inverse? Let's say by looking at our valid keys in mod 26, here are their inverses. And let's just verify that these are in fact the inverses. We'll dig into how we can compute these in just a moment. But let's verify, let's multiply them all out. And then we're gonna mod all of those answers by 26. And we have verified in fact that one and one are inverses of each other. K has a multiplicative inverse of nine, and later down the line nine has a multiplicative inverse of three. Five and 21 are multiplicative inverses of each other. Seven and 15 are multiplicative inverses of each other. 11 and 19 are multiplicative inverses of each other. Then we got a bunch of repeats. And then we can see that 25 are multiplicative inverses of each other as well. So every valid key has a multiplicative inverse that we can use. Let's just real quick verify that these keys work in practice. So we'll try out a K value, a key value of three, and it's inverse of nine. Let's just pick a couple of characters that we computed earlier. We saw that J went to B, K went to E, and 11 went to H. Let's take those B, E, H, and see if we can get them back to J, K, L. We'll take their numerical values, one, four, and seven, multiply them by the inverse key of nine, mod by 26. And we can see we get back to nine, 10, 11, which correspond to J, K, L. So this process does work. We've verified that multiplying by K inverse works to decipher a message that was enciphered using a multiplicative cipher. But we still have this lingering question. How do we find these inverses? We're working with a 26 character alphabet now, but what if we worked with a different language or a larger alphabet? How can we compute those inverses? Well, in an inefficient way, we need to just try every number, say N, that's less than M, to see if K times N, your key, times this value that we've tried is in fact equivalent to one after you mod by N. So that'd be equivalent of saying, say I've got a key of seven and mod 26, I'm just gonna try all the numbers less than 26 to see if any of them multiply with my key to give me a one after I mod by it. That's gonna work. And if it does, then we'll know that whatever number we just tried is the inverse, but it's kind of bad because you might have to try a bunch of numbers. When we're working with an alphabet with only 26 letters, trying 26 different things, computer can do that pretty well. But in this course, we're ultimately gonna be working with modern encryption systems where our modulus, the M that we're working with is going to be in the hundreds or thousands of digits long. Trying all of those is not just kind of an annoyance, it could take lifetimes or thousands of years for even the best computers to try all of these. And we're gonna see that brute force method of finding an inverse is not the way to go. Luckily, there's a clever little bit of math that's gonna help make this a little bit more efficient for us and we're gonna learn about it in our next lesson.