 I'm going to then talk about the interactive case. So here we are. The answer is coming and Something is known about the interactive case. Let me just very quickly Repeat this so Where we almost all start our teaching of the crypto course is Alice and Bob. They want to exchange a key What we often don't say in the basic crypto course is that it's not just Alice and Bob out there There are lots of people out there. So And and this is a problem because we have lots of serious security proofs that work very well for two people But when you mix in lots of people, we get lots of trouble as we shall see Let's just remind ourselves what are the properties of key exchange. What does the what is the adversary allowed to do? So the adversary first of all he directs everyone because we're trying to give the adversary as much power as possible and To get as much power as possible Well We have to allow him to do everything that could conceivably give him an advantage without making his work too easy Without these trivial queries that we talked about in the previous session So he directs every honest user He can inspect keys and then he gets the real key or he can test keys and this is the real a random query That's where he earns his money. So to speak He controls network, of course, and he can also adaptively corrupt users and this is What really causes trouble for us? Also, we'll just remind ourselves what our goal is well we want authenticated key exchange And I've tried to render it into English and some of you can probably find some corner cases where this is wrong never mind Once we have a security notion what we next want is a security proof We want to prove that our scheme is secure and this usually takes the form of a reduction Why do we want security proofs and there are well we had this slide in the previous talk to The first mathematical answer is why not it's interesting the second and Some people actually use this as an argument if we have a security proof We know that the adversary in some sense has to tangle with the mathematical problems underlying our key exchange So we haven't really messed up Okay, and the third reason you might want to give is that the security proof is going to help us choose security parameters Because we know that and then This just saying that we have a polynomial time blah blah blah it doesn't really help us We need to be a bit more concrete So we get this if you have an attacker with advantage t. Sorry it using time t with advantage epsilon blah blah and This we can then use to decide security parameters and Then as the previous talk mentioned if we can have a tight reduction a tight reduction is one where We don't get a loss of advantage or an increase in time by running the reduction Then we can probably have smaller keys and that might result in effect more effective systems if you actually believe in this Provable security and want to use it to choose security parameters. Of course today. No one does so But anyway Let's just yet again remind ourselves. What is Diffie helman? Why do we care about Diffie helman? Well, because we're going to make Diffie helman better You thought that wasn't possible, but just wait so we all know Diffie helman and In a very simplified case we can say that the adversary He's going to promise not to tamper with any messages And he's also telling us in advance which users he has corrupted and then we can do a very nice reduction from To prove that this Diffie helman key exchange is actually secure so what we do is if Carol which were what which Alice wants to talk to is corrupt Then you just run the Diffie helman key exchange as usual why well because you have no expectations of privacy for this key Because Carol you're the one you're talking to is corrupt. So who cares? However, if you're talking to an honest Bob Then you just pick out the Diffie helman tuple You use the X and the Y as your messages back and forth and then you use the third or the fourth element of the Diffie helman tuple as your key and as Lisa just explained Diffie helman says the real Diffie helman tuple is indistinguishable from a random tuple. So you can't tell the real key from a Random key and this well, then we have security And all is very nice and we also have these other beautiful property of Diffie helman Tuples they're Rerandomizable so if I have one tuple I can very easily create a huge amount of them and what happens then well for every Conversation between two honest people I can just pick out a new random tuple from my Rerandomizations and I get lots of keys that are all either real or all either random And this is very nice. We get a tight security proof. Of course We haven't allowed adaptive corruptions. We haven't allowed the adversary to mess with the messages. So this is too easy What happens and now we're going to the adversary still promises not to tamper with messages But now he's allowed to adaptively corrupt that means he doesn't have to tell us in advance who he's going to corrupt So now the adversary tells care tells Alice. I want you to talk to Carol and he hasn't yet corrupted Carol So now our reduction, which is us trying to trick the adversary into solving Diffie helman for us or some other interesting thing We have to decide on a message to Carol We have to decide first the adversary who can do adaptive corruption. He gets to decide later Whether or not to corrupt Carol Which means we have to commit to something Before the adversary choose makes his choice. We have a commitment problem And this one might ask Why is this a problem? Well Because we have to commit first We can't shoot. We can't use the strategy. We just used Because that strategy Depended on if Carol was dishonest we chose our message as G to some exponent If Bob was honest, we chose our message as something coming from a Diffie helman tuple Now when we don't know if Carol is going to be honest or dishonest by the time she gets this message Well, I can choose something from a Diffie helman tuple But if Carol then turns out to be corrupted, I can't find the key. So I don't know what the key is And that's a problem and the same way if I say, oh, he's bound to corrupt Carol because that always happens What if he doesn't well then I've chosen G to the a and then I have no reasonable expectation that my key is going to be random looking So this is the commitment problem. We have to commit before the adversary Has to commit to corrupting Now the standard strategy when you want to do a proof like this This is simply guess like the last talk mentioned You simply guess a pair and you put your Diffie helman tuple into that pair and if it goes wrong Well, then it goes wrong, but with a certain non negligible probability It goes right, but we don't get a tight proof. We get this loss of n square and That's bad So we want to do something really simple and This is really simple. This is what we do. What we do is we just hash the first message And then we don't send the first message we send the hash and then the hash goes to Carol who then replies And only when Carol has replied Do we send the real message the point is that we only send the real message Once we know whether or not the one who replied is honest or not and in the random oracle model This means we don't have to commit Because in the random oracle model we can reprogram our hash So we don't have to choose to message we just have to choose the hash value and Once we know what we want the hash value To be then we can just reprogram the hash oracle and In this way we get a beautiful tight little reduction and that's kind of nice of course Some of you will then complain now we have a different protocol. It's not as nice as Diffie Hellman because really Bob here who now gets the message he gets a hash and In the ordinary Diffie Hellman once he gets that hash He how once he gets the first message he also gets the key, but in our protocol He doesn't get the key He has to first send his message back and then he has to wait until the message from Alice arrives and Only then is he able to compute his key. So there is an increased latency for Bob There is also a bit of extra Things you have to transfer back and forth But remember this is often not a problem because Frankly, you're often transferring some something like signatures and stuff. So Very often Diffie Hellman ends up being a three-move protocol. Anyway The thing is and this is kind of nice if you actually look at what's the likely result of using Diffie Hellman if you use a small-scale system and likely you're likely to actually bump your Curve that you're going to use for Diffie Hellman Opposize and if you use a really large system, you might have to bump it up really large to get the same security level and then Our nice little forget the sign thing that's a bug in the slides Our nice little hash Yes, it does cost us some things, but it gives us really better performance And this is where tight Security proofs might actually do some good Okay, you might quibble with the choice of curves blah blah blah, but the idea is essentially correct But obviously I was still working in a model where the adversary had promised me not to tamper with his message with my messages And that's not actually a realistic so If he doesn't keep that promise my protocol obviously fails It falls to exactly the same man in the middle attack as as ordinary Diffie Elman. So we're We're nowhere The natural answer is to use sign Diffie Elman The problem we now run into is Of course that if we just throw any old signature scheme at this protocol We no longer have a tight security proof Because any old signature scheme doesn't have a tight security proof What do I mean by tight security proof for signature schemes? well, first of all for ordinary signatures The signature game that we're all used to that we learn in basic cryptography well It only considers a single key and To see why we get Non-tight if we want to consider many keys consider for instance RSA signatures well Every one of the users are going to have their own RSA modulus. That's kind of how our RSA signatures work And which one are you going to get the adversary to factor? Well, you get at least a 1 over n and in this interactive key exchange where we actually have to guess both parties Who might be corrupted we get n-square security laws? When we have to move to a situation where not only do we have many keys, but we also have adaptive corruptions so We're going to have to do something with signatures as well and that is Believe it or not substantially more complicated because of all of these Obstacles right. I'm just redoing the arguments that we've all heard in the previous talk. So This is all straightforward All the obstacles Here is the idea. This is an idea that appeared at TCC 15 The idea is to use a double signature thing and it you've kind of already heard the idea So what we want is for every user to have two public keys One of them is his real key. That's the one he's going to actually use to sign and the other is a fake key And whenever he wants to sign something He's going to sign it with the real key and he's going to fake a signature for the fake key The idea in this is that the real signatures and the fake signatures and the real public key and the fake public key They are going to be indistinguishable So since the adversary can't tell them apart When the adversary says I'd like to get your secret key. We're going to give him the real key We can do that because we have the real key of the real key That's very easy and he doesn't really expect there to be a key for the fake one. So who cares? So he gets what he wants but We're going to put our difficult hard problem into the fake keys Because the real key and the fake key are indistinguishable when the adversary makes his forgery that's going to allow us to do an extraction He can't tell the real key and the fake key apart. He can't tell which is which Which means That when he creates his forgery, it's going to be a forgery for the fake key with probability one-half Which means that every other time he's going to produce a forgery for the fake key allowing us to do our extraction so this is the existing idea and it was used before in a rather really nice Scheme that had lots of pairings and lots of whatever and it's completely impractical So what we did was Let's forget about this pairing and so all the nice stuff. Let's just throw some random oracles at this and see if it sticks So we did and we threw it at lots of different signature schemes and it didn't work because we need most of these signature schemes that you start with which are Tight with respect to lots of keys just not adaptive corruptions they use Indistinguishable keys and then you distinguish keys instead of Extracting something we need to be able to extract something because it's not somehow. It doesn't work with this is a indistinguishable keys so We need to find a real system and then we found a system and this is Somehow embarrassing I use this system It's it's I think it's a real old system and I use it kind of to motivate The development of zero knowledge proofs in my crypto course and I say this is completely useless, of course It's an old system. It's when you want to do discrete log-based Signatures in exactly the same way you do RSA signatures You want to take the hash of a message you raise it to your secret and then some in RSA I mean You have the public exponents everyone can check if you did did this raising correctly But in discrete logs, no one can do it So somehow we need to get some way to check that this raising to my secret key was done correctly And the way we do this of course is with a non interactive zero knowledge proof So we just prove that these two discrete logs are equivalent are the same So this is a proof. I stood in my crypto course and I said that this is a useless course and System and then a few weeks later. We suddenly realized this is what we need This is always happens whenever you say something is useless in mathematics. It shows up somewhere being useful so and this scheme what we do here and this is actually I'm skipping a lot of details in this Presentation, but the idea here is really simple What we do is we just Combine two signatures and these are just The signatures are just the hash raised to some power And then there is an Equality of D log proof and we just combine those proofs using the standard or proof techniques that were developed in 1990s These really old techniques that still work really well. So whenever you want to do this you You Raise the real thing real the hash into your real key and then you just choose a random element for the fake signature and then you fake an Equality of D log proof for the fake signature and Then you hash and do your if you achieve here and blah blah blah And then you connect this and then you do the real proof for the real signature keys Where you know the discrete logs are equal and you can do this equality proof And of course there are some details that you need to get right here But this is essentially the idea throw random oracles at it and it works. We get a proof with tight security Of course This scheme Well, we can't prove We can't give a tight proof that we have strongly unforeachable signatures So when we get Existentially unforeachable and this gives us problems when you go back and put those signatures in the key exchange So we get lots of problems there as well. So everything is Cascading into problems, but the end result is we get a really nice tight authenticated key exchange and we get this nice signature scheme Of course, those of you who know what these proofs are and can count Exponentiations you have by now counted fairly high You have counted almost as high as I have seconds left. So let's go So if you look at some performance, we do not get the same really good performance here, but still As the first thing you might even think about implementing. This is quite good. We are competitive Re snublish and of course There might be other applications where a signature scheme with a tight security proof is Gives you a much bigger advantage Okay, so let me just reiterate. We have our first really practical tightly secure signature scheme we have a first practical tightly secure authenticated key exchange and If you go to really large-scale deployments This is going to be more effective. I should also say in fairness these numbers where I didn't come off so well I really gave this signed if you have an every advantage because I used elliptic curve DSA Which doesn't really have a security proof So it got some some something for free there You should really because the signature schemes that are as fast as Elliptic curve DSA they typically have very non tight reductions not just in the number of users But also in the number of Oracle queries So the numbers might be actually a lot worse and if you move to these schemes that are tight otherwise well then you Get more explanations. So I show get show off. Yeah, our results are better really than we showed off So we were really modest here Questions, thanks