 So we introduced the concepts of hash functions. We now want to look at how we can use them to authenticate and we'll start by a set of examples. So just remind you, so far we've said for a hash function, a cryptographic hash function, we take, we need the requirements that it's a one-way function. It has this one-way property. You can hash a message and get the hash value. So apply the function on the message, get a hash value, that should be easy, but to take just the hash value and find the original message, that should be hard. So one-way only. Finding the original message just from the hash should be practically impossible. So we need a function with this requirement or that meets this property. Another property, no collisions. You hash two messages, you get two different hash values. So we'll see some examples of why those properties are important when we use them for security. But we said in practice, this one's not true. Because the number of messages is always, well, not always, with all the practical hash functions we use, the hash value is short, so 128 bits. But the message may be long and longer than the hash value. So therefore, the number of possible messages is going to be larger than the number of possible hash values. Therefore, if a hash function maps a message to a hash value, some messages must map to the same hash value. So in theory, we'll have collisions in practice we need it to be hard for an attacker to find collisions. Let's look at how we can use hash functions for authentication. And we'll go through three examples here, showing different uses of hash functions. This example, A, we have a message we want to send from A to B. And we want to make sure that B can authenticate. Well, we've seen in the previous topic that we can use symmetric key encryption to authenticate. Encrypt. And then we decrypt. If we decrypt successfully, it means the message is authentic. But that relies on the decryptor to know what to be able to recognize the structure. We said the assumption was that when we decrypt a message, we can recognize that this is the plain text. It's not something which is not the plain text. Now, in this example, we're effectively using the hash function to add structure to the message. So what we do is we take the message, calculate the hash of the message, get the hash value, and then combine them together so it concatenate the message and the hash value, and then encrypt everything. With a shared secret key, shared with B. And we send that ciphertext to B. B decrypts. So B receives a message, thinks it's from A. From address is A, therefore decrypt with a key that is shared with A. When we decrypt, we get, as an output, if we use the right key, and now nothing's been modified, we get the message and the hash value. So to authenticate, B checks the hash of the message, compare it with the hash value received. We use the same approach using Mac authentication. We send the message and the tag to verify the receiver. We calculate the Mac of the message and compare it to the tag. Here, same concept. Receive the message and the hash value to verify, calculate the hash of the message and compare to the hash value received. And if they match, we assume everything's okay. If they don't match, something's gone wrong. Don't trust the message. The role of the hash function in this example is just to provide structure to the message. Remember, we need to be able to make sure that the message is the correct plaintext when we decrypt, and that's what the hash function does here, because if we decrypt with the wrong key, why would that happen? Well, if the message came from someone pretending to be A and didn't have the key shared between A and B, then we decrypt with a key which wasn't used to encrypt. Then we get some output, and the output would be different than the message and the hash value. It would be able to detect that it's different because of the different key in that case. So if someone masquerades as A in this case, the keys will be different. Use a C, I'm not drawer, but use a C sense. They don't have a secret key K. If someone modifies the message, again, if they modify the message, then when we decrypt and compare the hash, those values will be different, and that's used for our verification. So this one is providing structure in our message, but also using symmetric key encryption. Now, we don't normally need to use symmetric key encryption all the time. Sometimes we don't want the message to be confidential. We don't need the message to be confidential, and because encryption of the entire message takes time, we often want to authenticate the message without providing confidentiality, and that's what this example does. We take the message to send to B. I don't care if someone sees the message, but I care that B can be certain that no one's modified the message. So I calculate the hash of the message and encrypt the hash of the message with key K, a shared secret key between A and B, concatenate the message with the encrypted hash value, send and verify, verify the receiver B. And again, verification is hash of the received message compared with the hash generated by the source, the hash received. If they match, everything's okay. If not, don't trust it. Let's look and see what an attacker can do on this scheme. So what happens if the attacker tries to modify something along the way, or if they try and pretend to be someone else and see how this provides authentication? We'll try and draw it again and see what the attacker can do. And what are the general ways for an attack to take place? Anyone's suggestions? Suggest in a, and we'll show whether it works or not. No need to be correct, just a suggestion. Sorry? Modify the message, good. So if as an attacker, A sends a message to B, if you can intercept, modify the message, and then forward it on to B, and if B doesn't know it was modified, then you've been successful in an attack. You've modified the message without it being detected. So that's what we want to do as the attacker, modify the message. So let's try. What do we start with? So A is gonna send a message to B, and we have a message. We have the hash of that message. Let's call it lowercase h is the hash of m. So A calculates that, and then A encrypts that lowercase h, that hash value. And let's say it's c, we get from encrypting with a shared secret key, KAB, lowercase h. That's what we do at user A. That is a message, take the hash of the message, and the result of that, we encrypt with a shared secret key, and now we're going to send the message and that encrypted value concatenated together. So let's send them. So we send, in this case, m concatenated with c. I'll just use c because that's the output of the encryption here. The message and the encrypted hash value. We send that, but our malicious user intercepts. Before it gets to B, they intercept and do some modifications. So our malicious user, Mao, he intercepts and tries to first modify the message. So intercepts and sends to B a modified message. So he calculates m prime, Mao gets this new message which he wants to send to B, m prime, and sends m prime and the original c to B. So there's the attack, and now we need to see if B can detect the attack or not. Now, how do you modify a message along the way? Well, we haven't looked too much about the practical parts, but let's say A and B are communicating across the internet. So B is in the US, A is here in Thailand. When we send our data across the internet, it goes via a set of routers which are owned and operated by different internet service providers. So A sends it to his local ISP in Thailand, which sends it through an ISP that connects to, up to Japan, which then goes across the Pacific to the west coast of the US and then to the destination. So the data traverses through many different organizations' networks. So who is Mao? The malicious user is someone who somewhere between A and B can intercept the packets being sent and modify them. What's an example? Maybe Mao is a rogue employee of an internet service provider. So an ISP, the malicious user is some employee who has access to the routers. So in effect, he can see everything sent through his internet service provider and in this case even modify it. So the malicious user modifies the message, sends the message, the new message, but the C value unchanged. Now we try to authenticate. So B follows its normal steps. We receive a message and we receive a C value. And to make it a bit clearer, I want to denote the values received by M. Let's denote them as MR, that's an R, combined with CR. R for received. So B receives some message, let's call it MR, combined with some encrypted hash value CR. What we need to be sure is that MR, the received message by B, should be the same as the message sent by AM. That's what B wants to be sure. If it's not, then it's a problem. So what it does to verify, decrypt. It decrypts using KAB. Why KAB? Because B thinks it came from A, therefore used the key shared between A and B. It decrypts that C value received. And let's get it, let's say, the result is HR. It will be a hash value, or it should be. Because in fact what was encrypted, a hash value was encrypted to get C. So what we'd expect when we decrypt C, we get a hash value. So I'll denote it as HR. And the next step B takes is to calculate the hash of MR, the message received, and compares. That is, compares HR with the hash of MR. I haven't shown it very well, but this is compare these two values. Are they the same? If so, trust the message. If not, don't trust. Are they the same? If you're B, do you trust the message? Let's check. H of MR, so we've got a hash of MR. And HR, which is decrypt using KAB of CR, what was CR? The C value was not modified. So we know, now I know that CR, the C received, is the same as the C sent. It wasn't changed along the way. So in fact CR is the same as C. The reason I gave it a different name, because initially B doesn't know if it is the same. So I'll just try and distinguish. When B receives a message, it doesn't know whether it's the same as what A sent. So instead of using the same notation, I use the CR to mean it's different. But now I know that in this system, CR is the same as C. It wasn't modified. Therefore, when we decrypt CR with KAB, CR was this C, and we're going to get lowercase h. So let's continue here. Let's write it longer. HR, I'll repeat. Given that the C value did not change, that means CR is actually C. And what is C? If we look on the left side here, C is the encrypt of KAB of H. So decrypt. I'm just doing a replacement. Replace C with encrypt of KAB of H. What do we get? If we decrypt something, again using symmetric encryption, decrypt something with KAB that was encrypted using KAB, then we get the original plaintext. Plaintext H, encrypted with KAB, gets ciphertext. Ciphertext decrypted with KAB, gives us the original plaintext. So the output is h. Lowercase h. That's a h, not an n. So this value here is lowercase h. And what was lowercase h? How was h calculated? Well, the hash of m. So what we have is the hash of m. That's one value that b has determined. That's this value. The other value b has determined is the hash of mr. Let's look at that. The hash of mr, the hash of the message received, equals what? Well, the message received, sorry we need to scroll up, the message received was m prime. The modified message. So b received the modified message. It doesn't know it's modified. But we know that mr is the same as m prime because malicious user sent m prime with c, b receives that. So mr is really m prime. So hash of m prime. So now the two values that b has, the hash of m and the hash of m prime, is m prime the same as m? No. m prime is the modified message, m is the original message, they are different. Are the two hash values the same? No. If m and m prime are different, our property of the hash function is that the hash of those two different values should produce different hash values. So the result is that hash of m should not be equal to the hash of m prime. That is the values that we compare are not the same. And that tells us don't trust this message. It's not authentic. That's the long way to go through. It's similar to what we did with the mac function, but I've just used some different notation to try and show it from a different perspective. b receives, hashes the message received, decrypts the part attached to that message, c in our case, and compares. And in this case, if we compare, we'll get two different hash values and therefore not trust. Why are they different values? Because we said it should be computationally infeasible. If we use a cryptographic hash function, it should be practically impossible to have two messages that produce the same hash value. So we have two different messages, therefore we assume they will not produce the same hash value and therefore be different. Any questions? Is this clear so far? Good. Any problems back here? Okay. So you see why this property is necessary. Because a successful attack would be if the malicious user could modify that message and go undetected. So what if the malicious user modified the message, b receives, goes through the checks, what if the hash of m prime, if the hash of m prime did equal the hash of m, the hash of two messages were the same, then this attack would be successful. Okay? So that leads to this requirement that we must have a hash function where we can't find two messages with the same hash value. And that defines the strength of hash functions. If a hash function has that property, we'll see, we'll call it a collision resistant or a strong hash function for cryptography. You can try other attacks. That was modify the message. What else could you do? Try and modify the message. In this case we didn't change C. We used the old value. Another attack would be modify the message and try and recalculate C. But to calculate C again, remember the procedure is the hash of the message encrypted with the shared secret key between A and B. But the malicious user doesn't have the secret key but shared between A and B, therefore could not create the correct encrypted hash value. It would be detected at the receiver again. So modifying the message and trying to modify this encrypted hash value would work because of the keys. Okay. Any other attempts? Denial of service of B, how? Sending many messages and getting to decrypt. Okay. I don't know if that's relevant here but it raises an interesting practical point that calculating hash values is often in some cases can be quite slow. The algorithms can take a lot of effort. They often are designed to be slow. Usually we design our algorithms to be fast but we see later when we use hash functions, it won't be in this topic but later we'll look at passwords. And in that case we want to make it hard for the attacker to calculate hashes quickly. So some hash functions are designed to be slow. But that's the future. That's a later lecture of this topic. Okay. Let's look at another scenario. So that's our typical form of authentication using a hash function. It provides authentication that is B knows the message came from A because if it didn't verify correctly then we can't trust who it comes from. If it verifies correctly it must have been the hash value must have been encrypted with a shared secret key between A and B. Therefore, if B receives a message and it's correct it must have been created by A or B. And unless B sent the message themselves then that's proof that it came from A. So authentication of the source and integrity. If we try and modify the message along the way it will be detected. That's how we provide integrity. Make sure the data is not modified. Okay. The next one considers so let's say we have this scheme. We send a message. So let's define the notation first. S is a secret shared between A and B. Okay. A has S, B knows S, no one else knows S in this case. This scheme we don't use any encryption. We use public key or public key encryption. We take the secret combine it with the message and take a hash of the combined value and then combine that hash value in the message and send them. When B receives, B wants to authenticate. B wants to be sure this message came from A. So what B does is similar to before takes the receive message but now combines it with a secret value it knows and calculates the hash of that and compares to the hash of the message. Sorry, the hash received. The idea here is that these two to authenticate don't need to use encryption. There's no encryption steps in here. Encryption is costly in terms of processing. So to avoid encryption we're just using a hash function and combining the message with a secret. Some secret value. Let's see what an attacker can do and see how this scheme provides authentication. A sends a message to B so A has a message A also has a secret and I'll denote it as S, A, B similar to a key a shared secret key is not used for encryption here so we'll just call it a secret. So we calculate the hash of the message combined with the secret and let's say we get H and then we send them the message and the hash to B so send the message with the hash value to B and let's see if C or the malicious user in this case can intercept. The malicious user wants to modify the message what do they do? Let's say they change the message not the hash value so the malicious user just does a modification attack in this case M is changed to M prime a different message send the same hash value B receives and authenticates B receives MR combined with HR the received values of what was sent and let's note it here we know that MR equals M prime B doesn't know that yet but we know because we can observe everything that's happening and the HR equals H the original H if we could observe everything that's happening we'd know this but of course B doesn't observe what the modification is done here so B doesn't know this therefore needs to check so it goes through the checking process and back to our scheme take the message and the shared secret key or the shared secret value key it's not used for encryption combines and hashes and then compares to the received hash so B takes MR combines it with secret value shared between itself and the sender or at least that's who B thinks sent it and calculates the hash and what is that value note that MR as we know is M prime alright instead of MR M prime so we have this value and the second step is that we compare that with the hash value received so we're going to compare that value compare this with the hash value received what is the hash value received HR HR which we know is H where did H come from hash of M and SAB and now we compare those two values as we the hash of the received message combined with the secret compared with the hash value received do they match yes or no let's have a test hands up so you've got two options no hands up means penalty in the next quiz two options yes or no when we compare these two green values and don't worry I'll remember who doesn't put their hand up these two green values when we compare them are they the same hands up for yes it's okay if you're wrong you won't get a penalty hands up for no I haven't seen some hands over here what happens with no hands okay I think everyone can see the hash why are they different they're not the same because look at the contents or the input of the hash I'll come back to how I got here but let's see why they're different this is M prime combined with SAB this is M combined with SAB SAB same but different from M we said that because that was the attack change M to M prime because M prime and M are different it means the inputs to the hash function are different and our property from before the hash of two different inputs produces two different hash values so the outputs of these hash functions are different so we compare them they're different and therefore B detects this attack it knows something's gone wrong question how do I know the B does not know M B received HR HR but we know so B received HR so what B does is compares HR with this but what is the value of HR we know HR is the same as H why do we know that because M concatenated with H was sent H was not modified therefore what was received was the original H where did the original H come from A calculated it from the hash of M and SAB so B is not performing this calculation we're just using it to show that these two values are different so when you do compare them they will be different so we've defeated this attack give me another attack on this scheme change the hash that is change the message and the hash let's try so we intercept and change not just the message but also the hash value our malicious user sends H prime concatenated with let's call it H prime where H prime is what Mr. Attacker tell me what H prime is no how do we calculate H prime the hash of what hash of message prime concatenated with your own secret S mal S of malicious user we're supposed to concatenate the message and the secret shared between the two users but of course the malicious user doesn't know SAB we've modified the message yes so I'm the malicious user I change the message to whatever I like and now I try to recalculate the hash I can I take the new message combine it with some secret value I wrote S mal because we know it's not SAB because that's a secret only A and B know and I get H prime and send that to B and it comes to B and we'll denote what's received again as the received values as MR concatenated with HR that is that's what B receives the values we know as this oracle that can see everything that's happening we know that what is MR what was sent to B M prime MR is actually M prime HR the received value is H prime so let's go and continue for the verification we step one we calculate hash of the received message combined with the secret key shared between A and B the secret value SAB and we know MR is in fact M prime so that is equal to the hash of M prime concatenated with SAB there's our first value what the B takes is they compare that value to the hash received what is the hash received HR which we know is the same as H prime where did H prime come from our malicious user our attacker calculated it as given by this equation it's the hash of M prime and S the secret value of AB B compares the values again I think you'll see they're not the same because the inputs to the two hash functions are different therefore the hash values as output will be different we compare them they're not the same we detected his attack the hash function is known we assume the function the algorithm the same as we assume the encryption algorithms are known we assume the algorithms used in all of this are known let's say they're using some software so this is all done in software A and B are using some software some email client and it's known that that software uses this hash function so the attacker knows the hash function different values don't trust malicious next attack anything crack the SAB if you know SAB if malicious user knew SAB here they wouldn't have used S now they would have used SAB and we would have got to hash of M prime with SAB compared to the hash of M prime and SAB they would have been the same and the attack would have been successful so it's about keeping SAB secret okay same with encryption our keys must be kept secret if not they're not called secret keys but how can you find SAB how could the malicious user find SAB brute force what about trying to go backwards from the hash value so if we have SAB this would be a successful attack by the malicious user how do we find SAB well an approach so this is the malicious user what do they know the malicious user knows M so let's known to the malicious user M H because they received M and H okay they know the hash function they want to find SAB if they can they can do an authentication attack so how do they find SAB apart from guessing well one approach note what is H H is hash of M concatenated with SAB that's what lowercase H is now what do we know we know the hash value we know M we know the hash function we want to find SAB what do we need to do we need to calculate the inverse of this hash function we know the output if we knew the input it'd be easy to find SAB because SAB is just the difference of the input and the message M so to find SAB if the attacker can do the inverse of the hash function what would they find that is if the attacker could calculate a writer as H the inverse function of lowercase H what's the answer so in lowercase H is the hash value if we could do the inverse function of that the answer would be the original input which would be M SAB if the attacker now knows M SAB they know M so SAB is easy to find because let's say M SAB is 1100 bits in length if we know M and M is 1000 bits it means SAB is the last 100 bits it's just concatenation it's just one combined with the other so if we know the full part and we know one part of it then we know the other part of it so if we know M concatenated with SAB and we know M finding SAB is direct from here so we'd find the secret so this depends on being able to calculate the inverse of the hash function that is given the hash value go backwards and get the original input can we do that? no well if we have a cryptographically strong hash function we've said a property is it's practically impossible to go backwards that is given a known H value so if you know H to find an M so it's practically possible given a known H to find M that is go backwards to do the inverse function so that's why we need the one-way property here if we didn't have a hash function with this one-way property and we used it in this authentication scheme the attack would have been successful but there are two questions on hash functions so far everyone's quiet means everyone understands is that a safe assumption or everyone's listening to music on their headphones question? that two questions or is that a yawn disappointed so this scheme here was performed authentication but without the overhead of encrypting data sometimes so it's one way to do authentication and we saw some attacks and see why they unsuccessful why they were detected and also it demonstrates this requirement for the one-way property this one is similar but now we use encryption as well so you see it's a combination of take our secret and the hash of that but instead of sending that to make sure everything secret confidential send using symmetric encryption of all of those values so the previous one everyone can see the message no confidentiality but if we also want confidentiality then we can get that as in this approach this slide demonstrates that I've reversed the order of the topics so you covered hash before Mac functions I think we've said it several times before using encryption we want to avoid sometimes because it's slow it has some costs involved with it so having an authentication scheme that doesn't rely on encrypting the entire message is useful and Mac functions and hash functions can be used for that Mac functions we mentioned in the previous topic note what's the difference between a Mac and a hash function if you look at the concept let's write them down our hash function and from the previous topic a Mac function what do we do a tag was the Mac of using a key a shared secret key and a message but we use them for similar purposes sometimes a Mac function is called a keyed hash function sometimes we implement the Mac using a hash function but introducing also a key because we use it for the same purposes very similar except a Mac also takes as a key as an input if you look at the last few slides of the previous topic Mac, the Mac function you'll see there's one called a Mac hashed Mac which is a Mac function but uses a hash function so it's just a way to combine a known hash function and a key as an input the reason for that is that hash functions there are many or there are several well known hash functions and the properties and the performance of them are known and the security is available to implement them so in some cases it makes sense don't develop a new Mac function just use an existing hash function but introduce a key as well and H Mac does that H Mac was on the last few slides of the previous topic I will not go back to it let's look at, let's introduce digital signatures now so on this topic we'll look at digital signatures then we'll come back and look at our properties collision free and one way property but that will be next lecture and then actually before digital signatures a quick example of some hash functions MD5 and SHA are two hash functions let's show you we're not going to go into the details of any hash functions the algorithms and how they are implemented I'll just show you some examples just set it up so it will work easy I think we mentioned before so we have a plain text message actually this is the wrong example we have an input message plaintext.txt we showed before this is our message that we want to send we calculate the hash of that MD5 is a hash algorithm a hash function so that's one hash function which is quite popular MD5 sum is just a program to calculate it for us on a Linux so it takes as an input the the input message and returns the hash value MD5 produces a 128 bit hash value so represented here is what 32 hexadecimal digits so 4 bits per hexadecimal digit there are 128 bits there and it looks random that's the requirement of hash functions you hash an input message the output hash value should be have random properties appears as a pseudo random number if you hash another message you should get another random hash value as an output so if we change our message actually copy it I'll copy it and now change the message just change a letter and now calculate the MD5 sum of that modified message here's the MD5 sum of plaintext.txt 911d2 and the MD5 sum of the modified message B64 see the hash values are completely different that's what we desire for our hash function random looking hash values even if the input messages are similar so we said with two different input messages we should get two different hash values another example I've got from before I've got two files there are 128 bits 128 bytes in length so file and file 2.txt 128 bytes in length are the files the same there are some binary files so we're not opening it in a text editor let's open in a hex editor are these two files the same who can see so just two binary files file.txt and file 2.txt are they the same it's hard it's not obvious or is there a difference somewhere remember this is a hex editor these are the hex values these are the hex values converted to ASCII to dot if there's no printable ASCII character they are different there are several differences I think one of them I can see look at this fourth row going backwards B, 5C, 3 7, 3, 0, 8 all the same F and 7 so there's a difference there and I think there are a few others around there there are six or seven bits that are different if you look at the binary so there's a few small differences in these files but just a few bits different so when we do the MD5 sum of the first one we get this and the MD5 sum of the second one again what are we going to get are we going to get a hash value which is the same different or similar same close or completely different we hope it's completely different the hash of two similar messages will produce two completely different hash values uh oh it's the same hash value what went wrong what went wrong is the MD5 is not it's considered cryptographically secure no longer at least with MD5 with that as a hash function it's possible and people have found two different messages that produce the same hash value here's an example two different messages but they produce the same hash value now of course these messages are not in English but they're to demonstrate that they produce the same hash value in practice an attacker usually needs to find two different messages which make sense that produce the same hash value which is much harder but still nowadays for security MD5 is considered insecure it's a hash function but it no long where it doesn't have this property that it's practically impossible the same hash value people have found collisions with MD5 and it's not so hard to now in the past MD5 was considered secure but today it's not recommended for security applications a new algorithm is SHA the secure hash algorithm and there's the SHA-SUM I think SHA-SUM is a program that uses a different hash algorithm called SHA a secure hash algorithm and if we apply SHA-SUM on both files two different files on input SHA-SUM returns two different hash values so SHA is considered cryptographically secure so it's a better algorithm than MD5 with MD5 this specific example produces the same hash value but the same files produce different SHA hash values this form of SHA produces a 160 bit hash value there are other variations with 256 bits 512 bits which are even more secure so we desire this collision free property but not all hash algorithms have that collision free property so we need to choose one that does have the property to be secure let's go back to one of our schemes we went through this scheme yeah this scheme we went through this scheme we take the hash of the message in crypt with the key the key that's shared between A and B and we can verify at receiver B which means when B verifies B knows that this message hasn't been modified and the message came from A so authentication is proving that the message came from a particular sender what's a signature to find a signature when you sign your name on a piece of paper what's the intention verification that the paper is authentic the message on that paper is authentic and verification to who when you sign a piece of paper what's the purpose there's a message on the paper you're trying to make sure that if someone sees that paper they know it came from you so your signature when someone has a piece of paper with your signature on it the idea is that that other person who has that piece of paper is sure that that came from you so that's the signature if we try and implement a similar mechanism using hash functions and symmetric key encryption we could think here's our message we take a small representation of that message the hash of that message and not sign it and encrypt it with a shared secret key we could think this part is the signature this is the message so you have a message and you sign the bottom so you can split between message and signature so think of the same concept here a message and a signature where the signature is the encrypted hash of that message now someone receives this they receive M and the encrypted hash the message and the signature the idea of a signature is that we can verify later that this message came from A can B verify that this message came from A when B receives this message does it know it came from A yes that's our verification here that is B receives it it does the check and it confirms this message came from A but with a signature we'd like to be able to allow anyone to verify the message so when I sign something I'd like to be able to give it to all of you and all of you could verify it came from me not just one person so I don't just send it to one document everyone knows it came from me so let's say there was another user C not a malicious user just another normal user and C wants to verify the message came from A how does C do that can C verify a message came from A how would C so this message was signed and sent to B but then the signed message is also made available to A with the intention that A needs to verify this message came from A how does C do that how could C do that what would they need to know to do that any ideas are you too smart how would we do it with this scheme yes use public and private key but we're using symmetric key it's possible but under certain unrealistic conditions we'll see so if C needs to verify this that is there's a message sent to B and then later C needs to make sure it came from A well first thing they would need to know the key they would need to know KAB okay because it was encrypted with KAB and to verify we must have KAB so there's the first step but it's a problem because for C to verify this message C needs to know the secret shared between A and B so imagine we need to somehow exchange messages between users and there's another entity that needs to verify who sent those messages that's what we're trying to achieve for C to verify this message came from A it would need to know KAB which defeats our purpose of a shared secret between A and B if C also knows it so there's a problem if we want to use this scheme as a signature what's the second problem what else stops us from using this to implement our signature let's say C does know KAB let's assume it does so they have a message I'll give you the message that you are user C and this is the value that you have and think of this part as the signature you have this and you need to confirm that this message came from A that's your task and let's say to make it easy you also know KAB those to use A and B they trust you with their key so they give you their key so now your job is to confirm that this message has been signed by user A how do you do that or can you do that decrypt so as this user C if I know KAB I can decrypt so I will not write it down the steps but if I know KAB of course I can decrypt this I'll get the hash of M compare this hash with the hash of the message if they are the same assume they are authentic does that confirm that this message came from A no it doesn't it's either A or B and that's the point I'm trying to get to if we use symmetric key encryption we can use it for authentication but this idea of a signature a signature is that this message came from one person in the world if we use symmetric key encryption the best that we can do if we knew this key would be confirmed that this message came from A or B why? because A could have created this because A knows the message they know the hash of the message they know KAB or B could have created this they know all of that as well so this could have come from A or B therefore some third party cannot verify which is the original sender is it A or B we don't know there's no way to be sure and therefore using symmetric key encryption cannot be used for a signature so I called it a signature it's not if we try to use this for a signature it won't work because the best we can do is confirm it came from two users in the world but a signature should be unique to one user so as was suggested before for a real signature or a digital signature we don't use symmetric key encryption we use public key encryption so we move away from a symmetric key encryption and move to using public key encryption for a signature and that's what we're going to cover on Thursday so we'll look and go through digital signatures see what they are how something is signed how a signed document is verified and see the role of public key encryption and hash functions in that let's stop there and we'll continue that on Thursday