]> Cisco

rlb@ipv.sx

Selkie Cryptography

durumcrustulum@gmail.com

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 attacks 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 now 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 post-quantum/traditional (PQ/T) KEM algorithms for HPKE, which allows HPKE to provide post-quantum security, as discussed in :

• ML-KEM-512
• 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 operation 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 uses the SHAKE256 KDF (see ) to derive an ML-KEM decapsulation key in the 64-byte seed format, then uses the function ML-KEM.KeyGen_internal from to compute the corresponding encapsulation key. As discussed in , the value of suite_id used within LabeledDerive identifies the KEM in use:

• ML-KEM-512: KEM\x00\x40 (hex: 4b454d0040)
• ML-KEM-768: KEM\x00\x41 (hex: 4b454d0041)
• ML-KEM-1024: KEM\x00\x42 (hex: 4b454d0042)

The GenerateKeyPair function simply calls ML-KEM.KeyGen_internal with a pseudorandom dk 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, DeserializePublicKey, SerializePrivateKey, and DeserializePrivateKey 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 , where any of an ML-KEM ciphertext check failure, decapsulation key check failure, or hash check failure causes 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 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 .

Hybrid KEMs with ECDH and ML-KEM defines a collection of concrete PQ/T hybrid KEMs. These KEMs combine ML-KEM with a traditional ECDH group:

MLKEM768-P256:

ML-KEM-768 and P-256

MLKEM768-X25519:

ML-KEM-768 and X25519

MLKEM1024-P384:

ML-KEM-1024 and P-384

These KEMs satisfy the KEM interface defined in . This interface maps to the KEM interface in in the following way:

• The HPKE DeriveKeyPair function uses the SHAKE256 KDF (see ) to derive a 32-byte seed for the hybrid KEM, then uses the function DeriveKeyPair from to compute the key pair for the hybrid KEM. The input to this function SHOULD be at least 32 bytes long.

• The GenerateKeyPair, Encap, and Decap algorithms are identical.
• The SerializePublicKey, DeserializePublicKey, SerializePrivateKey, and DeserializePrivateKey algorithms are the identity, since encapsulation and decapsulation keys are already fixed-length byte strings.
• The constants map as follows:
  • Nsecret = Nss
  • Nenc = Nct
  • Npk = Nek
  • Nsk = Ndk

As discussed in , the value of suite_id used within LabeledDerive identifies the KEM in use:

• MLKEM768-P256: KEM\x00\x50 (hex: 4b454d0050)
• MLKEM768-X25519: KEM\x64\x7a (hex: 4b454d647a)
• MLKEM1024-P384: KEM\x00\x51 (hex: 4b454d0051)

Single-Stage KDFs This section defines HPKE KDFs for eXtendable Output Functions (XOF) based on Keccak. SHAKE is defined as part of the SHA-3 specification . The related TurboSHAKE XOFs are defined in . The Derive() function for SHAKE is as follows, where <SIZE> is either 128 or 256: .Derive(ikm, L): return SHAKE(M = ikm, d = 8*L) ]]> The Derive() function for TurboSHAKE is as follows, where <SIZE> is either 128 or 256: .Derive(ikm, L): return TurboSHAKE(M = ikm, D = 0x1f, L) ]]> The Nh values for the KDFs defined in this section are listed in . Single-Stage KDF IDs

Value	KDF	Nh	Two-Stage	Reference
0x0010	SHAKE128	32	N	RFC XXXX
0x0011	SHAKE256	64	N	RFC XXXX
0x0012	TurboSHAKE128	32	N	RFC XXXX
0x0013	TurboSHAKE256	64	N	RFC XXXX

[[ RFC EDITOR: Please change "XXXX" above to the RFC number assigned to this document. ]]

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-CCA secure. It follows that HPKE is IND-CCA2 secure against a quantum attacker if it uses a KEM that provides IND-CCA 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-CCA secure, and the IND-CCA security of the hybrid constructions used in this document is established in . Another security property that is salient in some use cases is "key binding". In , these notions are referred to with the shorthand X-BIND-P-Q. The most salient for protocol design provide assurances similar to those provided by transcript hashing in protocols like TLS:

LEAK-BIND-K-PK:

If the sender and receiver have the same key (K, shared_secret above), then there is only one encapsulation key (PK, pk) that could have produced it, even if the decapsulation key is leaked to an attacker after the encryption has been done.

LEAK-BIND-K-CT:

If the sender and receiver have the same key (K, shared_secret above), then there is only one KEM ciphertext (CT, enc) that could have produced it, even if the decapsulation key is leaked to an attacker after the encryption has been done.

DHKEM and ML-KEM meet these properties, as shown in . The hybrid KEMs used in this document also provide these properties, as discussed in .

PQ Hybrid vs. Pure PQ Assuming that ML-KEM is secure, either the PQ/T hybrid KEMs defined in or the pure PQ KEMs defined in provide security against a quantum attacker. Hybrid KEMs can be used to provide security against a non-quantum attacker in the event of failures with regard to the PQ algorithm, including both implementation flaws as well as new cryptanalysis. See for further analysis of hybrid security properties.

Asymmetric-Key-Authenticated Modes of RFC9180 In the version of HPKE, KEMs could optionally define the additional functions AuthEncap and AuthDecap. These functions allowed a sender to authenticate the message to the recipient without interaction. The KEMs defined in this document do not support AuthEncap/AuthDecap and cannot be used to migrate uses of HPKE that rely on this mode. PSK-authenticated HPKE () or digital signatures may be suitable alternatives.

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 is requested to 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 IANA is requested to replace the entry for the value 0x647a and add two entries for values 0x0050 and 0x0051 with the following values: PQ/T hybrid entries for the HPKE KEM Identifiers table

Value	KEM	Nsecret	Nenc	Npk	Nsk	Auth	Reference
0x0050	MLKEM768-P256	32	1153	1249	32	no	RFCXXXX
0x0051	MLKEM1024-P384	32	1665	1665	32	no	RFCXXXX
0x647a	MLKEM768-X25519	32	1120	1216	32	no	RFCXXXX

SHA-3 KDF Entries IANA is requested to add the values listed in to the HPKE KDF Identifiers registry.

References Normative References National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) SandboxAQ Cisco University of Michigan This document defines generic constructions for hybrid Key Encapsulation Mechanisms (KEMs) based on combining a post-quantum (PQ) KEM with a traditional cryptographic component. Hybrid KEMs built using these constructions provide strong security properties as long as either of the underlying algorithms are secure. SandboxAQ Cisco PQ/T Hybrid Key Encapsulation Mechanisms (KEMs) combine "post- quantum" cryptographic algorithms, which are safe from attack by a quantum computer, with "traditional" algorithms, which are not. CFRG has developed a general framework for creating hybrid KEMs. In this document, we define concrete instantiations of this framework to illustrate certain properties of the framework and simplify implementors' choices. Cisco Inria Inria 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 a variant that authenticates possession of a pre-shared key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. 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 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. ABN AMRO Bank zkSecurity STMicroelectronics National Institute of Standards and Technology Radboud University This document defines four eXtendable Output Functions (XOF), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128 and KT256. All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way. This document is a product of the Crypto Forum Research Group. It builds up on the definitions of the permutations and of the sponge construction in [FIPS 202], and is meant to serve as a stable reference and an implementation guide. 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. CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security 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). 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.

Test Vectors Each section below contains test vectors for a single selection of HPKE algorithms and contains the following values:

1. Configuration information and private key material: This includes the mode, info string, HPKE ciphersuite identifiers (kem_id, kdf_id, aead_id), and all sender and recipient key material. For each role S or R, (sender and recipient, respectively) key pairs are generated as (skX, pkX) = DeriveKeyPair(ikmX). Each key pair (skX, pkX) is written in its serialized form, where skXm = SerializePrivateKey(skX) and pkXm = SerializePublicKey(pkX). For the PSK mode, the shared PSK and PSK identifier are also included.
2. Context creation intermediate values: This includes the KEM outputs enc and shared_secret used to create the context, as well as the context values key, base_nonce, and exporter_secret.
3. Encryption test vectors: A fixed plaintext message is encrypted using different sequence numbers and AAD values using the context computed in (2). Each test vector lists the sequence number and corresponding nonce computed with base_nonce, the plaintext message pt, AAD aad, and output ciphertext ct.
4. Export test vectors: Several exported values of the same length with differing context parameters are computed using the context computed in (2). Each test vector lists the exporter_context, output length L, and resulting export value.

These test vectors are also available in JSON format at .

ML-KEM-768, HKDF-SHA256, AES-128-GCM

Base Setup Information

Encryptions

Exported Values

ML-KEM-1024, HKDF-SHA384, AES-256-GCM

Base Setup Information

Encryptions

Exported Values

QSF-P256-MLKEM768, Unknown KDF, AES-128-GCM

Base Setup Information

Encryptions

Exported Values

QSF-X25519-MLKEM768, HKDF-SHA256, AES-128-GCM

Base Setup Information

Encryptions

Exported Values

QSF-X25519-MLKEM768, Unknown KDF, AES-128-GCM

Base Setup Information

Encryptions

Exported Values

QSF-P384-MLKEM1024, Unknown KDF, AES-256-GCM

Base Setup Information

Encryptions

Exported Values