]> Your Organization Here

rlb@ipv.sx

SEC HPKE Publication, Kept Efficient hybrid public key encryption hpke post-quantum Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post-quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attack by a quantum computer. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the HPKE Publication, Kept Efficient mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction A cryptographically relevant quantum computer may or may not exist as of this writing. The conventional wisdom, however, is that if one does not already, then it likely will within the lifetime of information that is cryptographically protected today. Such a computer would have the ability to infer decapsulation keys from encapsulation keys used for traditional KEMs, e.g., KEMs based on Diffie-Hellman over finite fields or elliptic curves. And it would be able to do this not just for data encrypted after the creation of the computer, but also for any information observed by the attacker previously, and stored for later decryption. This is the so-called "harvest now, decrypt later" attack. It is thus a high priority for many organizations right not to migrate key exchange technologies to use "post-quantum" (PQ) algorithms, which are resistant to attack by a quantum computer . Since these PQ algorithms are relatively new, there is also interest in hybrid constructions combining PQ algorithms with traditional KEMs, so that if the PQ algorithm fails, then the traditional algorithm will still provide security, at least against classical attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme . It is the foundation of the Messaging Layer Security (MLS) protocol, the Oblivious HTTP protocol, and the TLS Encrypted ClientHello extension . This document defines a collection of PQ and PQ/T KEM algorithms for HPKE, which allows HPKE to provide post-quantum security, as discussed in :

• ML-KEM-768
• ML-KEM-1024
• X25519 + ML-KEM-768
• P-256 + ML-KEM-768
• P-384 + ML-KEM-1024

ML-KEM, X25519, and P-256/P-384 are defined in , , and , respectively. This selection of KEM algorithms was chosen to provide a reasonably consolidated set of algorithms (in the interest of broad interoperability), while still allowing HPKE users flexibility along a few axes:

• Pure PQ vs. PQ/T hybrid
• CFRG-defined vs. NIST-defined elliptic curves
• Different security levels (NIST category 3 vs. category 5)

We also define HPKE KDF algorithms based on the SHA-3 family of hash functions. SHA-3 is used internally to ML-KEM, and so it could be convenient for HPKE users using the KEM algorithms in this document to rely solely on SHA-3.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. We generally use the terminology defined in the HPKE specification . There are two meanings of "hybrid" in this document. In the context of "hybrid public key encryption", it refers to the combination of an asymmetric KEM operaiton and a symmetric AEAD operation. In the context of "PQ/T hybrid", refers to the combination of PQ and traditional KEMs. For clarity, we always use "HPKE" for the former, and "PQ/T hybrid" for the latter.

ML-KEM The NIST Module-Lattice-Based Key-Encapsulation Mechanism is defined in . In this section, we define how to implement the HPKE KEM interface using ML-KEM. The HPKE DeriveKeyPair() function corresponds to the function ML-KEM.KeyGen_internal() in . The input ikm MUST be exactly Nsk = 64 bytes long. The d and z inputs to ML-KEM.KeyGen_internal() are the first and last 32-byte segments of ikm, respectively. The output skX is the generated decapsulation key and the output pkX is the generated encapsulation key. The GenerateKeyPair() function is simply DeriveKeyPair() with a pseudorandom ikm value. As long as the bytes supplied by random() meet the randomness requirements of , this corresponds to the ML-KEM.KeyGen() function, with the distinction that the decapsulation key is returned in seed format rather than the expanded form returned by ML-KEM.KeyGen(). The SerializePublicKey() and DeserializePublicKey() functions are both the identity function, since the ML-KEM already uses fixed-length byte strings for public encapsulation keys. The length of the byte string is determined by the ML-KEM parameter set in use. The Encap() function corresponds to the function ML-KEM.Encaps() in , where an ML-KEM encapsulation key check failure causes an HPKE EncapError. The Decap() function corresponds to the function ML-KEM.Decaps() in , an ML-KEM ciphertext check failure, decapsulation key check failure, or hash check failure cause an HPKE DecapError. To be explicit, we derive the expanded decapsulation key from the 64-byte seed format and invoke ML-KEM.Decaps() with it: The AuthEncap() and AuthDecap() functions are not implemented. The constants Nsecret and Nsk are always 32 and 64, respectively. The constants Nenc and Npk depend on the ML-KEM parameter set in use; they are specified in .

Hybrids of ML-KEM with DH [[ TODO: DH + ML-KEM, in appropriate combinations ]] [[ TODO: Decide whether to use DHKEM, or use DH directly ]] [[ TODO: Define HPKE API methods for the combination ]]

SHA-3 as an HPKE KDF [[ TODO: Defer until draft-ietf-hpke-hpke has a suitable definition ]]

Selection of AEAD algorithms As discussed in , the advent of quantum computers does not necessarily require changes in the AEAD algorithms used in HPKE. However, some compliance regimes call for the use of AEAD algorithms with longer key lengths, for example, the AES-256-GCM or ChaCha20Poly1305 algorithms registered for HPKE instead of AES-128-GCM.

Security Considerations As discussed in the HPKE Security Considerations, HPKE is an IND-CCA2 secure public-key encryption scheme if the KEM it uses is IND-CCA2 secure. It follows that HPKE is IND-CCA2 secure against a quantum attacker if it uses a KEM that provides IND-CCA2 security against a quantum attacker, i.e., a PQ KEM. The KEM algorithms defined in this document provide this level of security. ML-KEM itself is IND-CCA2 secure, and the IND-CCA2 security of the hybrid constructions used in this document is established in . [[ TODO: Binding properties ]]

IANA Considerations This section requests that IANA perform three actions:

1. Update the entries in HPKE KEM Identifiers registry corresponding to ML-KEM algorithms.
2. Add entries to the HPKE KEM Identifiers registry for the PQ/T hybrid KEMs defined in this document.
3. Add entries to the HPKE KDF Identifiers registry for the SHA-3 KDFs defined in this document.

Updated ML-KEM KEM Entries IANA should replace the entries in the HPKE KEM Identifiers registry for values 0x0040, 0x0041, and 0x0042 with the following values: Updated ML-KEM entries for the HPKE KEM Identifiers table

Value	KEM	Nsecret	Nenc	Npk	Nsk	Auth	Reference
0x0040	ML-KEM-512	32	768	800	64	no	RFCXXXX
0x0041	ML-KEM-768	32	1088	1184	64	no	RFCXXXX
0x0042	ML-KEM-1024	32	1568	1568	64	no	RFCXXXX

The only change being made is to update the "Reference" column to refer to this document.

PQ/T Hybrid KEM Entries [[ TODO: Register KEM values ]]

SHA-3 KDF Entries [[ TODO: Register KDF values ]]

References Normative References National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) Cisco Inria Inria Apple This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. SandboxAQ This document defines generic techniques to achive hybrid post- quantum/traditional (PQ/T) key encapsulation mechanisms (KEMs) from post-quantum and traditional component algorithms that meet specified security properties. It then uses those generic techniques to construct several concrete instances of hybrid KEMs. Informative References Nokia Nokia Nokia DigiCert Entrust Limited The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public-key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), detailing the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. Independent Fastly Cryptography Consulting LLC Cloudflare This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni).

Acknowledgments TODO acknowledge.