 Hello, my name is Benjamin Lip, I'm a PhD candidate at Inria-Paris and I'm presenting our EuroCrip 2021 paper, analyzing the HPKE standard. It is joint work with Joelle, Bruno, Edward, Eike and Doreen. HPKE stands for Hybrid Public Key Encryption, where in this context hybrid refers to the Camden paradigm. An asymmetric building block is used as key encapsulation mechanism and a symmetric building block as data encapsulation mechanism for efficiency reasons. Hybrid schemes have been used and standardized since a long time, but all of the existing ones have problems. For example, they rely on outdated building blocks, they lack proofs of NCCA security or they fail to provide test vectors, which would help interoperability. The new HPKE standard by the Crypto Forum Research Group addresses all these problems. Its creation was motivated by the realization that two IETF standardization efforts require the same building block and efficient public key encryption scheme. These two are the Encrypted Client Hello extension of TLS 1.3 and the Messaging Layer Security Group Messaging Protocol MLS. The HPKE standard exposes three interfaces. The Single Shot Encryption Interface encrypts one message just as you would expect from public key encryption. The Single Shot Secret Export Interface provides one shared secret of almost arbitrary length. It can be used in a higher level application. This is interesting because cams usually output a fixed size shared secret and so this API provides a secure way to expand this to an almost arbitrary length. Almost because in practice the specific key derivation functions have limits. And finally a multi-shot interface where the user can encrypt multiple messages and export multiple shared secrets as they wish. In this work we focus on the Single Shot Encryption Interface. More orthogonal to this classification of APIs, HPKE defines four modes. They vary in the involved long-term key material and their names somewhat reflect their authentication guarantees. As long-term key material we have receiver key pairs, sender key pairs and pre-shared keys. HPKE always requires a receiver key pair. In the base mode there is no other key material involved. In the Outh mode there is a sender key pair being used for sender authentication. In PSK mode a pre-shared key is used for sender authentication and reinforced confidentiality. Finally in Outh PSK both of them are used. In this work we focus on the Outh mode. Thus our object of analysis is an authenticated public key encryption scheme or short APKE. Let's take a look at the syntax of APKE. We have two roles, a sender and a receiver and both of them need a long-term key pair identified by S or R in the subscript. Encryption takes a sender secret key, a receiver public key and a message and returns a cipher text. The cipher text is consumed by the authenticated encryption function alongside a receiver secret key and a sender public key. As a side remark, this might remind you of sign encryption literature and I mentioned that again one other time. The authenticated chem syntax looks similar. The encapsulation function takes a sender secret key and a receiver public key and returns an encapsulation cipher text and a shared secret key. The authenticated encapsulation function takes a receiver secret key, a sender public key and an encapsulation cipher text and returns the shared secret. In hybrid schemes that you might know already, the chem shared secret is often directly used as a symmetric encryption key. This is not the case in HPKE. There is an intermediate key schedule function that is used to derive a symmetric key and a nonce. This info variable over here can be set arbitrarily by the application. The key schedule is needed to support the secret export and the multi-shot APIs of HPKE. Now we have seen all ingredients necessary to understand the generic construction of APKE. The authenticated encryption function takes a sender secret key, a receiver public key, a message and an info bit string. It uses the authenticated chem to generate a shared secret, then computes key and nonce using the key schedule and finally encrypts the message using a symmetric encryption scheme. The APKE cipher text consists of the ACAM encapsulation cipher text and the symmetric encryption cipher text. As an overview, here is what we prove in this work. We prove that the specific authenticated chem instantiation of the standard provides certain security guarantees. We prove that the key schedule is a pseudo random function and we prove composition theorems saying that given an authenticated chem with certain security properties, the ACAM dem construction we see here provides certain security properties. Now let's discuss what these security properties are. We prove two kinds of properties. First chosen cipher text indistinguishability, which covers confidentiality of chem encapsulations and PKE cipher texts. And second, authenticity, which covers unforgeability of chem encapsulations and PKE cipher texts. In the following, we will dive into the security games for APKE and ACAM. Let's begin with confidentiality for APKE. We set up the game with N honest key pairs, which means we consider a multi key notion. Also we choose a random secret bit B. The adversary gets access to an encryption and a decryption oracle. For the encryption oracle, it can choose the index of an honest sender key pair, then an arbitrary receiver public key and a message. The oracle returns the cipher text computed by the encryption function. For the decryption oracle, the adversary can choose an arbitrary sender public key and the index of an honest receiver key pair and the cipher text. The oracle refuses to query if the cipher text was produced by the encryption oracle. Otherwise, it returns the plain text computed by the decryption function. The challenge oracle for what we call outsider CCA is as follows. The adversary chooses the indices of an honest sender and receiver key pair and two equal length plain text M0 and M1. The oracle encrypts MB and returns the cipher text. The adversary wins if it guesses the secret bit B correctly. Again outsider CCA might remind some of you of the scientific literature and in the paper we discuss the relation. Outsider CCA is called like this because no honest key pair is compromised in this scenario. So the adversary is an outsider. For insider CCA we let the adversary choose the sender secret key SK. Likewise the adversary wins if it guesses the secret bit B correctly. Insider CCA is a stronger security notion than one where we would only allow to compromise some of the honestly generated keys. Also our security notions are adaptive in the sense that the adversary is allowed to make multiple calls to the oracles in any order. So what we have here are confidentiality or semantic security expressed as left or right indistinguishability game. For authentication the setup and the encryption and decryption oracles are the same. For the outsider out security notion we let the adversary choose indices for honest sender and receiver key pairs and submit a cipher text. The adversary wins if the cipher text was not produced by the encryption oracle and it decrypts correctly for the chosen key pair. For insider out the adversary chooses an honest sender key pair and an arbitrary receiver secret key. It submits a cipher text and wins if the cipher text was not produced by the encryption oracle and decrypts correctly under the submitted key pair. Insider out covers key compromise impersonation. Morally the security notions for the authenticated chem are very similar but because the chem as we define it generates the shared secret internally and returns it they look a bit different than the notions for APKE. So let's look at them. For outsider CCA we give the adversary access to an encapsulation and a decapsulation oracle. For encapsulation it chooses the honest sender's key pair index and an arbitrary public key. For decapsulation the adversary chooses an arbitrary sender public key and the receiver's key pair index and submits an encapsulation cipher text. The encapsulation oracle returns the pair of encapsulation cipher text and shared secret. In the ideal version of the game the shared secret is replaced by a fresh random value. The decapsulation oracle returns the result of the decapsulation function but if C was produced by the encapsulation oracle it will return whatever K the encapsulation oracle returned to be consistent. The adversary wins if it can distinguish between the real and the random slash ideal version of the game. Intuitively this expresses that the adversary cannot decide if C and K belong together. Said differently cipher texts between honest key pairs are secure in that they do not leak any information about this shared secret. For the insider CCA notion we expose a challenge oracle such that the adversary can choose the sender's secret key and here it is the challenge oracle that will replace the shared secret by a random value in the ideal version. And again the adversary wins if it can distinguish real and ideal version. For outside our authentication we want to express that the adversary cannot forge a cipher text between two honest key pairs. We express this by having the decapsulation oracle replace the shared secret by a fresh random value being consistent with the encapsulation oracle. So the adversary could detect this change if it was actually be able to forge a cipher text. We could define an insider out notion in the same spirit however we did not do so because of two reasons A the specific instantiation of the ACAM in the HPKE standard has an attack against insider authentication because it is vulnerable to key compromise impersonation. And B the generic APKE construction is vulnerable to an attack against insider authentication. So even if we had an ACAM that is insider out secure this would not fix the problem in APKE. With these security notions in mind we can understand the three composition theorems that we prove in this work. For outside a CCA and inside a CCA the theorem is as follows. If the authenticated key encapsulation mechanism is outsider or insider's ECA secure respectively and the key schedule is a PRF and the data encapsulation mechanism is in CPA and in CTXT secure then the authenticated public key encryption scheme is outsider or insider secure respectively. For outsider out the theorem actually requires that the ACAM is outsider out and outsider CCA secure and here too the key schedule needs to be a PRF and the DEM needs to be in CTXT such that the authenticated public key encryption scheme is outsider out secure. For the details on the attack on insider out I'd like to refer you to the paper. I just want to say here that this attack is a reason why HPKE's out mode is not suitable for use in the MLS standard because MLS requires security against key compromise impersonation. Now we have these composition theorems. Let's continue the work to achieve security guarantees for the specific instantiations presented at the HPKE standard. The authenticated CAM is instantiated by a Diffie-Hellman based construction using either one of the three prime order NIST curves P256, P384 or P521 or curve 25549 or curve 448. Let's look at it in the setting of prime order groups. Secret keys are drawn uniformly at random from Z modulo PZ without zero and public keys are computed by a raising the generator to the power of the secret key. The authenticated encapsulation function creates an ephemeral key pair and sets its encapsulation ciphertext to its public key. Then it sets a variable called context to the concatenation of the public values that we like to have bound to this encapsulation and a variable DH to the concatenation of the static ephemeral and the static static Diffie-Hellman operation result. Finally the CAM shared secret is computed by applying a key derivation function to the context and the Diffie-Hellman. The decapsulation function uses the equivalent Diffie-Hellman operations to derive the same shared secret. Now why the first elliptic curves here are prime order groups, curve 25549 and curve 448 are actually not prime order groups. In particular for each honestly generated public key they have a small number of equivalent public keys that will lead to the same Diffie-Hellman shared secret. So if you want to avoid identity misbinding or unknown key share attacks with these curves it is vital to put the public keys explicitly in the context of the key derivation just as we saw for the HACAM. We have shown this in a previous work on the wire guard VPN protocol for which we developed a fine-grained model of curve 25549 and curve 448. For this work on HPKE we did not want to do the proofs three times to cover all three kinds of curves. So instead we developed a model that covers all of them at the same time. We call this model nominal groups and we look at it in more detail now. First a short summary if in nominal groups we do not assume a group structure but only an exponentiation function with certain properties. Okay and now for the details. A nominal group N consists of a finite set of elements g, a base element small g and efficiently computable exponentiation function x from g cross z to g and we write x to the y for x of x comma y and finally two finite sets the set of honest exponents EH and the exponents EU both subsets of z. The exponentiation function needs to have certain properties. First we need that x to the y to the z is equal to x to the y times z and that's basically correctness for the Diffie-Hellman operation. Then the discrete logarithm must be unique in the set EU. That's needed to define a meaningful Diffie-Hellman oracle and the U in EU stands for unique discrete logarithm and finally we call a nominal group rerandomizable if rerandomization preserves the distribution of public keys for secret keys that have been chosen in EU. Let's look at an interesting parameter of nominal groups. So first let DH be the uniform distribution on the honestly generated exponents and DU the uniform distribution on EU. Then delta n is defined as the statistical distance between these two distributions. If we look at the values delta n for the five candidate groups we see that the prime order groups have delta n equals zero because there is no difference between these two distributions. However for curve 25549 and curve 448 there is one and this will show up in the security bounds because for each on a secret key we need to add a delta n to the adversary advantage when we pass from EH to EU to use the gap Diffie-Hellman assumption. For the exact definition of gap Diffie-Hellman and square gap Diffie-Hellman for rerandomizable nominal groups please have a look at the long version of the paper on e-print as we made some updates recently. The theorems we prove about the Diffie-Hellman based authenticated chem are as follows. So we prove outsider and insider CCA security assuming gap Diffie-Hellman in the elliptic curves as rerandomizable nominal groups and by modeling the key duration function H as a random oracle. For outsider out we need the square gap Diffie-Hellman assumption. Please have a look at the paper for the exact security bounds of these three theorems. Putting all these pieces together we can look at the exact security of the HPKE scheme in the standard. The standard offers algorithm choices with different security levels for the elliptic curves, the hash functions and the symmetric encryption. Here it is noteworthy that while different key sizes are offered for the symmetric key the length of the authentication tag is always fixed at 128 bit. In our proofs we find that this indeed limits the overall security level of HPKE to a maximum of 128 bit regardless of if an elliptic curve or a hash function with a higher security level has been chosen. Also current results on multi-key security of AAD schemes like AES128GCM are not sufficient to actually guarantee this security level of 128 bits. There is more research needed on this front. Towards the end a note on how we wrote our proofs. For most proofs we use the proof assistant called CryptoVerif which is developed at Inria Paris. It is a proof assistant for game based or code based proofs. On a high level what you would do is to express the initial security game in the programming language of CryptoVerif and then indicate the game transformations. CryptoVerif would apply them if it's sound and write the intermediate games for you and it can then finally prove security properties like secrecy, authentication and indistinguishability properties. CryptoVerif has a built-in proof strategy to find a suitable next transformations and can also be guided in detail which we did for this work. If the proof concludes we have asymptotic security and CryptoVerif also computes exact security bounds as a formula depending on the number of queries to oracles, the runtime of the adversary and the length of inputs. Some more notes on CryptoVerif. First, assumptions have to be expressed in multi-instance versions. For example, a proof of two user security implying any user security cannot be expressed in CryptoVerif. However, this can also be seen as a notch because in this work we found that we actually achieve better security bounds when we directly start with a multi-user notion. There are other limitations in CryptoVerif which I will not detail now, but let me just say that CryptoVerif can go as far to treat large real-world protocols as SSH, TLS and WireGuard in detail as they are. And if that makes you want to learn CryptoVerif a bit more, Bruno and me recorded a CryptoVerif tutorial during the very Crypt Workshop of IndoCrup 2020. The video and the examples are available at cryptoverif.inrea.fr slash tutorial. To conclude, we prove that HPK is out-mode satisfies its desired security properties. We prove composition theorems for outside a CCA, inside a CCA and outside or out of the ACAM-DEM construction. We have handwritten proofs that the single user to user security notions of ACAM imply their multi-user security notion. This closes the gap to security proofs of, for example, post-quantum camps that are usually only analyzed in a single user or two user setting. We prove that HPK's key schedule is a PRF and we prove that HPK's DH, ACAM is outside a CCA, inside a CCA and outside or out secure. And finally, as a contribution which with interest beyond this HPKE analysis, we introduce re-randomizable nominal groups to cover prime-order groups and non-prime-order groups in a single model. And to repeat it once more, spread the word, Curve25519 is not a prime-order group. So that's all I have for this talk. You'll find the paper and the cryptoverif models online. The links are indicated on this last slide. And please feel free to contact me and my co-authors by email. And thank you very much for listening.