]> SandboxAQ

durumcrustulum@gmail.com

Cisco

rlb@ipv.sx

IRTF Crypto Forum post quantum kem PQ hpke hybrid encryption 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. 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 Crypto Forum Research Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction 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. Such KEMs are secure against a quantum attacker as long as the PQ algorithm is secure, and remain secure against traditional attackers even if the PQ algorithm is not secure. defines a general framework for creating hybrid KEMs. It includes multiple specific mechanisms for combining a PQ algorithm with a traditional algorithm, with different performance properties and security requirements for the underlying algorithms. In this document, we describe instances of these different specific combiners, with specific choices for the underlying algorithms. The choices described here illustrate the security analysis required to make choices that meet the requirements of the general framework, and can serve as a baseline for application designers. We also provide test vectors for these instances so that implementors can verify the correctness of their implementations.

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 make extensive use of the terminology in .

Concrete Nominal Group and KEM Instances This document introduces concrete hybrid KEM instances that in turn depend on concrete KEM and nominal group instances. This section introduces the nominal groups and KEM instances used for concrete hybrid KEM instances, specified in line with the abstraction from . defines the concrete nominal groups, and defines the nominal KEMs.

Nominal Groups This section specifies concrete nominal groups that implement the abstraction in . It includes groups based on the NIST curves P-256 and P-384, as well as a group based on Curve25519.

P-256 and P-384 Nominal Groups The NIST P-256 and P-384 elliptic curves are defined in . They are widely used for key agreement and digital signature. In this section, we define how they meet the Nominal Group interface described in . Group elements are elliptic curve points, represented as byte strings in the uncompressed representation defined by the Elliptic-Curve-Point-to-Octet-String function in . Scalars are represented as integers in big-endian byte order. The Nominal Group algorithms are the same for both groups:

• Exp(p, x) -> q: This function computes scalar multiplication between the input element (or point) p and the scalar x, according to the group law for the curve specified in .
• RandomScalar(seed) -> k: Implemented using rejection sampling from a PRG, as described below.
• ElementToSharedSecret(p) -> ss: The shared secret is the X coordinate of the elliptic curve point p, encoded as an Nss-byte string using the Field-Element-to-Octet-String function in .

The RandomScalar algorithm depends on an pseudo-random generator (PRG), with the following API:

• Init(seed) -> state: Initialize a new state of the pseudo-random generator based on the provided seed.
• Read(state, n) -> data: Read n pseudo-random bytes from the PRG, updating state to reflect that this read has happened.

A hybrid KEM using these curves MUST specify the PRG that should be used. All of the hybrid KEMs in this document use SHAKE256 . Given a PRG, the RandomScalar algorithm is defined as follows: = order: sk = OS2IP(XOF.Read(state, Nscalar)) return (sk, pk(sk)) ]]> The OS2IP function converts a byte string to a non-negative integer, as described in , assuming big-endian byte order. The order variable represents the order of the curve being used (see Section 3.2.1 of ), reproduced here for reference: The group constants for the P-256 group are as follows:

• Nseed: 32
• Nscalar: 32
• Nelem: 65
• Nss: 32

The group constants for the P-384 group are as follows:

• Nseed: 48
• Nscalar: 48
• Nelem: 97
• Nss: 48

Curve25519 Nominal Group The following functions for the Curve25519 nominal group are defined:

• Exp(p, x) -> q: Implemented by X25519(x, p) from .
• RandomScalar(seed) -> k: Implemented by sampling and outputting 32 random bytes from a cryptographically secure pseudorandom number generator.
• ElementToSharedSecret(p) -> ss: Implemented by the identity function, i.e., by outputting P.

The following constants are also defined.

• Nseed: 32
• Nscalar: 32
• Nelem: 32
• Nss: 32

Concrete KEM Instances This section specifies concrete KEM instances that implement the KEM abstraction from .

ML-KEM-768 and ML-KEM-1024 The ML-KEM-768 and ML-KEM-1024 KEMs are defined in . The algorithms defined in that specification map to the KEM abstraction in as follows:

• GenerateKeyPair() -> (ek, dk): Implemented as KeyGen in Section 7.1 of .
• DeriveKeyPair(seed) -> (ek, dk): Implemented as KeyGen_internal(seed[0:32], seed[32:64]), where KeyGen_internal is defined in Section 6 of .
• Encaps(ek) -> (ct, ss): Implemented as Encaps in Section 7.2 of .
• Decaps(dk, ct) -> ss: Implemented as Encaps in Section 7.3 of .

The KEM constants for ML-KEM-768 are as follows:

• Nseed: 64
• Nek: 1216
• Ndk: 32
• Nct: 1120
• Nss: 32

The KEM constants for ML-KEM-1024 are as follows:

• Nseed: 64
• Nek: 1629
• Ndk: 32
• Nct: 1629
• Nss: 32

Concrete PRG instances This section specifies concrete PRG instances that implement the PRG abstraction from and meet the required security definitions.

SHAKE256 SHAKE256 is an extendable-output function (XOF) defined in the SHA-3 specification . It can be used as a PRG for arbitrary values of Nout. When SHAKE256 is used as the PRG component in a hybrid KEM, it is implcit that Nout == KEM_T.Nseed + KEM_PQ.Nseed or Nout == Group_T.Nseed + KEM_PQ.Nseed as appropriate.

Concrete KDF instances This section specifies concrete KDF instances that implement the KDF abstraction from and meet the required security definitions.

SHA-3 The SHA-3 hash function is defined in . It produces a 32-byte output, so it is appropriate for use in hybrid KEMs with Nss = 32.

Concrete Hybrid KEM Instances This section instantiates the following concrete KEMs:

MLKEM768-P256:

A hybrid KEM composing ML-KEM-768 and P-256 using the CG framework, with SHAKE256 as the PRG and SHA3-256 as the KDF.

MLKEM768-X25519:

A hybrid KEM composing ML-KEM-768 and Curve25519 using the CG framework, with SHAKE256 as the PRG and SHA3-256 as the KDF. This construction is identical to the X-Wing construction in .

MLKEM1024-P384:

A hybrid KEM composing ML-KEM-1024 and P-384 using the CG framework, with SHAKE256 as the PRG and SHA3-256 as the KDF.

Each instance specifies the PQ and traditional KEMs being combined, the combiner construction from , the label to use for domain separation in the combiner function, as well as the PRG and KDF functions to use throughout.

MLKEM768-P256 This hybrid KEM combines ML-KEM-768 with P-256 using the CG framework from . It has the following components:

• Group_T: P-256
• KEM_PQ: ML-KEM-768
• PRG: SHAKE-256
• KDF: SHA3-256
• Label: |-()-| (0x7C2D28292D7C)

The KEM constants for the resulting hybrid KEM are as follows:

• Nseed: 32
• Nek: 1217
• Ndk: 32
• Nct: 1121
• Nss: 32

MLKEM768-X25519 This hybrid KEM combines ML-KEM-768 with X25519 using the CG framework from . It is identical to the X-Wing construction from . It has the following components:

• KEM_PQ: ML-KEM-768
• Group_T: Curve25519
• PRG: SHAKE-256
• KDF: SHA3-256
• Label: \.//^\ (0x5C2E2F2F5E5C)

The following constants for the hybrid KEM are also defined:

• Nseed: 32
• Nek: 1216
• Ndk: 32
• Nct: 1120
• Nss: 32

MLKEM1024-P384 This hybrid KEM combines ML-KEM-1024 with P-384 using the CG framework from . It has the following components:

• Group_T: P-384
• `KEM_PQ: ML-KEM-1024
• PRG: SHAKE-256
• KDF: SHA3-256
• Label: ` | /-` (0x207C202F2D5C)

The following constants for the hybrid KEM are also defined:

• Nseed: 32
• Nek: 1629
• Ndk: 32
• Nct: 1629
• Nss: 32

Security Considerations The Security Considerations section in generic hybrid KEM framework lays out the requirements for component algorithms in order for a hybrid KEM constructed according to the framework to be secure . In brief:

• A nominal group needs to be one in which the Strong Diffie-Hellman problem is hard.
• A KEM need to be IND-CCA secure.
• When the C2PRI combiner is used (as it is here), the PQ KEM also needs to satisfy the C2PRI property.
• KDFs need to be indifferentiable from a random oracle, even by a quantum attacker.
• A PRG needs to be a secure pseudo-random generator

The components used in this document meet these requirements:

• The security of X25519, P-256, and P-384 as nominal groups is shown in .
• ML-KEM is shown to be IND-CCA in and shown to be C2PRI in .
• The sponge construction used by SHA3-256 is shown to be indifferentiable from a random oracle by a classical attacker in . Indifferentiability with respect to quantum attackers is shown in .
• Since SHAKE256 is built on the same sponge construction as SHA3-256, it is also indifferentiable from a random oracle, which is a sufficient condition for being a secure pseudorandom generator.

IANA Considerations This document requests that the following values be added to the "Hybrid KEM Labels" registry: Hybrid KEM Labels

Label	Fw	PQ Component	T Component	KDF	PRG	Nseed	Nss	Reference
"|-()-|"	CG	ML-KEM-768	Curve25519	SHA3-256	SHAKE-256	32	32	[RFCXXXX]
"\.//^\"	CG	ML-KEM-768	Curve25519	SHA3-256	SHAKE-256	32	32	[RFCXXXX]
" | /-\"	CG	ML-KEM-768	Curve25519	SHA3-256	SHAKE-256	32	32	[RFCXXXX]

[ RFC EDITOR: Please replace "XXXX" above with the number assigned to this RFC ]

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 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. 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. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. 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. Informative References ANSI SandboxAQ MPI-SP & Radboud University Cloudflare This memo defines X-Wing, a general-purpose post-quantum/traditional hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML- KEM-768. CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security n.d.

Test Vectors This section provides test vectors for the three concrete hybrid KEM instantiations defined in this document. Each test vector represents a single key generation followed by an encapsulation:

• seed - the seed used for deterministic key generation
• decapsulation_key - the derived decapsulation key
• decapsulation_key_pq - the decapsulation key sub-key for the PQ component
• decapsulation_key_t - the decapsulation key sub-key for the T component
• encapsulation_key - the derived encapsulation key
• randomness - the randomness used for encapsulation
• ciphertext - the ciphertext produced by the encapsulation operation
• shared_secret - the shared secret produced by the encapsulation operation

MLKEM768-P256

MLKEM768-X25519

MLKEM1024-P384

Acknowledgments Thanks to Chris Wood and Britta Hale for contributions to early versions of this document. Thanks to Filippo Valsorda for the ASCII art labels for the non-X-Wing hybrid KEMs.