]> 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 generator g is the standard base point defined in Section 3.2.1 of . 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 seed, 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 .

Given a seed, the RandomScalar algorithm is defined as follows: = order: start = end end = end + Nscalar if end > len(seed): raise Exception("Rejection sampling failed") sk = OS2IP(seed[start : end]) return sk ]]> RandomScalar fails with cryptographically negligible probability, as long as the input seed is uniformly random. (The chance of a single rejection is < 2^-32 for P-256 and < 2^-192 for P-384. The chance of more than Nreject rejections is thus < 2^-128 for P-256 and < 2^-192 for P-384.) 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:

128

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 generator g for the Curve25519 nominal group is the value 9, represented as a 32-byte little-endian integer, as defined in Section 4.1 of . 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 the identity function, i.e., by returning the seed.

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() -> (dk, ek):

Implemented as KeyGen in Section 7.1 of .

DeriveKeyPair(seed) -> (dk, ek):

Implemented as KeyGen_internal(seed[0:32], seed[32:64]), where KeyGen_internal is defined in Section 6 of .

Encaps(ek) -> (ss, ct):

Implemented as Encaps in Section 7.2 of .

Decaps(dk, ct) -> ss:

Implemented as Decaps in Section 7.3 of .

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

Nseed:

64

Nek:

1184

Ndk:

64

Nct:

1088

Nss:

32

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

Nseed:

64

Nek:

1568

Ndk:

64

Nct:

1568

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 implicit 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: MLKEM768-P256 (hex: 4d4c4b454d3736382d50323536)

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

Nseed:

32

Nek:

1249

Ndk:

32

Nct:

1153

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: \.//^\ (hex: 5C2E2F2F5E5C)

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: MLKEM1024-P384 (hex: 4d4c4b454d313032342d50333834)

The following constants for the hybrid KEM are also defined:

Nseed:

32

Nek:

1665

Ndk:

32

Nct:

1665

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
"MLKEM768-P256"	CG	ML-KEM-768	P-256	SHA3-256	SHAKE-256	32	32	[RFCXXXX]
"\.//^\"	CG	ML-KEM-768	Curve25519	SHA3-256	SHAKE-256	32	32	[RFCXXXX]
"MLKEM1024-P384"	CG	ML-KEM-1024	P-384	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. This document specifies the syntax and semantics for conveying Elliptic Curve (EC) private key information. The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG). This document is not an Internet Standards Track specification; it is published for informational purposes.

Deterministic Encapsulation Deterministic encapsulation allows for testing encapsulation as well as decapsulation. defines deterministic encapsulation for a hybrid KEM when it is supported by the constituent algorithms. The nominal groups and KEMs defined in this document all support deterministic encapsulation. As noted in , nominal groups all support deterministic encapsulation with Nrandom = Nseed. For ML-KEM, the EncapsDerand() function is implemented as Encaps_internal in Section 6.2 of , with Nrandom = 32.

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

The seed and randomness values are opaque random values, as are the decapsulation_key and shared_secret fields (as defined by the hybrid KEM specifications). The encapsulation_key and ciphertext fields reflect the concatenated encapsulation keys and ciphertexts (in (PQ, T) order) called for in the hybrid KEM specifications. The decapsulation_key_pq values are ML-KEM expanded private keys in the format defined by . The decapsulation_key_t values for X25519 are simply opaque 32-byte strings. The decapsulation_key_t values for the NIST curves are big-endian integers reflecting the private scalar value for the private key. This format is identical to the privateKey value used in the PKCS#8 format for private keys .

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. Thanks to Mike Ounsworth, Bas Westerbaan, and Chris Patton for independent validation of the test vectors.