 Thank you. So this is joint work with the Caterilkas, Hockon and Tibor and we're going to talk about a highly efficient key exchange protocol that we've looked at and We're also going to say something about tightness and efficiency So the current situation when you look at key exchange protocols and indeed many other protocols is That we have security proofs for a lot of these but the proofs are not tight In the sense that if you were to deploy them with what we'd call theoretically sound security parameters You would get a very slow scheme so people don't do that instead. They deploy with what seems like convenient parameters In fact that are treating the security proof as a heuristic not as a proof So what We have also is schemes that have what's known as tight security You can deploy them with the key sizes we use today and you get the proper security guarantee But as we saw with yes, then Yager last year at crypto Such games tend to be a bit inefficient. They are slower quite a bit slower than what you'd like to have even though if you Deploy with theoretically sound parameters. They're still faster than the alternatives so the question that we started looking at is Can we get more efficient scheme using theoretically sound parameters? Okay, so the thing we're talking about is implicitly authenticated key exchange Alice and Bob they want to exchange a key But in this model, we don't really we want don't want to limit us to just two people. We want lots of people So we have lots of people who want to exchange keys They can do many key exchanges between many different people We are going to say that the adversary is the one that schedules all these key exchanges that gives him more power Which is good because if we can prove security against more powerful adversaries. We have more security the adversary he can do a key reveal which is Simply learning some previous session key He can also do a test where he gets the real or the random key This is what he's supposed to Decide did I now see a random string or did I see the key? They actually agreed on in our model the one we prove The adversary is allowed to do many test queries Why do we do that first of all because we can and second because that's very convenient when you're going to use your key Exchange as a sub protocol in some other protocol you're analyzing then it's very convenient to have lots of test queries The adversary of course controls the network and the adversary can adaptively corrupt users So this is our adversary model And our goal for security and this is implicitly authenticated key exchange. So If Alice somehow believes she has an exchange to key with Bob, then Bob is the only one who could possibly know that key If he participated if Bob didn't participate in the key exchange, then there's no one but Alice that knows the key And moreover, there's only one instance of Bob that has this key and this is sufficient that The implicit authentication says that when you start using this key if you can use it successfully the authentication is there And of course to get implicit authentication this key has to look random to everyone who was not supposed to learn the key Right Now security proofs. Why do we have security proofs? Well, the traditional form where you have a polynomial time adversary gives a polynomial time solver blah blah blah This ensures that your system is not let's call it structurally breakable There's no easy way to break your system that avoids the hard problem underlying it But still I mean it doesn't really help you with the one Interesting problem. Namely, what should I use as a security parameter? So we have concrete security where you say, okay adversary with time t1 blah blah blah blah blah blah This does allow us to say something about which security parameter should we use Unfortunately a lot of our like I said a lot of our schemes aren't really tight So t2 tends to be a lot bigger than t1 and If you want t2 Sorry, yeah Lot smaller, I should say Then t1 and if you want a really big t1 Big t2 then you need a huge t1 and you have to choose. Yeah, okay. I'm probably messing this up. But anyway So what we want One approach to do this is what we call tight security where t1 and t2 are essentially the same Because then you don't have these problems But this tends to result in slow schemes. So our approach in this Paper is to make a trade-off So we're going to do two trade-offs. We're going to trade off a bit of efficiency Compared to the fastest and when we're talking efficiency. We're talking number of explanations and we're going to trade off a little bit of tightness and the result is a Hugely more efficient protocol when you instantiate it with theoretically sound parameters Let me just before I start going on to end the analysis of our main protocol Say a few things about the other results in our paper a few other results So this tightness loss that we are giving ourselves This is for a large class of key exchange protocols optimal you cannot get away from having this tightness loss and We have a really nice proof Using meta reduction techniques, which I'm not going to talk about you'll have to read the paper We also our main protocol is going to depend on strong Diffie-Hellman This is an interactive assumption. Some people don't like those for those people We also have a few other variants that depend on just plain ordinary computational Diffie-Hellman or plain ordinary decision Diffie-Hellman and then we use twinning techniques and possibly in combination with the commitment trick from a yes and the other last year The cost then of course is that you get more Exponentations twinning basically doubles a number of exponentiation at some point So these have weaker underlying assumptions, but they have more costs. So they're not as efficient. They're still reasonably nice compared to other Protocols so they're still good just not as good as our main protocol And then of course you can debate how does strong Diffie-Hellman with a faster protocol compare against a Slightly more expensive protocol shouldn't you really increase your security parameters if you're using strong Diffie-Hellman instead of computational Diffie-Hellman. There's some things that you can debate there Which we haven't really looked at yet, but it's an interesting thing people who do algorithms might want to look at this So let's start with our protocol and this is really an old idea. This is not a protocol. This is plain Diffie-Hellman So we all know this and we all love it And you'll see this is not post-quantum at all There are lots of variations if you add some public keys with Diffie-Hellman you can do this static ephemeral trick Where you take one public key you combine it with the other guys ephemeral key and Wise-Werzer and then you hash it all up and now you have a nice key exchange protocol This is I believe key A or something But obviously you don't have to stick with static ephemeral you can also put a static static Sorry ephemeral ephemeral term in there You can put some names in there You can put some public keys in there and one of the tricks that really make the security proof go through is this We put the actual messages of the protocol in there That's good crypto hygiene You really want to do this to make sure that no one confuses anything and you're not doing something silly But it also helps our security proof go through without these two terms inside the hash We couldn't get the security proof to go through we'd get a quadratic term So our explain our runtime would be would blow up unfortunate. So this is actually a Kind of a tricky thing But these things are really important inside there. They're not just there for crypto hygiene Okay, so our proof the first thing we do in our proof is that we say well We're going to be a bit lazy with our random oracles We're just not going to bother evaluating them So what we do is when the key exchange protocol finishes and it needs to determine its key we just choose a random key and We don't bother querying the hash oracle and When Someone queries the hash oracle at the appropriate point at a later time then we just reprogram the hash oracle So that the adversary sees something that's consistent This is a perfectly standard thing that we do all the time and The idea then our strategy for doing the proof is that we stop this reprogramming Because then once you've stopped all the reprogramming from happening what happens then is that the adversary He can query the oracle, but the oracle has been disconnected from the keys We actually choose when we stopped reprogramming which means the keys No longer come from the oracle just just random strings. So in our final game the adversary if he gets the real keys he gets a bunch of random strings that are have no relation to anything or He gets a bunch of random strings that are not related to anything which means trivially. He doesn't have any advantage That's our strategy. There are some obstacles. We have to be really careful about making a consistent experience for the adversary so that when he Corrupts too much. He will be able to recover the keys He will be able to query the hash oracle at the right place and then he must get the correct hash value Which is the key that we agreed on a bit earlier? So we have to be a bit careful there And that's where we need the strong development We need to recognize when the adversary is querying the hash oracle at the right place And then we get a really nice theorem the tightness loss is linear in the number of users And as I said, this is for this class of protocols For a large class of protocols This tightness loss is optimal Right, so in the security proof, I'm going to very quickly run through a few of the cases You can see that Either you have an initiator there are two in a key in a standard key exchange protocols. There are two Parties there's the initiator and there's the responder and Then for an implicitly authenticated protocol. There are really four cases the initiator He might either have a partner Or he might not have a partner, which means that the response that this oracle gets came from the adversary Well, the adversary might have but it doesn't come from an oracle that matches art that has a matching conversation with us And this is where the obstacle happens because this Person could become corrupted later, which means the adversary learns its long-term key Which means it might actually pair off with this Guy that turns the session non-fresh. So that's okay But it's still a thing that we really have to take care not to mess up Responder oracles they of course can have or not have a partner The nice thing about the responder oracles is that when they receive their first message We know if they're going to have a part or if they go if they can have a partner or not With the initiator oracles we start by sending out a message and we have no idea whether we're going to end up with an initiator oracle that has a partner or that hasn't got a partner and That Simplifies quite a lot of stuff Dealing with the initiator oracles that have a partner which we know at the time they're going to decide their key That's very easy Because now you know you have a matching conversation So you just forget about all those key computation and you just steal the key from your partner oracle So then we get rid of them. There's no more detail to these kinds of initiator oracles anymore They take care of themselves The initiator then we deal with responder oracles Responder oracles that we know will not have a partner and how do we do? This and it's at this point tightness loss happens because we need to guess a public key where we can put the Strong diffie helmet instance in So we guess one partner not the person that we're going to deal with the oracle But the person that oracle is talking to So we guess that guys with what so that means we have one key this key. We cannot reveal. We do not know the key Instead We're going to have to use This strong diffie helmet oracle that we have to recognize when the adversary could have done something bad and If you look really carefully at this query, you'll realize that we don't know all the terms there But this is actually an interesting thing about our proof the adversary To be able to get this query right He has to guess all of the three terms both the ephemeral static the static ephemeral and the ephemeral ephemeral While we in our reduction in order to win We only need to get one of them right and that's the one we can recognize with our static diffie helmet key Okay, and then when we do this We have to be a bit careful with the others. So we have to set up all of the recognizing of everyone else's Oracle, but then typically we have more information for the other guys So we get this to work When we do responder oracles that have a partner then we can use plain old decision diffie helmet We don't need this recognizing thing because what we know is that if we use decision diffie helmet in this case We just put the decision diffie helmet real a random term into the hash oracle And we know that if this is a random term the adversary is never going to query that your hash oracle at that point Which means if we ever see him querying anything at that point. Well, then we know that This is the real thing So this is quite simple And again, we can recognize when we win and the same thing for initiator oracles We can deal with all of the corner cases and and Essentially, that's the way the proof goes. There's some few technicalities. You have to take care that Nonses are not repeated and stuff in order to simplify everything But you end up with this nice result the loss in tightness is linear in In practice, we end up that the adversaries key exchange advantage is bounded by and the number of users times the strong oracle advantage of two different adversaries and the decision diffie helmet advantage of one adversary so now Let's see how we end up with a really efficient scheme here. So we decided to Do a small comparison with HMQV. There are lots of security proofs for HMQV And they have different tightness and it also depends a bit on which assumption you use. So we said HMQV is Has a quadratic tightness loss in the number of users and the number of sessions That's sort of the best we could find Our protocol has a tightness loss. That's linear in the number of users. So let's see what the effect is We have two small a small scale and a large scale Situation large scale Facebook small scale any other reasonably big thing and When you go for a 112-bit security level We end up with NIST 256 bit curve is suitable for our protocol in the small scale in the large scale We have to have the 384 bit curve What do you see here is that If you do the tightness loss computation 384 is a bit too big Could have done it with a smaller one, but This is the only one that's deployed if you were going to deploy this with today Immediately you'd have to choose one of these standard curves and they are not available in every bit size you can imagine So that's why we have a small loss. So this is not a perfect scaling But I think HMQV it's Reasonable It's not too bad over And Then we took some timings from open SSL running on one of our computers and you see our protocol is simply a lot faster when you instantiate it with Theoretically the sound parameters Now, of course if you just do what everyone does today and instantiate it with p256 everything HMQV is faster than our protocol, but not by a huge amount Because our protocol requires for Explanations HMQV requires say two and a half So it's not It's not like our protocol is completely out there. It is actually very efficient So to summarize There are really highly efficient protocols that can be instantiated with theoretically sound parameters namely our protocol with Theoretically sound parameters, we're the best with if you don't care about theoretically sound. We're still good If you look at things like the noise framework You find essentially the same thing as our protocol inside there Except our protocol has a nice analysis now and also we've shown that our results with respect to tightness loss Is essentially optimal Questions. Thank you. So we'll have some time for questions. If you have questions, please come up to the front microphone So that everyone can hear you You That's a good question I agree my interpretation is that the random oracle heuristic says that Your adversary is not going to care about the hash oracle The hash function he's not going that's not where he's going to mess with your key exchange protocol So at some point the adversary that you have He's going to put some value into the hash oracle and he's going to sorry into the hash function He's going to simply evaluate the hash function and what we're doing is base What our adversary the adversaries that we construct are basically doing they are basically Just looking at what the adversaries putting inside the hash or the hash function He's just they're just observing this reprogramming isn't That essential that's just used for the there's an artifact of the proof but they're looking there and I believe that it's a reasonably good heuristic that's If you take a real adversary against a key exchange protocol, it's going to behave like that So that means that this adversary is going to do something That you can observe if you mess a bit mess about a bit inside him And then you should be able to get a real adversary against underlying strong defilement That's my feeling But of course, this is heuristic. This is a bit vague But that's that's my interpretation of this No further questions, let's thank Christian again