 Come to the third session on protocols. And the next talk will be asymmetric PIC with low computation and communication by Bruno Freitas da Santos, Yankee Gu, Stanislav Shereke, and Hugo Kravchik. And Stanislav is giving the talk. It's my mic on. Hi. Good morning, everyone. Thank you for coming. OK, thank you for the introduction. OK, so let's start with what PIC is. PIC is, hold on, is there a pointer here? We're very weak. Ah, OK. Well, PIC is a functionality where two parties put passwords. And the functionality checks if the passwords are the same. If they are, it gives them a fresh random key. If they are not, it gives them independent keys. So it's used for authentication and key establishment at the same time. And the most efficient PICs in the random oracle model are they all come from blinding Diffie-Hellman key exchange using passwords. And it starts with encrypted key exchange by the value of the merit and continues by the first result uses ideal cipher, then random oracle onto the group, not onto the group, and then the costs were optimized. But they are basically roughly like a key exchange. Now, what we do in this paper is an asymmetric PIC. What is that? So now the server no longer puts a password into the protocol. He has a deterministic one-way hash function of the password. And the functionality checks whether the client's input and the server's input are related to this one-way function. Why? So that when a server is compromised at some point and presumably has a database of user accounts and these password hashes, the password doesn't go in the clear, you have to do a brute-force search to find the preimage of this deterministic hash. That's the problem we address here. There is a strengthened version of this model where we call strong asymmetric PIC where the server's hash is randomized. The randomization is commonly referred to as salt in the hash. And now the functionality checks is randomized hash. The key thing is that the salt is private to the server, does not leave the server. And why is that beneficial? Because the brute-force attack cannot be pre-computed before a server is compromised. These asymmetric PICs that we address can be salted, but the salt is by necessity public. It can be derived from client's name, server's name. It can be derived from some random nonce that the server stores, but the random nonce has to be sent to the client in some form because hash function is assumed to be computable by the client. And for completeness, because we will use this tool, let's compare it to an authenticated key exchange where the two parties have private public keys. The public keys are a common reference string under which they execute. And if one party supplies their private key and the other there, then the keys are established. So that's the public key counterpart authenticated key exchange. So what is known efficiency-wise about these things, about password authentication? So let's first look at just symmetric PIC, right? So encrypted key exchange, PIC, S-PIC, other variants, they basically get a cost of an authenticated Diffie-Hellman key exchange. Moreover, they have sort of perfect communication pattern. It's a unanimous single flow. Just like in a Diffie-Hellman, I can send G2TX. You can send G2TY. Maybe you sent your G2Y yesterday. Like we can do this asynchronously. And then when I get your message, I compute the key. And so the same for you. And these symmetric PICs have these property as well. Now, if you want explicit authentications, then you have to do three rounds. So that's optimal, too. Now, what about the APEC cost? So first, Jude, Lehen, Roy had actually a unanimous, so minimal communication protocol, but it used by linear maps, type three curve. So it was significantly more expensive. Now, there are compilers that, given a PIC with signature, by Gentry et al, give you this authenticated, this asymmetric PIC. And then Schub had a specialized result for version of S-PIC that supports asymmetric setting. And these compilers were, these settings were in a non, well, so first they don't have salt. And I have a little bit of a start there. So what is the double star for the no salt? Well, if whenever you have APEC that doesn't have a salt, you know, you can always add salt. The server sends salt, at which point the non-salted version can run, but you add two flows. The client has to say, hey, what's the salt? The server has to say, here's the salt, and then they run the previous protocols, right? So from three rounds, you get five rounds. In the last crypto, we had this protocol Cape that gets the cost down to unauthenticated key exchange. So somehow you get the cost of this asymmetric stuff at the minimal cost of, you know, just Diffie-Hellman. But we had four flows, okay? So suboptimal, I mean, non-optimal flows. And we don't get minimal flows in this paper. So this is this paper. We just shed off one round, actually, because in our protocol, it's the server that starts. It is a two-flow protocol. And whether in practice, the client starts or the server starts, you know, some people have strong belief about this. I think that both options are possible. But it is not one round, right? And we had an optimization in this paper, and we apologize to everyone, that we realized there is a scenario that leads to an attack. So it's insecure in general. And I'll try to explain why, because it's a cute example of, well, help and mistake. But it is secure in some, for some applications. So I'll try to explain what kind of applications that would be. So there is like, you model this by leakage of certain form, and we believe then you are okay. But only for such applications. Just if you wanted to wonder, you know, if you move from public salting to private salt, like the strong APEC, what are the additional costs? Well, here are the additional costs. So there's different versions of, first of all, APEC and some alternatives. And in particular, the first line actually gets two messages, but none of them get one, right? So except of Jutlaroi, which has significantly higher costs. Okay, so let me start, like how do we create this protocol? And actually, okay, the protocol I'm going to talk about today is a modification of the crypto protocol, CAPE. So they use similar tools. They basically one comes from the other as an improvement on it. They both use something we call key hiding, authentication key exchange. So here is what that is. Unlike a standard key exchange where you think of public keys as, you know, everybody knows what the public keys are. Here, no explicitly each party has to send both their own secret key and what they think the counterpart is public key is. And there is a difference between that and the, you know, standard notion of authenticated key exchange where the public keys are like reference in the sky that everybody knows. Because think of the server as an attacker, the public key and even the, of the servers that client assumes and even the public key of the clients that corresponds to the SKC the client uses, both of these are not public. The only way to learn anything about what they are is to contribute matching pair, right? And otherwise you don't know what the other person uses. Okay? And that's going to be important. Why? Because basically in our protocols, both the crypto protocol, CAPE and the current protocol, okay, I'll copy. The client doesn't have any keys. They must derive those keys from a password. So how do they derive their secret key? Well, they just harsh the password, they get randomness and they get secret key. What about the public key of the server? Well, there will be a ideal cyber envelope from which they will decrypt the, what they think the public key of the server should be. And the ideal cyber has to be key hiding because nobody knows, given an envelope what the correct public password should be. Under every password, you derive different public keys. So you cannot test that way. And, but it is a form of a commitment too in the sense that for a fixed password, the public key is non-random to whoever created this envelope because they can create a secret key, then public key and then envelope. But for all other keys, the envelope is going to map to random public keys and there are four instances of whatever systems that are going to be secure. Okay. How are we? So here is, okay. So why use this tool? Because actually it's a very inexpensive tool. So here are three options for how you could implement a key hiding authenticated key exchange. Triple DV Helman. The green person has G to the X and G to her secret key SKC. The blue person has G to the Y and G to the SKS and you do DV Helmans, right? So this first thing is G to, you know the green exponent and the blue exponent are always paired up. So the green party has two exponents, the permanent key and an FMRL key. The blue party has permanent and FMRL and they do a bunch of DV Helmans to, yes, they can both compute and it both implements authentication and freshness. You can combine them all into one equation in the beautiful way that H and QV does that. And then you have the cost of effectively a single DV Helman. And then you can also do this with generically with any chem, right? I encrypt for you, you encrypt for me and then one of us sends a public key fresh one and you encrypt under that. And we have three nonces, we derive through the keeper but just watch out because if you think that you can do you know, this is generic chem so therefore you can take a lattice chem. There is a gap. You need key privacy in these applications so the chem has to be key private and you need to have a security against a plain text checking attack. And as far as I know, plain text checking attack is like, there is no efficient ways to achieve it except for basically CCA attack, CCA security. And then you have issues with key privacy. There is actually two talks about this later on in the other session and yet in some other in two sessions about key privacy of CCA secure versions of lattice encryptions. Okay, so these things are inexpensive. So here is how the crypto protocol went. So as I said, the client that only has a password so she has no keys. Okay, but she can derive her secret key from how I hashing the password and the client is the server's public key will be encrypted under an ideal cyber envelope encrypted under the password. So that's how she and importantly is an ideal cyber over a group. Excuse me. So that was my ramp session talk like the importance of ideal cyber over groups for this type of applications. So how do they do it? She derives the secret key. He supplies to her this envelope. She derives the service public key from that. Then they run this key hiding authenticate the key exchange which as I showed on the previous slide is not expensive and they need key confirmation messages which will account for the non-optimality in round complexity of this construction. Why do they need these key confirmations? Well, the client to server key confirmation. Why is that? Because I failed to point out on the previous slide these cheap authenticated key exchange protocols have no power out secrecy. So let me flush that because you see why don't they have power out secrecy? Because let's say I'm a blue guy. I put in G to the Y into the protocol, right? I don't have SKS. I don't have the secret key of the server. But if you look at these equations later on if I do get the secret key of the server then I can complete these equations. So if the client just happily uses the key without me sending a confirmation message that proves I have the SKS at that moment then she's subject to an attack where I corrupt the server one month afterwards and I decrypt everything that she did with that key. So it has no power. These things don't have perfect core secrecy. You can build perfect core secrecy by key confirmation messages and that's why it's very important here. And so in particular, look what happens without the client to server key confirmation message. Attacker doesn't know the password. She just puts in these ephemeral values into the authenticated key exchange. Then eventually she does offline dictionary attack. She finds the passwords and eventually she derives SKS and PKS she can complete these equations. It's a funny thing about an encryption that I can send a ciphertext without knowing your public key. And even month later I learn your public key then actually I can learn what's the chem key that you received. Most encryptions are, they don't commit to the public key that is used. Some do, but it's like by coincidence. Most of them don't. And the role of the server to client key confirmation message is that if eventually the server gets corrupted, again, the adversary is going to learn the private keys that allow the completion of this key, of this authenticated, of the key derivation equations. So what do we do? How do we improve that? It's some sense. It's a simple observation. We don't need to create these server keys beforehand. Instead, we do one more hash. Of course, the client derives it online. And given that hash, the server can now create a one time secret public key pair and envelope the public key under the same, under that hash. So the client decrypts under that hash now. What does this do? Two things. Because it's a one time key, the key hiding ache gets cheaper because we don't need independent freshness. This one time key is already fresh. So basically we shave off one exponent, you know, one D.P. Hellman from these equations because you don't need a femoral, independently a femoral key stuff. Secondly, the key confirmation is not needed from the server to client because what was the reason for it? It was that eventually you corrupt the server and you learn this permanent secret key residing on it. Now the secret keys on the server side are femoral. So there is nothing to corrupt. And okay. So we get basically two things, improvement in efficiency and shed off a round. Here is, you know, quick think like why each efficiency gets better, but it's not so important. I think this picture is kind of cute. Here is the classic protocol encrypted key exchange on the left, but in a two round version. So what did the love and merit do at the very beginning of the whole story of cryptography and password authentication? They said, D.P. Hellman basically, or any key exchange and just encrypt under passwords. And in fact, if you do it in two rounds and only the first person has to encrypt under the password, okay? And if you look at the protocols that we have now in the, you know, this OCCAPI protocol I was talking about, this is its instantiation with either three D.P. Hellman or HMQV, because they only differ by the way you derive the final key, not in messages that you exchange. And you might observe that you exchange exactly the same messages as in symmetric peg. The only difference is the way you derive the key and the fact that the key you use on the server side was, you know, was, well, kept for, yeah, the client's key was kept on the server. You know, what kind of application would make use of this fact of this, the fact that the two look very much like, okay, some sort of code minimality maybe. And here is why this is OCCAPI because this first message is the delivery of the envelope. Here is the key hiding authenticated key exchange. It's really just a single message and a key derivation and a key confirmation. And let me just do one more thing, which is the insecure version. So this parallel between this protocol and encrypted key exchange only goes so far, sort of drunk on this parallel. We proposed the optimization where here is the unanimous flow. No, this is the two round version of EKE. And here is the unanimous version, okay, because the two messages can be created independently. So we thought, okay, maybe the same work here. And it doesn't quite, there is a scenario where this fails. The scenario is this, let's say adversary corrupts the server. So they know the hash of the password and therefore they can run as the client except they don't have the private key little a, right? So if the adversary at the moment when he pretends to be the client to the server after server compromise. So this is known as KCI attack. I attack the server and then I pretend to be the one of the clients. I don't have the discrete log. I cannot complete the equation, but notice that we got rid of the key confirmation. So server will happily use the key, but once the offline dictionary attack succeeds, attacker finds the little a, completes the key derivation equation and the old stuff that the server did with the key leaks. So it hasn't have that version has no proper security. On the other hand, if you have an application where you use PAKE to grant short-term privileges, like credentials, right, then access control, then this kind of long-term usage of the session key is not important for those applications. Let me conclude. Well, this, I said all maybe some follow-up questions. This motivates the IDL cipher on the groups how to exactly implement it. I mean, not only this, but this in particular, you can get lattice-based asymmetric PAKE from lattice-based symmetric and lattice-based signatures by the GMR compiler, but using CAMS, perhaps it would be nice to just do this using CAMS. And then, of course, minimum cost, minimum one, what's the cost of the one round? Couldn't we just do it for round? You know, unanimous message flow. This protocol has still two message flows. Thanks. Let's thank the speaker. Do we have any questions? Okay, let's thank the speaker again.