 The problem we're dealing with is how to get a key from one entity to the other, especially a secret key. Two users, we know we want to use shared symmetric key encryption to encrypt our data, but for that to work, the receiver of the data, of the encrypted data, needs the same key as the sender. And we can't send the key across a public network because someone can intercept that and find the key. So we need to encrypt that key when we send it across the network, but we get this problem of, well, what key do we encrypt it with? And so far we've looked at using a symmetric key encryption to encrypt our symmetric key. So we have two types of keys. So to get what we call a session key from me to you, I send that session key, but I send it encrypted to you and I encrypt it using a master key. So that assumes that I and you have shared a master key in the past. So if somehow we've shared a master key, then we can encrypt session keys. And the concept is that we use session keys to encrypt data for some time period, for a session. And then we can change that session key after some time and change it quite easily when I say easily. I mean, the computer can do it using some protocol automatically. The human user doesn't have to be involved. So every TCP connection or every five minutes across the network they exchange a new session key safely encrypted using the master key. So the problem with that case then is, well, how do we get the master key? We either manually exchange, well, we must manually exchange the master key. If we manually exchange master keys with everyone, then there's a lot of exchanges needed. So the approach that we arrived at was using a centralized key distribution center that each user manually exchanges a master key with a KDC. And then for the two users to communicate, they go via the KDC to get a session key. So this reduces the number of manual exchanges. And we went through some operations or those five steps and how an attacker could, if they try to attack, how this protocol stops the attack. So it's all about getting a shared secret key between A and B. The other approach is to use asymmetric cryptography to encrypt the shared secret key. What's asymmetric cryptography? What's the other name? Asymmetric is public key crypto. So asymmetric in that the keys are different. We have a public and a private key. We don't have symmetry between the two user's keys. So the idea here is that I still want to get a secret from A to B. But instead of encrypting that using symmetric key crypto, we'll encrypt that using public key crypto. And we'll see some advantages of that. Some practical things comparing symmetric versus asymmetric cryptography or symmetric versus public key crypto is that public key algorithms are quite slow. RSA, Diffie-Hulman and other public key algorithms, when we encrypt a large amount of data, they are very, very slow compared to symmetric key algorithms. For example, RSA encrypting data compared to AES is maybe thousands, could be thousands of times slower to use RSA than AES. So in practice, we don't want to encrypt large amounts of data using public key cryptography. We'd like to use symmetric key cyphers. So a common application, therefore, of asymmetric encryption is to just encrypt a small amount of data, encrypt a secret key. For example, what we do is that I encrypt an AES key encrypted using RSA. I send that encrypted key to someone else, they decrypt it, and then encrypt the data using that AES key. Again, use public key cryptography to encrypt a shared secret key, and then encrypt your data using that shared secret key. And that's a very common way in which the two different types of cryptography are used. We'll go through, actually, we'll mainly go through the first two, some different protocols to achieve this and arrive at some problems with using public key cryptography. First, let's see if I can show you, and I think I've done it before, but I'll try and illustrate again the speed differences between AES and RSA. Let me bring up some instructions. What I'll do is just use OpenSSL just to show you the speed differences between RSA, for example, and AES, two common algorithms. But I need to remember the exact commands. OpenSSL is the software that provides a library of many different ciphers, and it has an option to do a speed test. So this is doing just some speed tests with AES, 128-bit key, and CBC is the mode of operation. And it does, for three seconds, encrypts different size blocks. And it gives a lot of information, maybe we'll just select one of them here. If the blocks are, say, 64 bytes, it could do this is 91,000k or 91 megabytes per second. So AES could encrypt 91 megabytes per day of data per second. So that's some indicator of the speed of when we use AES. Now I'll do a similar speed test, but with RSA. So with RSA, we have different length keys that we can have. So the private key, so it does some tests. In fact, in this case, with 10 seconds, it uses the private key for 10 seconds and records how many it can do as fast as possible. And at the end, it will report some summary statistics. It may take a little bit too long. With RSA, when you use the private key to encrypt versus using the public key to encrypt, the private key is much, much slower than using a public key. Remember the public key is usually this value of E, which can be small. Maybe three, maybe 65,000 are about that. That is, everyone may use the same. The value can be chosen to be very fast when we use it to implement. Remember with RSA, you take your message, you raise it to the power of E mod by N. If E is small, that's good. But with using D, the private key, you take the message raised to the power of D. If D is very, very large, that takes a long time to calculate. So encrypting using the private key is much, much slower than encrypting using the public key with RSA. So it runs it with both. When we encrypt with a public key, sorry, we'll go the other way. When we encrypt with a private key, we use that for signing something. I want to sign a message, I encrypt with my private key. And you verify that using my public key. So that's the using RSA or public key crypto for authentication. I want to send you a message. I want you to be sure it came from me. I will use my private key. You will verify with my public key. So the output here is saying that if you use RSA with different key lengths, say 1,024 is common, it can sign that he's used the private key. That's how long it takes for one signature operation. Or it can do 4,500 signings per second. It can verify much faster. This is using the public key. Signing uses the private key, verifying uses the public key. It's what, 4,500 to sign, 68,000 to verify. So a factor of 10, more than 10 times faster using the public key than the private key. So the first point there with RSA, using your public key is faster than using the private key. So verifying is much faster than signing. It's hard to compare with AES, but here we've got in the order of, what, 60, in the best case, 68,000 encrypt operations per second. When we used the speed test on AES, it was, for example, there in three seconds, it did 425,000. No, 4.2 million operations in three seconds, which is about 1 million operations per second. With AES, it's encrypting about 1 million times per second. With RSA, it's about 68,000 times per second in the best case. 4,000 times per second in the worst case. Now, there is some differences, but rough comparisons. AES, a million times per second. RSA ranges from 4,000 to 60,000. Just trying to show the point that AES is much, much faster than RSA. So if you want to encrypt a large amount of data, we generally use symmetric key algorithms like AES. We only use public key algorithms to encrypt small amounts of data. For example, encrypting a short key. Any questions on those concepts? So our aim is still to get a shared secret key from A to B. But we'll encrypt that shared secret key using public key crypto. And we'll look at some simple approaches for doing that and look at some limitations. The first one, very, very simple. A wants to get a shared session key with itself and B. So they both need to know KS at the end. So what they do, A has its own public key pair. It sends a message to B saying, I am A, and here's my public key. And what B does is uses A's public key, chooses a session key, KS, and encrypts that session key with the public key of A and sends that back in the response in message 2. When A receives message 2, A can decrypt because A has its private key. It was encrypted with A's public key, only A can decrypt. So no one else can intercept message 2 and see the session key because no one else has the private key of A. So here's a way to get a shared session key between A and B using public key cryptography. Very simple, just two messages exchanged. We don't need any other entities involved. There's no third party in this case. So you come to someone else, you just say, here's my public key. That other person chooses a session key and sends back the session key encrypted. And it works under some conditions. And the conditions that it works is if assuming the attacker cannot modify these messages, it may be able to read the messages, but assuming they cannot modify them, it works well. But if the attacker can act in between A and B and modify or insert new messages, then they can do what we've heard of before, a man in the middle attack. And then it doesn't work. First, can the attacker modify messages? How could you do an attack that would modify messages or under what conditions between two other users can you modify messages in practice? Let's say I have a cable going between my laptop and this PC and I'm using this protocol. So there's a cable going between them. Can you as an attacker modify the messages sent between my two computers? What would you need to do to modify those messages? Easy. Anyone have an idea? You need to somehow get access, physical access to that cable, somehow tap the line. And not just get access to it, but have some device that will create messages. So often intercepting messages is relatively easy, but modifying messages on some communication links is harder than just intercepting. So tapping a line and just recording what's sent, you just get access to the signal is possible. But what you need to do to modify the messages is to get the signal before it gets to the destination B, modify it and then send it on without B noticing. And in some communication links, that's not easy to do from an attacker's perspective. It's hard to modify messages without B knowing that someone's tapped my line. So in some cases, some networks, we can assume that an attacker will not be able to modify messages. Let's say we own the submarine cable going between two countries under the ocean. Across that link, we may assume that someone can't go under the ocean, the bottom of the ocean, and insert a device that will modify the messages being sent across that link. So we could assume that they cannot modify messages. So in some cases, the attacker can't modify. But if they can, the man in the middle attack is possible. Try it. Do a man in the middle attack so that you, as the man in the middle, the attacker finds the session key. You find the session key, and A and B don't know you have it. If A and B know that you have it, then of course they won't use it. So the attack is not successful. A successful attack here would be to an imposter, some other user, in between A and B, can learn KS and A and B don't know that. So see if you can draw the diagram that involves a man in the middle attack in this case. In fact, we've done it similar with Diffie-Hellman in the past, but I think you can do it more generally here for any public key algorithm. So the normal behaviour is A sends its public key and its identity to B. For example, where it's RSA public key and the identity, again, depends upon the system that this is used in. So we assume all entities have some unique identifier, whether it's a name, some computer-based address, but something that uniquely identifies that entity. And B, when it receives the public key of A, sends back or generates a session key. Session keys are typically just random values for symmetric key cryptography. We just use a random key. It generates that random key, but instead of sending it in the clear, which we should never do, we encrypt it using the public key of A and A decrypts that. So in the attack, if we have a man in the middle attack, A sends the normal first message, but it sends it to B, but the imposter somehow intercepts it and gets it before it gets to B. My writer is lowercase A. It sends its public key, sends it to B, but the imposter intercepts, and then the imposter modifies something, forwards it on to B. What does it do? Change the public key to what? And the ID. It doesn't change the ID. For example, if the ID is the user's name, then user... I send my public key, and my ID is my name, Stephen Gordon. The imposter receives that message, modifies the public key, but the identity, Stephen Gordon, is sent on as is to B. So B thinks this is my public key. What does a public key look like? If you remember back, when I opened SSL to generate public keys, it's just a sequence of what looks like random characters, random bits encoded in different ways. By just looking at it, there's no way for B to know that this is A's public key or A's public key. So... And that's the problem in this system, is that B receives this. Here's a message. It's from A. Here's A's public key. B doesn't know it's A's public key. It's just a public key that it's received. So, according to the protocol, B responds. Actually, B generates the session key. KS is generated, and then B responds, encrypting that with the public key of what it thinks of user A, but in fact is that of the imposter. It encrypts at thinking only the original A can decrypt, but in fact, it goes back. The imposter intercepts. They can decrypt. Because they know. We should have listed what they know. They know A, of course, has PUA and PRA. The imposter has PUI and PRI. They have their own key pair. That was generated, so the imposter can decrypt this. When they decrypt, they learn KS. What do they do next? The last message. Remember, user A is still expecting to receive a response. If it doesn't, then it will not use the session key. So, the imposter is trying to make A and B think that they've got a shared session key, but no one else knows it, but the imposter does actually know it. They encrypt that same session key with what? The original PUA. A receives this. A decrypts. It successfully decrypts. They use PRA because they expect it to be encrypted with PUA. They learn KS. A has sent the message and received the response as expected. B has received the original request and sent a response as expected. They think they have KS. They do, but the imposter also has KS. Now, how is KS used? It's used to send encrypted data between A and B. Anything sent in either direction between A and B so that KS is used now to encrypt, let's say, using AES, a different algorithm. Any data sent between A and B using that session key can be intercepted by the imposter and decrypted because they also know the session key and that's where the system fails. We've seen a man in the middle attack on Diffie Hellman on a specific case of public key cryptography. So this is in general of distributing public values. The flaw or the problem arise because when B received the public key, it has no way to know for sure if the public key inside that message is actually of the user A or it's of someone pretending to be A. And we'll see. We need some way to make sure that we know that the public key is the correct public key. We'll see that towards the end today. So this scheme doesn't work in the case that we've got someone who can intercept and modify messages. Any questions on man in the middle attack on our public key distribution? Who uses public key cryptography? Anyone here has used it? Everyone? What for? Some applications you've used it for or you may come across it again? Chat applications. How do they use public key cryptography? Maybe the one thing... Yes, many applications may use it. One thing that it's very common and widely used and we'll see it come up is in web browsing, HTTPS. You use HTTPS for secure connections between you and the browser and one part of that creating the secure connection and making sure that you are talking to the correct web server involves your browser getting the public key of the server and the concept is to use digital certificates to do that. So the web server has a certificate containing its public key and the problem with that or the problem that certificates solve is to make sure that when you receive someone's public key it is in fact their public key, not someone else's. It's the same problem that arises here. When B receives a public key in a message it must be sure it is A's public key, it's not someone else's. And that will come up a lot in... We'll see some more examples with HTTPS. So we need a way for B to verify this public key. Let's look at a different scheme. Here is again a way to distribute the goal is to get the session key KS between A and B. They both know KS but we're using public key cryptography to encrypt that. Here we of course have it encrypted and also authenticated. What happens? Initiator A sends a message to B not containing a key but containing some nonce value and its identity encrypted with B's public key. This scheme again, this assumes that A has the correct public key. When we say PUB here it is the public key of B. So we send some nonce value, let's say some random number, N1 and the identity of A to B. The meaning of this message is really to say or the purpose is to check whether who we're sending to is in fact B because if I encrypt with the public key of B who can reply or who can see the contents? If I encrypt with the public key of B the only person who can see the contents of that message is B because only B has the private key. So what I do is I send this random value N1 and my identity to B. The B decrypts it, they know the private key and they send back that random value N1 in a response encrypted with a public key of A. The idea of sending back N1 is for B to prove to A that I am B because the only person who knows N1 is the person who has the correct private key to decrypt the first message. So what happens when B receives this? It learns N1 and sends N1 back in the response with the idea to prove to A that I am B but in addition B wants to check that the other endpoint is A. So what it does is it chooses another random number N2 and encrypts it with the public key of A if it's encrypted with a public key of A only user A can decrypt. So the response from A, when it receives message 2, it decrypts. It sees N1 is included. This confirms to A that B must have sent it. If it contains N1, the only other person who knows N1 is the person who can decrypt the first message. Who can decrypt the first message? B. So B learns N1 and sends N1 back in the response. So this is some method for proving that you are the endpoint that A expects it's communicating with. Authentication. And same with the third message. B chose some random N2 encrypted it using the public key of A the only person who can decrypt it is A. Therefore the only person who can learn N2 is A and for this entity to prove that it is A it sends that value of N2 back to B. If this entity was not A if it was somebody intercepting the second message it would not be able to learn N2 and it would not be able to send back message 3. So these 3 messages are for both sides to confirm the identity of each other to make sure who they are communicating with is the right person. The last message is containing the actual session key so A generates a session key it signs the session key so it encrypts with its private key and then encrypts with B's public key so here's two operations of public key cryptography where we use the private key to sign to confirm it came from A and the public key for confidentiality so that no one else can decrypt. Let's look at a couple of attacks on that and see how this mechanism works. There's our original scheme let's see what an imposter or someone in the middle can try and do and see why it won't work. So we'll draw it again and assume that there's someone intercepting. Let's say A sends the first message it's intercepted what can the imposter do? Can they see the contents? No it's encrypted with the PUB so they cannot see the contents so they cannot learn N1 they can guess IDA they know it came from A so the identity is going to be that of A but they cannot learn N1 the number chosen by A we cannot guess it because if the random number is long enough it would take too many guesses so what can they try and do? If they cannot see the contents well maybe they could try and send a different message to B without learning the contents try and send a similar message to B to try and fool B and to think it's communicating with A what could it try? It could say IDA we know we're pretending to be A so I'll say my identity is A I'll choose some nonce value and I'll denote it as N3 it will not be N1 because I don't know what N1 was if I choose some random number it will not be the same as this so I'll denote it as N3 and we can encrypt with PUB that's okay so what we do is we know the identity of A we're trying to pretend to be them we choose some random number N3 and encrypt it with PUB what happens next? what does B do in response? B in the normal case decrypts yes it can decrypt it has PRB it learns N3 and IDA so what's the response that sends back? it thinks this was from A so it will encrypt with PUB of A and it will include the nonce value it received N3 the one it received in here to confirm and it will choose its own nonce value N2 in this case so B has received a message it thinks it's from A here's the nonce value N3 so what I'll do is I'll see from A let's encrypt with the PUB and send it back and let's include my own nonce value N2 just to check the other side can the imposter decrypt? hands up for yes good everyone's correct it's encrypted with the PUB therefore the imposter cannot decrypt they cannot see N2 they know it's N3 in there they created N3 they know N2 in the same way as in the first message the imposter had no way to learn N1 but they want to make A receive the expected message A sent the first message they expect to receive the second one back so what can the imposter do? they need to send a message to A so that A believes everything's working okay A expects to receive something encrypted with a PUB so yes the imposter knows the public key of A what do they encrypt? any suggestions? let's look at what A is expecting A is expecting the original nonce value it sent N1 combined with a new nonce value N2 I doesn't know the new nonce value but it can make one up so it doesn't know N2 but not as A but the problem with the imposter here is that what does it include here? it should include N1 A is expecting N1 to come back it sent N1 in the original message it must come back but I doesn't know N1 because it couldn't decrypt the first message so whatever comes back here I'll say N5 well maybe it's N3 N1 and as a result A will detect the message I got in response it successfully decrypts but it doesn't contain N1 something's gone wrong so this is one example of why we use these nonce values encrypted because if someone tries to modify things and pretend to be one of the other entities and verify that someone's performing an attack questions any other suggestions I knows the public key of B but it cannot decrypt something that was encrypted with the public key of B so the first message was encrypted with the public key of B the only person who can decrypt has the private key of B so yes that's N1 knows PUB so in fact they can send a message here they can encrypt with PUB but they cannot decrypt this because they don't have PRB if I cannot decrypt this first message they will not learn N1 and the protocol requires N1 to come back if A doesn't receive N1 back it knows something's gone wrong and the only person who can learn N1 is the person who has PRB which is B and it's similar with the other that third message is doing the same thing from the opposite endpoint that is N2 is sent encrypted with PUA the only person who can learn that is A so the only person who can reply with N2 is A so if B receives a reply with N2 it knows that it got that reply from A not from someone pretending to be A because if someone was pretending to be A they wouldn't be able to learn N2 so these three messages perform some verification of the endpoints once we know who we're talking to B knows it's communicating with A A knows it's communicating with B the last thing is to exchange the session key A generates KS it encrypts with A's private key and then encrypts with B's public key why does it do that B wants to be sure that this came from A an attack, a potential attack on that even if the first three messages were correct so let's consider a different scheme if it was A the first three messages are the same let's to verify the endpoints and the last message was not signed what if it was a different protocol where the last message was just KS chosen by A encrypted with PUB how would an attacker take advantage of that scheme so let's say we used a different protocol what can an attacker do first three messages are exchanged the attacker couldn't do anything there because of the nonce values then the fourth message is sent from A to B containing the actual session key can the imposter see the session key they cannot decrypt but they could send a different message some other key KX that is they cannot see KS the actual session key there is send on a message to B and when B receives that B thinks it has the session key and that may be useful if it can now B thinks that the session key is X KX so we should sign that message and that's what the last the fourth message actually does it doesn't just encrypt it with the public key of B so that the attacker cannot do such an attack of just modifying that message this fourth message B checks it came from A using PUA to decrypt this part and it confirms it's confidential by using PRB to encrypt the outer part so a more complex way to exchange the session keys in public key cryptography still it's there's no third party involved it's only between the entities that are communicating you can extend it for lecture slides there are ways to extend it to incorporate a third party like the KDC, the key distribution centre so have a combination of public key distribution and KDC with master keys back to one problem which is present here but especially in the men in the middle attack, this problem of if you get a public key how do you sure that it is that person's public key if I I post my public key on my website and I say download it and encrypt messages and send them to me using my public key how do you know it's my public key it's not someone who's maybe compromise my website and put their public key there saying it's mine how do we be sure any suggestions someone gives you a public key how can you be sure it's theirs what can you do can you be sure not if it's just those two involved then we need some normally we need some other entity to confirm or to verify it's theirs so accepting the public key have that public key some other entity confirms yes that is Steve's public key if you trust that other entity then that scheme would work so the approach is if I give you a public key you don't just accept it you check and you confirm if someone else believes it's my public key and if you trust that someone else then it implies that you can trust that it's my public key so we get actually another entity to sign my public key saying yes this is Steve's public key I confirm it and we build up this what we call a chain of trust that we can build up and say okay if I trust this person and they confirm it's Steve's public key then I trust that it's Steve's public key and we'll see that that's commonly used when we use public keys in internet based systems and in particular in secure web browsing and digital certificates so the issues of distributing public keys how do you know that the public key that you've just got is of the correct person how do we distribute public keys now we say public keys are public but making sure it belongs to the correct person is a challenging problem and there are four approaches or we'll list four approaches arriving at a commonly used one public key certificates public announcement is easy you post your public key in some public forum on a website in a newspaper you print it and stick it on your door you attach it in the bottom of your email so that's what we mean by public announcement a publicly available directory is similar but it's done using a computer so when we say a directory here some server keeps track of the public key so I somehow publish to the server and distribute through there and the last two the public key authority and certificates use some automatic way and some central party to exchange public keys so public announcements so you just tell everyone here's my public key now the problem is it's hard to prevent someone pretending to be someone else okay we could do it in this class and one way it's done in some some systems is that okay we're here we all have our public keys alright and I read out this is Steve's public key and you record and take down or with a computer I copy the file to you so I can announce it to everyone and then you know it's it is my public key because it's me saying it I wouldn't say this is someone else's public key so you associate that with me you know it's me you trust me okay and I could do the same you could announce your public keys to me so in a local forum we could do that if we have some other way to verify who is doing that announcing because we used to have some other form of trust but in a large system that's not possible if you see a public key attached at the bottom of an email or on a website someone may have compromised that website or modified that email as it was sent across the internet to modify the public key a publicly available directory is a similar concept but usually we think it's done in a computer based system where each user publishes a public key to a server a directory so maybe there's some protocol or some website that stores public keys and you go there and you enter your public key and it's saved in that website and when anyone wants your public key they go to the directory and download it so A puts its public key in the directory B puts its in the directory when B wants to know A's public key it goes to the directory it goes to the public key so there are ways to do that of course we still have this problem when A uploads its public key how does B know it was A that uploaded that it's not someone else and impostor that uploads it so we haven't solved that problem to solve that problem we'll introduce another entity what we'll call a trusted third party someone that we trust that we use them to verify that it is the correct public key here's one approach for doing that using what's called a public key authority before these exchange of what seven messages takes place there are some assumptions about what's known and we'll draw that what is known before any messages take place we'll list it on the on the different nodes everyone has their own key pair so we can write that A has P U A P R A B has its key pair and the authority has its own key pair P U authority in addition we assume that the two entities involved here A and B the two users also know the public key of the authority so when we say that they know the public key then somehow they know they've learnt the public key and they are sure that it is the public key of the authority remember that's the problem that we have when we get a public key how do we be sure that it is well one way would be to have some manual exchange in the past A has gone to the authority and confirmed face to face that they are the correct people and got the public key of the authority very inconvenient but if we only need to do it with one entity it's possible similar in the past B has gone to the authority and confirmed face to face and got the public key of the authority so we assume that they know the authorities public key and they know for sure it's the correct one it's not someone pretending to be the authority what else when we learnt the authorities public key the authority learnt the public key of A and B so that happens before this exchange an example I'm the authority all the students are the users in the system and the task is you need to come to my office show me your ID I will show you my ID confirm we are the people who we're saying we are the public keys I as the authority will give you my public key so you know my public key and you will give me your public key so that would be some manual exchange where we confirm via outside mechanisms that we trust it's the correct entity so let's assume we've done that then the challenge then is to get the public key of A B and similar from B to A and for them to be sure they've got the right public key that it's not someone in the middle pretending to be A or B that's what this protocol is for distributing public keys let's look at the the messages the first one step one A sends a message to the A communications with B so it sends a request and it's not specified here but the request would say who they want to communicate with it would include for example I am A and I want to communicate with B so the requests may include the identities of those users of a particular format saying I am A and I want to talk to B and B is a time stamp so T1 is at this time and we'll use time stamps in a similar way to nonce values so to indicate whether we have replays because if there's a later such message with the same time stamp then the authority will be able to detect it's a replay of the original one so a time stamp can be used you check the time stamp in the message to receive time and if they are too far away you treat this as a delayed or replay packet and ignore it so the authority sends back B's public key the actual request so the same request information and the same time stamp but signs it with their own private key so here we encrypt with the private key of the authority which is called a signature we sign we use this it verifies that it is the correct public key because it uses the public key of the authority to verify A trusts the authority because it knows the public key of the authority so anything signed by the authority it also trusts so the public key of B of importance inside here is what A learns when it receives message too because it is the public key of B because the only person who could have signed it is the authority and we trust the authority no one else can sign this message that we already trust so when we say trust from now on with public key crypto think about we know the public key of the person who's signing so upon reception of message too A learns PUB and it knows for sure it is PUB because it came from the authority and it knows for sure it came from the authority because it was signed with the authority's private key and it verifies that using the public key of the authority up until now B has done nothing B doesn't know A wants to talk to it the third message is that we send my identity I am A here's a nonce value and these nonce values are used in the same as the previous scheme to confirm we are talking to the right end point encrypted with PUB when B receives message 3 it requests the public key of A from the authority so message 4 and message 1 the same meaning request a public key of the person you want to communicate with B sends the requested authority the authority sends back the public key of A signed by the authority therefore B verifies and receives the public key of A and hence it can send message 6 N1 that received in the first message a new nonce N2 encrypted with the public key of A and A can confirm sending N2 back encrypted with the public key of B to confirm between A and B they are talking to the right end points note that these three messages 3, 6 and 7 are the same as what we saw in message 2, 3 and 4 here sorry 1, 2 and 3 the same purpose here we want to be sure we are talking to the right end point in this scheme we assumed at the start that A had B's public key and B had A's public key now we are introducing a scheme where we learn B's public key by getting it from the authority assuming we trust the authority we trust that we have got the correct public key of B and similar for B learns A's public key once they have each other's public key then they can exchange if they want a session key as we saw the fourth message in the previous scheme we could send the encrypted session key back so this was a way to get each other's public key then how we use it is up to the two entities an important point is that it all relies on trusting the public key authority if we don't trust it then this scheme will not work or if we get the public key of someone else and we think it's the authority then the attack can take place but if we have the correct public key of the authority then the scheme works what if an attacker replays message one what happens say these messages were sent today and then tomorrow someone who intercepted all the messages sends message one again to the authority what will the authority do sends the exact same message with the problem there that is it will recognise so the time stamp here is to recognise this is a replay message or a delayed message so that's one role of the time stamp there to recognise repeats can someone send the wrong or a fake public key for B in response that is A sends the request to the authority the authority sends message two back but an imposter intercepts that what can they do can the imposter intercept and modify message two if the imposter tried to modify message two in the response they receive message two and send a modified message to A what can they do can they decrypt message two yes they can decrypt message two they have the public key of the authority so they know PUB they know the request in T1 so they can modify if they then want to send a message encrypted with maybe PUI what do they encrypt with PR of someone not the authority so A will learn that this has been modified because when they receive this message here they decrypt with PU of the authority if it wasn't encrypted with a private key of the authority it would not successfully decrypt and A will know that so the imposter here cannot modify this content without it being detected by A and that's the role of a signature no one else can sign it except the authority and it's similar in four and five and three, six and seven are that confirmation that A is talking to the right endpoint the same as we saw in the previous protocol so here's a way to distribute public keys what's the problem with it to finish today security okay what's the problem speed in what way let's say we have a thousand users so every time one pair of users wants to communicate they go through these steps send a request to the authority authority responds message three the other endpoint sends a request to the authority authority responds and then they finish then another pair of users do it and so on then there can be a performance problem we rely on that authority that is let's say it has to happen thousands of times per second then the authority this server must handle these requests very very quickly if the authority fails or is down for a short time then they cannot proceed they cannot communicate so a performance problem is that every time two users want to communicate they need to go via the authority so next week we'll lead to one that overcomes that performance problem very similar but doesn't require all communication to the authority and that is digital certificates and we'll see examples of certificates in secure web browsing, HTTPS