 A digital signature. Remembering that the purpose of a signature is it acts as a confirmation that someone agrees to that message. I sign a document, I confirm that I've seen it, I created it, I agree to the contents of that message. We want the same thing for files or messages. I send a message, I want to sign that message. How can we do that? We want to be able to prove to anyone that a message originated or is approved at a particular user. We can't use symmetric key cryptography. The problem with symmetric key cryptography is that there's one key and two people in the world have that key. Let's say user A and B share a secret. A has the key. Anything encrypted using that key could have come from A or B. With symmetric key cryptography, we don't have confirmation that a message encrypted with that key comes from one particular user. It could have come from two particular users. Even though symmetric key cryptography, if someone receives a message, let's say A, they can verify that it came from the other user, B. That's okay. But we can't have a third party C to prove that the message came from B because that message may have also come from A because both A and B have the key to encrypt. So that's where public key cryptography comes in because there's only one person in the world that has a private key and we can confirm a message came from them using that approach. The concept is quite simple and we've seen it when we introduced public key cryptography. A user signs a message by encrypting with their own private key. I have a message. I use my private key to encrypt and the nature of public key cryptography is it can only be decrypted with my public key. So if it successfully decrypts with my public key, it means it was encrypted with my private key. So confirmation of this signature or verification of the signature is done by... The signature is attached to the message. We send the message and the signature. In fact, we could just send the signature as is. We'll see at a disadvantage of that in the next approach. And then we verify the receiver and the receiver uses the public key to verify. Any questions? You've generated your RSA keys for the last homework and you're going to use them, so don't lose your private keys. If you don't have your private key, you can't do the next homework because you're going to sign a document or sign a message. And the way that you will sign, you'll use your private key. You will send the message encrypted with your private key to the destination and they will verify by using your public key. If it successfully decrypts with your public key, we get the message and we know that that's the correct message. It came from A because the only person who can encrypt such that it successfully decrypts with the public key of A is user A. Only user A has the private key of A. So that's the concept. In practice, we don't encrypt the entire message, we encrypt a hash of the message so we can do a confirmation just for the... on across the hash. So this is the practical digital signature. And in fact, from now on, when I refer to a digital signature, use the hash of the message. We have a message M. To sign the message, to generate the signature S, we encrypt using my private key, the hash of that message. Hash the message, encrypt with my private key, I get signature S. S is quite small because the hash value is small. When we encrypt it, we get a small signature. Even if the message is 10 gigabytes long, the signature is a fixed size. So what we do is we send the signature and the message. And this is good for performance in there. There's not much communication overhead. If my 10-gigabyte message concatenated with a 256-bit signature, those 256-bits don't create much communication overhead. There's not much extra to send. We send the message and the signature S. The user verifies by decrypting the signature with the signer's public key. You know it came from Steve. You use Steve's public key to decrypt. And you get a hash value. And you compare that hash value with the hash of the received message. If they match, everything's okay. If they don't match, we have a problem. Let's see some quick examples of how the digital signature is applied. And we assume that users have keys, key pairs, in fact. We have user A and user B. And they know, let's assume to get started, they know each other's key pair or they know each other's public key. So A has its own key pair. They know P-U-A, P-R-A. I know my own key pair, but I also know P-U-B. And similar for B, it knows P-U-B, P-R-B, the private key of B, and the public key of A. Everyone knows their own key pair plus other user's public key. So the normal case. The normal case is we send a message from A to B. Let's say there's no malicious user in this case. And the message we can denote as message M1 concatenated with the encrypted hash value. So that's the message plus its signature, where the signature is obtained by hashing the message and encrypting with my, or the sender's private key. This process is called signing. The encryption of the hash is the signing. We sign the message and B verifies. When they receive the way that they verify, they decrypt the signature. It came from A, we decrypt with a public key of A, and I'll say S, which part is S? This component, so I don't have to write it all again, is S, the signature. The encrypted hash value is the signature. They decrypt the signature component. What do they get? Well, they get the original input, the hash of M1. And then they compare. Does this hash value equal the hash of the receive message? What was the receive message? Nothing's been modified here, so the receive message is M1. Yes, they're the same. Does the hash of M1 equal the hash of M1? Of course. So this is the message has been verified, and we know that the message came from A because it successfully verifies using the public key of A. That's the normal mode of using a signature. Questions on how to use the signature? We sign with our private key, but we encrypt the hash of the message, not the entire message. So let's see what happens when an attacker, a malicious user, tries to do something. Same initial state. They know each other's keys, public keys, and they know their own private key. And now we do the same. We sign a message and send it on to B, where we send M1 concatenated. Let's denote it now to be more precise. S1, where S1 was calculated as encrypting using the private key of A, the hash of M1. So this is what A sends, the signed message. Malicious user intercepts. Let's see if they modify the message. What happens when we change the message? M1, let's say changes to M2. We don't change the signature in the first attack. So leave it as S1. And then the verification steps at B to verify. We decrypt the signature using the public key of A. We know it came from A. We decrypt the signature. When we decrypt, then we get H of M1. Why? Because S1 was the H of M1 encrypted with a private key of A. Therefore, if we decrypt S1 using the public key of A, we'll get the original input, H of M1. And then we compare. Does H of M1, the decryptive value, match the hash of the received message? And under our assumed properties of our hash function, the hash of two different messages, the hash values will be different. So no, it won't match. Our collision-free property. The attacker can't find two different messages which produce the same hash value. We say that the verification fails. And you'll see this is similar to what we've done already with the authentication schemes. If we modify the message but not the signature, we get an error. Because the hash received, H of M1, doesn't match the hash of the received message, H of M2. What else could the attacker try to do? Well, we modify the message and the signature. But how do we create a new S2? Well, we can calculate the hash of M2, but it needs to be encrypted with the private key of A. The malicious user doesn't know the private key of A. Therefore, they cannot produce the correct signature. The correct signature is the hash of M2 encrypted with the private key of A, but we don't know the private key of A. So that would be detected. What else could the malicious user do? A masquerade attack, pretend to be A, sending a message to B. But if I want to pretend to be A, I need to know the private key of A. Because what B is going to do when they get a message thinking it's from A is use the public key of A. So again, if we try to pretend to be A, we don't have the private key and the attack will be detected. So very similar to what we saw with the attacks when we used symmetric key encryption, but now we're using private key encryption of the hash. That is, it's very similar to this case, where we encrypted the hash value with a shared secret key. Now we're encrypting the hash value with a private key. The difference is not the security, it's about proving who sent the message. If we use shared secret key and we have a signed message, either A or B generated that signed message. But if we use public key encryption, if we have a signed message, it came from one particular user in the world. And that's what a signature should be. We can confirm who the source is. And digital signatures are a very common application of public key cryptography today. Which algorithms are used for digital signatures? We can use RSA. So for the encryption decryption algorithm, RSA is a common one. But there are others. There's a special algorithm developed for digital signatures, DSA, the digital signature algorithm, which is used in the digital signature standard, DSS. But there are variations. And we may come across them in practical examples of especially web security. It's not just RSA, you may see DSA, a variation of DSA with something called elliptic curve cryptography. EC, DSA, El Gamal is another one. And there are a couple of other approaches. So there are different algorithms used to encrypt for digital signatures. And we can use different hash algorithms. MD5, SHA, SHA2, SHA3, and so on. We should use a secure hash algorithm. MD5 no longer considered secure. So SHA2 or above. And those hash algorithms, we need them to have particular properties. And we've talked about the general properties of collision-free and one-way property. Let's come back to those properties to finish the lecture today and look at them. And we'll define them a little bit further.