 We're going to recap on what we know, the very basics of cryptography or the assumptions that we're going to make because we're going to need to remember the principles of encryption, hash functions, signatures and so on when we look at HTTPS. These questions or these examples we've seen before when we summarise cryptography, so we'll go through some of them quickly, but just remind ourselves what do we know when we encrypt something? What is assumed? For example, when we encrypt some plain text P1 with a symmetric key cipher where we have a key k shared between two users x and y, then we get some cipher text denoted as C1. So just remember this notation. E is the encrypt function. The encrypt function takes two inputs, a key and a message or a plain text. So I denote the plain text as P1. The encrypt function, remember there are two types of encryption. There's shared secret key or symmetric key encryption and there's public key encryption. How do I know which one's being used? Is this encrypt symmetric or public key encryption? Just given that top equation, how do you know which form of encryption and what do I mean by the e there? The key. What does a key tell you here? Is this symmetric or it's symmetric because the key, the subscript on the key, I say x, y. To indicate this key is shared between user x and y. So to save space or time, I often won't say what type of encryption, e, but I would just make it implicit by the key. And to make it even clearer, when we use public key encryption later, you'll see we use pu and pr to represent the key. So just remember the notation. So for symmetric key encryption, let's say x encrypts P1 and sends the cipher text C1 to y. What happens if user z decrypts c1 with key kxz? What's the outcome? What can we assume or what happens? There's only eight or 10 people in the class, so we'll go around one person each. First one. What happens in this case? Z decrypts d decrypt c1 using key kxz. Does it work, the decryption? Look at what was encrypted, P1 encrypted with which key? It doesn't work, why not? Different key. So this is our assumption. If we decrypt with the wrong key, it will not successfully decrypt. Well, how do we know it doesn't work? We've made assumptions so far that when z does the decryption, they'll get some plain text which will be random. They won't recognize it. So we assume that they can recognize that it didn't work. What if this is the case? Y decrypts cr, second person. Y decrypts cr using key kxy and they get recognizable plain text. What does that mean? What do we know in that case? This is a little bit more complicated. Can anyone help him? What can we assume here? We decrypt some ciphertext cr that maybe the ciphertext I received, someone sent me some ciphertext cr. I decrypt it with kxy and the result I get is recognizable. It makes sense. If that is the case, what do we assume happened? C1 and CR are the same, possibly. Or at least we assume that the correct key has been used. The message came from x. Because it successfully decrypts, how do we know it successfully decrypted? We got some plain text we recognize. Therefore, this ciphertext must have been obtained by encrypting with key kxy. The only other person who has key kxy is x. So y knows this message came from x. So that's some form of authentication we know who it came from. Now maybe it could have been CR and C1 are the same, but not necessarily in that case. And if we get unrecognizable plain text, what do we know? I decrypt some received ciphertext with kxy, thinking it was from x, but it doesn't make sense when I get plain text as output. What's happened? What can we say maybe have happened in this case? We need to use a different key, but I am y. I think this message came from x, so it makes sense to use kxy. So what else can we assume may have happened? Somebody corrupted the message. Maybe user x did send me a message, but someone along the way modified the ciphertext to be CR. Therefore when I decrypt, it doesn't work because it's unrecognizable. However another thing happened, it didn't come from x. It came from z pretending to be x. They say I am x, but they send me a message. They didn't have kxy. They encrypted using kzy. So we know that this message didn't come from x. The ciphertext as is was not originally sent by x. It's either been modified along the way or sent by someone else. So we can use encryption for authentication. We've covered this before. What type of encryption? The top equation. What type of encryption in this one? We'll go to the back. Our new entrant. Top equation. What type of encryption has been used here? Symmetric or public? Public key encryption because pu. So e is the encrypt function, but the first parameter I denote is the key. If I use k, I mean symmetric key encryption, pu or pr, public key encryption. Remember the notation. We encrypt with the public key of x, p2, we get c2. If y receives c2, what happens or what do we know? Why you receive c2, what do you know? What can you do? Or maybe what can you not do if you're y? Can y get the plaintext p2? No, why not? y cannot see the plaintext p2 because they cannot decrypt because they don't have the private key of x. So this is our principle of public key encryption. Encrypt with one key in the key pair, pux. You can only successfully decrypt with the other key in the key pair, prx. y cannot decrypt so they cannot see p2 and that's about all in that case. If x receives c2, they can decrypt because they do have prx. So that's our concept of public key encryption. What about here? y receives c3. What can they or can they not do? What do they know? They can decrypt? Why? They can decrypt because they have pux because pux is public. Encrypted with prx, we can decrypt with pux and pux, the public key of x is of course public. Why has that? In other words, the message p3 is not confidential. Anyone can see it. So why can see the message? Because everyone has everyone else's public key. Public means everyone can see it. So what else does y know? So y learns the message p3, that's good for y, what else do they know? What do they know about this message? They know who sent the message, which and who sent it? x sent it because if it successfully decrypts with the public key of x, it must have been encrypted with the private key of x, therefore it must have been sent by x because only x has the private key of x. So y knows the message and it knows it came from x. So this is a form of authentication, similar for z, z knows p3, they can decrypt and they know it comes from x. So remember we use the public key encryption in two different orders. Encrypt with your own private key to sign a message for authentication, encrypt with the destination's public key for confidentiality. We can combine them and we'll not go through this. So all I'm showing here is that we first encrypt or sign with the private key of x and then encrypt with the public key of y. What's the result? It's signed by x, it must have come from x and it can only be decrypted by y. So that's a way to send a signed confidential message to someone. You do two levels of encryption. Yes, y can get p4 because from the outer encryption they can decrypt, they have pry, then they get the inner part and they can verify because they also have pux and therefore they get p4. No one else can get p4 because no one else has pry to do the first step. These are some principles from one of our first topics on cryptography. We'll skip through some, I can leave them on the website if you want to look at the one skip through. Hash functions, we know a couple of principles of hash functions. I take a hash function of message m1 and I get the hash value d1 if I know that the hash of m2 is d2 and I know m1 and m2 are different, what else do I know? d1 and d2 are different. Our assumption is the hash of two different messages, the hash of m1, the hash of m2, the two different messages will produce two different hash values. So we know d1 and d2 are different. That's our assumption for hash functions. In theory they may not be different, but in practice it's very hard to find two messages which do produce the same hash value. So we'll assume that they are different, d1 and d2. Here what do we know, what does this tell us, same m, the messages are the same. If the hash of m1 equals d1 and the hash of m3 equals d3 and the two hash values d1 and d3 are the same, it tells us the messages are the same. It's the reverse of what we saw in the previous one. The hash of two messages which are the same, if the hash values are the same, then the messages are the same. That's all we say here. d1 and d3 are the same, therefore the messages are the same. And we use that also for authentication to make sure things aren't modified. That's one on hashes I think. What do we know here or what do we not know? Z knows d1, but they don't yet know m1. Can they find m1? We assume no. The one-way property of hash functions is that if you have the hash value, you can't go backwards and get the original message. That's the property we require for some security features. If you have the message, you can easily calculate the hash of it, but if you have the hash value, you can't easily get the original message at this property we assume. That's just the easy case. If we know m1, we can easily find d1. And we combine hash functions with public private key cryptography to get digital signatures. And these will come up in certificates, so that's why we're recapping on some of this. We're going to see it when we look at HTTPS. We create a signature by calculating the hash of a message and then encrypting that hash value with our private key. So I sign something, I sign m1 by taking a fingerprint of that message. So I don't take the entire message, I take a hash or a small part of it, a digest sometimes it's called. And then encrypt that hash value with my private key. And we know from before if I encrypt with my private key, others can verify using my public key. So s1 is a signature of the message m1. And the common way that we use signatures, we send the message combined with the signature. We send them both. So x sends the message concatenated with a signature to y. What does y know? Y knows the public key of x, correct? And what else can they learn or observe from this? Note that y receives m1 and s1. From the previous step, we send both the message and the signature. So y knows the message, it's not encrypted at this stage. Y knows the message, they know the signature, they know pux. So what do we learn or what do we assume in this case? Y knows about the message that they receive, what do they know about it? Y knows m1 was sent by x and hasn't been modified as well. Because they receive a message, someone sent us a message, we don't know it's been changed between the source and us getting it. Maybe someone's modified across the network. So y receives a message, m1, and what they do is they verify the signature. They use the public key of x to decrypt and get h, the expected hash of m1. And then they calculate the hash of the message they actually received. If they match, everything's okay. If they don't match, something's gone wrong. Because if the two hash values don't match, it means the messages don't match. So if this signature verifies, y knows that it came from x and it hasn't been modified. So that's an important role of digital signatures. I sign a document from my signature on that document. You know it came from me and I approve that. It's harder to tell if something's being modified, but if you have a printed document, if someone changes or crossed something out, then you don't trust it unless they've signed that crossed out part as well. So in the paper land of signatures. What does z know? They know it comes from x, they know the message, and they know it hasn't been modified. The same as y in that case, there's no difference. So whoever received this signed message, they know the message and they know it hasn't been modified and it came from x. That's the role of a signature. What if the signed message was sent by x, someone in the middle modifies it, z is malicious, they change m1 to m2. So y receives m2 with the original signature. What happens if you receive this? Does it verify or not? No, it doesn't verify, why not? Different. I think you understand. So how would you write it in an exam question, the answer? Think about what you would do to verify. What steps do you take? So all right, I receive m2 and signature s1. I take the hash of m2 and I also decrypt s1 and as a result of decrypting s1 with the public key of x, I get the hash of m1. So now I have the hash of m2, the hash of m1 and since the messages were not the same, the hash values are not the same and it fails the verification. It doesn't pass. So I don't trust it. So remember the steps that you do at the receiver. In this case, hash the received message, decrypt the signature with the public key of the sender, compare the hash values, compare the one calculated and the encrypted one. If they match, verification succeeds. If they don't match, verification fails. So they are some of the main concepts that we've went through in cryptography and we'll see come up again when we look at practical applications of cryptography. One thing we didn't mention, we may see it in a couple of the examples, is message authentication codes. I don't want to spend much time on it, but in the same way that we can use public key encryption and hash functions to authenticate data, we've got also another technique called message authentication codes. And even if you don't know the equations, just remember a MAC or a message authentication code takes as an input some message or plain text and a key and it is used in a similar way to a signature to allow the receiver to authenticate. The message hasn't been modified and it came from a particular person. So even though there are a couple of examples of MACs, I will not go through them because we didn't mention them in the original cryptography lecture, but MACs are also used for authentication and we'll see them come up when we look at HTTPS.