 Hello. Welcome to a talk about CAPE, an asymmetric PAKE protocol from key-hiding authenticated key exchange. It's a joint work with Yankee-Goo and Hugo-Craftrack. I'll start by recalling what PAKE is. PAKE is the protocol where two parties contribute passwords, and if those passwords are the same, then the two parties compute the same random session key. Otherwise, they get independent keys, and this implies the authentication, because if the two passwords differ, the key leaks, one party compute, leaks nothing about the key of the other party. What are the most efficient existing PAKE constructions? Very briefly, assuming standard groups and the random oracle model, the most efficient schemes use the password to blind in a way messages of the DPP-HELM key exchange protocol. Each of these protocol proposal could be viewed in this way, starting from the encrypted key exchange of EKE of Bell of Merit and the overhead, some of these protocols create in particular, this one are very low compared to the underlying DPP-HELM key exchange. In a client-server setting, it's useful to have an asymmetric version of PAKE called APEC where the server stores a hashed password, not the password itself, and the protocol checks that the client's password hashes into the server held value. The advantage of this is that on server compromise, adversary doesn't get the password itself, but it's hash, so if it wants to compute the password, there's a one-way function, but it's a deterministic one, so it can compute forward on any password guest. However, it's called brute force search, but if the entropy of this part is high enough, then the password will escape the search. The search will fail to find the password. Existing APEC constructions are formed by essentially a PAKE with something added, and this is either a password-based encryption or a signature, and the signature is the lower cost option using snore signatures cost half the key exchange, so the overall cost of such solution is about one and a half of DPP-HELM. It can be strengthened to strong asymmetric PAKE where the hash is randomized. The point is that because it's a randomized hash now, it cannot be pre-computed because before server compromise, adversary doesn't know this randomization. The most efficient strong APEC is the OPEC construction, which is a compiler from oblivious random function and authenticated key exchange. For this, I will invite you to these talks or papers, but for authenticated key exchange we'll talk in a second. The bottom line is that both of these can be instantiated in this setting at the cost of key exchange each. This gives you two key exchange costs for this strong asymmetric PAKE. Now, what about this building block? We will need it in this work. Authenticated key exchange refers to authentication key exchange in a public key setting. So each party has secret and public key pair. The public keys are assumed universally known and tied to identities of these parties. The functionality is that if you get the same key, even only if you supply the secret key corresponding to the public key and so does your counterparty. There are many protocol proposals. TLS realizes this type of mechanism. The most efficient is HMQV. Some would surprisingly actually get the same cost as the DPM and key exchange. We'll look at this protocol in a few slides, because we'll use it here. Summing up, the efficiency landscape is that authenticated key exchange as well as symmetric password key exchange can both be implemented at the cost which matches plain unauthenticated DPM and key exchange. Excuse me. Now, this is not so for asymmetric PAKE and even less for strong asymmetric PAKE. So what do we do here? Our main contribution is a protocol we call CAPE. It stands for Key Hiding Authenticated Password Key Exchange, and it's an asymmetric PAKE created using a Key Hiding Authenticated Key Exchange. Because the overhead of this construction over the underlying key hiding egg is very low, and HMQV turns out to be a Key Hiding Egg. So basically, the APEC has the same efficiency as HMQV, and that in particular places APEC in the same now asymmetric PAKE costs essentially the same as the symmetric one. In more detail, our APEC construction is a black box compiler from Key Hiding Egg and IDR Cipher. Now, this IDR Cipher has to work on groups. So if the group is an elliptic curve, you have to work a little bit to implement it. One possible way to implement it would be using uniform encodings of elliptic curve points like Elegator 2 or Elegator Square. Another comes from the recent work by Matt Goye, Rostler and Roy, which show something which you can call weak IDR Cipher, that can be implemented with a single for a group, implementable using a single or random oracle hash onto the group per each Cipher operation. They show that this is sufficient for encrypted Key Exchange, which originally used the IDR Cipher, right? We believe that it can be also plugged in here, but still have to formally confirm that. Because we base our construction on this new Key Hiding Authenticated Key Exchange sub-protocol, we define this notion in a composable way. In particular, we can plug it in our own construction. We showed that in random oracle model, it's realized by several implicitly authenticated Key Exchange protocols out there, including HMQB, Triple DH, and Scheme. The last one is interesting because it's a black box construction from CEM, so it can lead to post-pon-to-may-peck design alternative to those. Now, taking the two together, gives us the most efficient opaque today, and it's optimal in terms of computational cost because it has roughly the same cost as the underlying Key Hiding Authenticated Key Exchange. It comes at the price though, it has four flows, three if the server starts, versus three flows in the standard setting where the client is an initiator, which was the case for prior APEX. Now, another interesting implication is that, if you instantiate, use this now low-cost APEC, you can use it to instantiate an alternative strong APEC construction, called OPEC Prime, which was given in the same paper that introduced OPEC. Because now APEC and APEC cost the same, so these two constructions have the same computational efficiency, but new construction has a funny advantage. Namely, it offers a graceful security degradation from strong APEC to just APEC if this sub-protocol breaks. Now, in one sense, it's going to break, it's a key leak. It's information theoretic for the client, so this implies this graceful security degradation. Why is it useful? For example, if you outsource the oblivious PRF block, but this outsourcing fails you, the worst that happens is that you downgrade from this to here. Another is that perhaps everything is quantum secure, but the OPRF not so, and indeed the quantum secure OPRF is still not very efficient. So it comes at the price. First of all, also we have one more protocol flow, so this is a four-message protocol, whereas OPEC is three, and it needs a specific ache, namely key-hiding aches, and in particular we cannot use the sigma ache from TLS, which will probably make integration with TLS easier for OPEC compared to OPEC prime. Okay, so that's the contributions. In the rest of the talk, I'll talk about what this key-hiding ache is, and then once we get that clear, how that this compiler works. Okay, so here's the key-hiding ache. So it's in the public key setting, where everybody has a secret public keeper, but unlike the standard ache notion, we modeled input since the public key of the presumed counterparty as the explicit private input of each of it party-participating in the protocol. So these are not defined by names. These are explicit inputs, and the rest looks the same, and now where's the key-hiding property? So notice that the key, the only output that this party gets, assume client is an attacker, is just a random key, right? Which is whether it's independent of K prime or the same, this person doesn't even know. So in particular, basically everything about these inputs is hidden by the, must be hidden by the protocol messages which will realize this notion. However, of course, the server computes a key here, and it can use it. So without the generality, it gives it to the environment which gives it to the client, right? So the client basically can reveal what the session key server computes is. And now using it, it can test whether it's a secret key, public key input, match the one server uses. So in that sense, that's the way in which it's not key-hiding. If you have the corresponding matching pair, you will test and figure out that I use the ones that match yours. But if you don't have them, then in particular, you don't have the secret key corresponding to this one. You learn nothing about either of these two inputs. Okay, however, we have no perfect forward secrecy. Okay, so in particular, when the server, let's say the client, at the time when the client runs this protocol, it really doesn't have to have these inputs. So it is possible that after the protocol stops, it really name uses the inputs and computes this key. And then compares to the key that the server gets and which adversely learned from the environment, which allows basically offline testing of any SKC, PKS pair that adversely learns in the future. Now, for better for secrecy, this is easy to stop. You just introduce key confirmation message. So the client has to confirm that it learned the key that matches the server one, or otherwise the server is not going to output this one with proof that the client knows these inputs before this guy decides to use the key, right? So it just stops this whole thing. However, better for privacy is not so easy because the first party, let's say it's the client who basically sends the key confirmation message, allows the server side attacker to then, well, if he doesn't have these matching inputs, then he cannot compute the key and he cannot send his key confirmation. So the client will abort. However, after if he learns these inputs, he can still compute the key and test whether it was equal because it has the key confirmation message from the client. Now, one can implement more secure notion. I mean, it's basically a notion which has to be perfect for privacy. Using the standard secure computation approaches commit to input, in particular commit to these inputs at the protocol execution. We don't because we're not interested in the strongest properties you can get for this. What we're interested in is to model minimal properties necessarily that this compiler goes through. And also that the properties will actually be realized by these least expensive key agreement protocols because it's the efficiency of the resulting asymmetry peg that we're after. Okay, so here's one example of how to realize this. This is a triple DP Helman used in the signal application. The setting is like the keys are like in Ergamal, encryption or if you have a key exchange and the messages that people send are just the DP Helman key exchange again. Note that the messages are independent of the input. So the messages themselves reveal nothing about these inputs. Now, how is the key computed? It's computed using a three as an arrow hash of three separate DP Helman instances where the client always makes one contribution and the server makes another. Either the ephemeral key for the client or the long-term key. And likewise, either ephemeral key for the server or a long-term key. So the protocol messages, but note that the protocol messages don't reveal anything about the long-term input but they do not commit to long-term inputs. So this party might not know these inputs when they send a message and when the counterparty outputs this key. But if they learn these inputs, afterwards they can complete this equation and learn the key as well. HMQV can be seen as an optimization of the DP Helman. Everything is the same except for the QiverVision equation which in a very nice way combines this three-way or really four-way matching of ephemeral keys and permanent keys for each side. Because the DP Helman contribution on the client side is a linear combination of the ephemeral, DP Helman contribution and the long-term. And so it is for the server where the linear equation here is a random one with the random coefficient output by the random oracle hash. So we showed that this protocol has the same properties as the DP Helman in particular is key-hiding. But it is advantageous in that its cost is very, it's roughly the same as the DP Helman Q exchange itself. Okay, so now how do we get this compiler using the key-hiding egg and an IDR cipher to get asymmetric peg? Because it's an asymmetric peg, we have to specify what is this quote unquote hash password that the server stores for a given client. Okay, so here's how we compute. We pick two public key pairs, one for the client, one for the server. And then we encrypt the AKE inputs of the client, namely the secret key of the client and the public key of the server. We together encrypt that under the client's password and we call this an envelope. The server's file is that envelope and the credentials it needs for authenticated key exchange. So it's own secret key, the secret key here and the public key for the client. Now note, public key in this crypto systems is a group element. Hence we need IDR cipher on groups. Now how does the protocol goes? Very simple, the server sends this envelope to the client. The client uses her password to decrypt the envelope and interpret the outputs as the secret key for herself and the public key for the server. And then the two run key hiding AKE on this corresponding inputs. Now, crucially, you need a round of key confirmations. Excuse me. And importantly, the client has to go first. And these are important for security as we'll shortly explain, but also they account for this extra protocol round compared to alternative APEC designs. It's interesting to compare this compiler to classic encrypted key exchange of beloved merit. Both protocols use IDR cipher to encrypt group elements and compile some form of key exchange into PAKE, but EKE compiles plain key exchange into a symmetric PAKE and we compile authenticated key exchange into asymmetric PAKE. And how we do? Well, encrypted key exchange uses the IDR cipher to password encrypt every message of the key exchange. What we do is to IDR cipher encrypt under a password, only the inputs of the client in the authenticated key exchange. Okay, so some similarities and some differences, but it's funny that this very classic protocol kind of gets resurfaced in a different version here. So now, why is it secure? So let's notice that basically by the property of this, the only thing that the party engaging here learns is the key and it's a random key regardless of the inputs. So the real information is in the envelope and in these key confirmation messages. So let's look at the envelope first. For a passive attacker, they can decrypt an envelope under arbitrary passwords and every time they do so, it gives them some random secret key for the client and random pass public key for the server. However, by the key hiding properties of AIC, this pair cannot be correlated with the inputs of the honest parties unless through an active attack. So let's look at an active attack. First, if the attacker plays the server role, so imagine an attacker on this side. What do they do? First, they have a choice of the envelope. However, because it's an IDR cipher, every choice of the cipher text commits to a single key, which is a password in this case, for which the decryption is non-random. So it can be controlled by the attacker. So in other words, the attacker can encrypt any secret key for the client and public key for the server that they want on a single password. But on any other password, it would decrypt into random keys. In particular, if it does, because this key will be random, so the adversary cannot know the corresponding secret key. And therefore, cannot go through this protocol and authenticate, and basically cannot make anything from this message and cannot send that one. On the other hand, for the password, for the single password, adversary does control what these inputs are, and therefore can pick them in such a way that it knows the corresponding values on the other side and go through the protocol, right? But that's a single password. It's an online choice. So this is the same as a pick, but it does allow you every session you interact with, you can test one password on it. Now, what about client's confirmation message? It is necessary because the adversary preying the client without this message could later, given the client's the server's key, perform this test offline. It can decrypt the envelope under different passwords and get these candidates, and for each of them completes this and test against the server's output, right? But if it has the key confirmation message, if it has to send it, then that has to commit to a single value here, which means a single value here, which means a single password, and again, that is an online choice of a unique password on which the adversary plays here. The server's key confirmation is a little more subtle. It basically protects against, without it, the protocol would be insecure, against future, the past client sessions, which use the key here without waiting for the key confirmation would be insecure against future compromises of the server, where the adversary learns these values and completes this, confirms here, and now knows the key for all prior sessions, okay? So, but with the key confirmations, this is stopped. And with that, I conclude, we showed a new APEC construction with optimal efficiency. In the process, we defined key-hiding eggs and showed that some protocols realize it efficiently, and it has these interesting implications for also for strong asymmetric take. Some follow-up questions, what about optimal cost and optimal round complexity and about lattice-based implications of this? And with that, I conclude, and thank everyone listening, and invite you to the presentation.