 Thank you for saying the title so I don't have to My name is Tatiana Bradley I am a student at UC Irvine and this is joint work with my advisor Staszurecki and my colleague Jayu Shu I'm going to be talking about strong asymmetric password authenticated key exchange So I'm going to explain what the problem is which is password authentication over the internet Explain how we can use crypto to do it better and show our protocol which we believe is one of the best ways to use Crypto to do password authentication better. I'll show you some building blocks, and then I'll discuss some open questions that still remain So how is password authentication done in practice now? It's basically just password over TLS so If we have a server Charles, he has a password file, which is a which has a salt and a hashed salted hash of the password and he's going to prove to Ada that he has the right public key using a certificate authority and then they're going to use TLS to establish a shared a session key, which is just going to be a symmetric key And so all of this has nothing to do with pad passwords yet But then now Ada is going to simply encrypt her password under that shared symmetric key Charles decrypts it and checks if it is matches the hashed password. So it's very simple Well, there's at least two problems with this method One is of course that it relies on PKI and we all know there are many attacks on PKI One example is phishing Ada believes she's talking to Charles, but she's actually talking to a malicious server I mean if that's the case, then she basically just sends her password to a malicious server and all of her Security regarding her password is lost. The other problem, which is a little bit more subtle is that at least for some number of milliseconds or whatever Charles holds the password of Ada in the clear So that means if Charles's server is corrupted at any point while he's checking that password The adversary who corrupts the server learns what that password is so we'd like to be able to do better with crypto and Of course we can because we're at crypto So our first attempt is going to be to use password authenticator key exchange, which is a well-established primitive It's been studied in the game-based simulation based models as well as the universally composable model So how does that work? We assume Ada and Charles each have a password they insert it into a paked protocol And then they get the same key if their passwords match. Otherwise, they get an independently random key and You can think of this as just like a secure computation of a password equality function with the addition of getting keys So what are the good things about this? No pki attacks because there's no pki. So we're good for that problem with TLS and The other good thing is that Charles doesn't get Ada's password in the clear during the protocol because it's your secure computation So her password is private But of course in order to be a server Charles needs to store the password on his server that he inserts into the protocol so basically We have an even worse problem with the server with the server storing a password in the clear because it's so it's stored for a long time not just a couple seconds so We hope to do a little bit better than this and the here we have something called asymmetric pake and This has also been studied in the game base and you see models And this is a simple extension of pake in which instead of storing just a password Charles the server stores a hash of that password so you can think of f here as a one-way function We of course have the same pros of pake normal pake and then we get the added pro that if the server is compromised then The adversary has to do an offline dictionary attack in order to learn the password based on that password file but because the Function f is a public fixed function Any computation for that offline dictionary attack can occur before the actual server compromise so basically the adversary who has some time on their hands can do a bunch of computation and then once They get access to the server immediately determine what a lot of the passwords are so we want to do even better than that and This is where we have strong asymmetric pake and this is recently proposed at Eurocrypt by by my advisor and my colleagues and 2018 and I The way this works is probably how you thought it would which is instead of holding a regular a unsolved or unrandomized function we use a randomized function, so we just add a salt a random salt and Now we get the benefit that there's no possibility of offline dictionary attack pre-computation because the salt is per user and It's not known beforehand So finally we are able to use crypto and get all the benefits of a password over TLS, but none of the shortcomings, so this is great But what's our contribution here because this is already existing so just to recap we have password over TLS the current De facto standard. This is nice because it's standard. It uses TLS. It's efficient. It's modular. Basically, it doesn't matter What hash function you use it doesn't matter what encryption scheme you use you just encrypt the password But as I said it has the two problems that I mentioned So opaque the protocol proposed at Eurocrypt Proposes a universally composable strong a-pake that of course is independent of PKI It has three rounds and it's based on an interactive assumption And what our contribution is is that we're proposing a new UC strong a-pake and we're able to shave off one round We have a similar number number of exponentiations, but we don't have to hash onto a group We we have a number of assumptions including ROM We also use GGM, but that is isolated into an offline part of the protocol and we're also proposing some new some new Primitives the UC tight one-way function and the implicit statement conditional seek him and we're showing how we can adapt a existing paradigm for pakes and for UC pakes into Strong a-pake and also shave off one half of that paradigm. So It's a nice little result there So let me get into it explain each one of these things. So let's start with the tight one-way function So this is in the UC model So we have something called f-staff and that's the idealized functionality of a salted tight one-way function and The salted tight one-way function has some passwords some secret password that it knows and it has some notion of Being compromised and it has some notion of having a password attack password guests being Happening against it so in the case that it's compromised is where it's just sends a message. Okay, I'm compromised and in the proof or in any kind of proofs using this we need to When we hear that the server has been compromised We need to sort of generate some kind of password file that looks legitimate to Pretend to have been a real server that has a password file So we have to generate that based on usually just some kind of random Password, but we don't know what the password is so we have to generate that without knowing the password and then the the other functionality of the F-staff is that you can ask it is this the right password? So it's basically like a point function where you're saying is this the password it says yes or no And I learned whether it's the password and then using that functionality as a simulator We need to translate the real attacker who's doing some kind of offline Local computation we need to translate that into a password guess So for example if the one-way function is just a hash function It's saying hash of password X And then we say okay since we're a random oracle we know what that password We know what that password was and then we say is this the right password? Yes or no, and then if it is right we program the password file to have to be Correspond to that correct password guess if it's not we just give it some kind of some kind of junk So as I've been saying I gave an example with the random oracle model It seems like with this model you're going to need some kind of idealized computation Yeah, so this is just a description of what a tight one-way function is Basically you can think of the tight one-way function as being You if you make a password the the best the best strategy for Learning the password from the hash password is simply to guess all the passwords trial hash them and so forth so brute force You can't like shave off a factor an exponential factor something But yeah, so as I was saying it's It seems like we're going to need some kind of idealized model for this so the first example I gave is the hash function and That's what password over TLS basically uses Because the server is storing that hashed password Then the other Example is the hash in the exponent type where you have a group element That's the a random group element That's the salt and you raise it to the hash of the password and that and we're using a variant of this and it's been used before It requires a programmable generic group model in order to show that it's a staff But we're okay with that because this tight one-way function is only surrounding the sort of offline part of the protocol in which the adversary is Compromising the server it's not during the actual protocol So this this does raise some questions such as are there can we prove a tight lower bound for some other arithmetic one-way functions beyond the one? I just described There is a one caveat and this is something technical that you can read about more in our paper But we're actually using a variant of this hash in the exponent Which is similar to the Bon Ivoian signature function and the reason for this is because we don't want the password file to be malleable and The reason for this is that we don't want the adversary who steals the password file to be able to Randomize the password file and then pretend to be the adversary without us being able to tell that they're pretending to the adversary So it's kind of a technical point for the proof But from now on in the talk, I'll just sort of use this app staff as an abstract primitive Alright, so I told you that we are working with a existing paradigm the Encryption plus SPHF paradigm. So let me show you how that works with regular peak If we have if we go back to our regular setting where we have a pass we have a password on both side Unless opposed that Ada wants to prove that she has the right password so Ada sends a commitment to her password using a public key encryption scheme and The public keys in the CRS so she she commits her password using the public key encryption scheme and then Charles creates a Statement that's in a think of like an NP language. He creates a statement that says okay This commitment of a does encrypts the same password as the one that I have so it encrypts my password And of course the statement could be true or it could be false and Then he plugs the statement into this magic SPHF box the SPHF SPHF has two algorithms. It has the hash algorithm and the P hash algorithm and P hash stands for projection hash The hash algorithm takes in a statement and it outputs a value and a hash projection The value is like a secret value the hash projection. You can think of it as kind of like a key so the hash projection You can send that to someone and then they can use the P hash value along with a witness for your statement That to get that same value so What's happening here is that? Charles is showing That so if only if Ada has the witness for her commitment Can she recover that? That value and also she can't recover it if she encrypted the wrong password because the statement will not be in the language So that shows that that proves to Charles that Ada has the right password But then Charles has to show Ada the same thing. So you just do the same thing symmetrically on the other side And that's and that's how the SPHF plus encryption paradigm works What about with a pic so with a pic we just do a simple transformation we instead of having Charles have the password he has the hash of the password and he his commitment his statement is that Ada's commitment encrypts the pre-image of The pre-image of his password file and he instead In he encrypts the password file instead of the password and so forth. It's just kind of a simple transformation So that all that's all fine. And what about for essay pic we can do the same thing but with the salts but What we notice here is that because we basically need to use ROM because of the staff as I said we need to use ROM for the staff so If we use ROM We can shave off a whole half of this protocol Oh and just to just for some context this kind of thing can be done without the random oracle model in general But if we say okay, it's fine to use ROM then we can shave off half of this protocol. So how do we do that? Well, we do we do need to change some things so in particular We now have Ada now has no guarantee that Charles has the right password file Because she proved that she has the password, but he didn't prove anything So we need to embed inside of this this Hash projection some more information. So we need CCA security. We need it to be non malleable and we also need it to be able to carry a payload an encrypted payload so Because he because Charles needs to be able to send his password file over to Ada So she can check that he does have the right one and has to be non malleable so that he can't Pretend he had the password file when he didn't really have it And then this sort of changed SPHF is going to be what we call an implicit statement seek him All right, so the implicit statements seek him is works pretty similar to the SPHF We have a send algorithm. That's like the hash algorithm and a receive algorithm. That's like the p-hash algorithm The send algorithm Transforms a statement into a key and a ciphertext the receive algorithm Transforms a witness and that ciphertext into a statement and a key so here It's called implicit statement because the receiver does not need to know what the statement is In order to generate the value and in fact she retrieves the statement in the in the course of doing the receiver algorithm and So that's great because in our setting the receiver who's going to be the client Ada Doesn't know what the password file is. She needs to grab it and check it and And then this is a trap door conditional seek him and so that means we have a trap door algorithm that can use a trapdoor and the CRS to compute the same values that Ada can compute and They look indistinguishable from Ada's values. This is just used in the proof and We also have simulation stoutness which you can think of like CCA and that's that the key appears to be rant the key K that the Sender generates appears to be random if the statement he Sends is not in fact in the language even given the presence of this trapdoor receiver So you can think of that like a decryption oracle and Finally we have statement privacy which says that the statement is hidden without the witness and this is The thing I just described is fairly similar to implicit zero zero knowledge Proposed by Benhamuda at all But the new thing here is this statement privacy notion and that's that the statement is hidden Given the cybertext you cannot determine what the statement is unless you have the witness and that's important because if the statement is revealed then the statement reveals the password file and Then it's as though the adversary Compromise the server without even having to do any work. So basically just by listening on the network They would get the password file and we don't want that to be the case All right, so how do we make the implicit statement trapdoor seek him? I'm not going to go through all the details But you can think of it like if you're familiar with the Fujisaki Okamoto transform from CPA to CCA public key encryption You can think of it like that basically what we're doing is we are We're Encrypting we're using that That hash value that we got that we know is the same if those two passwords if the passwords match We're using that to encrypt the randomness that we use to make the hash and also the statement itself And also just macking everything so that nothing can be changed and then Then Ada now knows that if Charles sent her a valid cipher text That he does have a valid. He does have a valid password file and nothing was changed So basically if we tie that all together what that gives us is this is like the picture before except now We're using the trapdoor seek him and the send and receive function instead and Just to recap we know that Ada authenticates herself using Using the basic seek him security, which is that if she's able to decrypt the Charles is Charles a cipher text then she must know The the witness and the statement must be correct. So she must have Encrypted the correct password and then Charles also authenticates to Ada because he's including his encrypted password file and the payload so we We basically just combine The the work that is done by the SPHF, which is the Authenticating Ada with the authenticating Charles into the same cipher text. So that's how we shave it down to two rounds And this is our protocol. Oh and just to just as a note We instantiate the PKE with a lifted Algamol, which is just a slight variant of Algamol and with our instantiation of the Seek him based on SPHF. We're able to get a very efficient protocol What I want to highlight for my summary is that we are in our instantiation is is quite efficient Not only does it have two rounds, but it also in terms of variable variable base Exponentiation which are much more expensive than fixed base exponentiation We only have one or one to two per party And so if you think of regular Diffie-Hellman key exchange, you would have one variable base per party So we're actually getting pretty close to that plain unauthenticated Diffie-Hellman and That leads into One thing I'm particularly interested in which is integrating this work with TLS. That's our last open question But some other Cool open questions are whether there are other tight one-way function constructions Like with different assumptions and maybe we could even get rid of GGM and ROM It's a possible to shave off the rounds from SAP even further Would we be able to make a seek him faster by using DHIS type transforms that of FO? Finally, could we extend it to two-factor authentication or TPEG? So yeah, that's all I have. Thank you so much for your time All right, we can have some time for questions. Please come to the mic if you have one So I would have a quick one regarding But I guess the last bullet point integration So my understanding is that OPEC is on its way to potentially being standardized at least it's an working group item of the CFRG Do you have any similar plans with that protocol? We don't have any specific plans regarding that and I am aware that OPEC is On it's on the road too, but I I would like to I don't have specific plans But I would like to get in on that if possible. Yeah, cool. Okay. All right. There are no other questions. Thanks. Thanks