]> Concrete Hybrid PQ/T Key Encapsulation Mechanisms 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 compressed representation defined by the Elliptic-Curve-Point-to-Octet-String function in . 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 by converting seed to an integer using the Octet-String-to-Integer function in , and then reducing the resulting integer modulo the group order.
  • 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 group constants for the P-256 group are as follows:
  • Nseed: 48
  • Nscalar: 32
  • Nelem: 33
  • Nss: 32
The group constants for the P-384 group are as follows:
  • Nseed: 72
  • Nscalar: 48
  • Nelem: 49
  • 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:
QSF-MLKEM768-P256-SHA3256-SHAKE256:
A hybrid KEM composing ML-KEM-768 and P-256 using the QSF scheme, with SHAKE256 as the PRG and SHA3-256 as the KDF.
QSF-MLKEM768-X25519-SHA3256-SHAKE256:
A hybrid KEM composing ML-KEM-768 and Curve25519 using the QSF scheme, with SHAKE256 as the PRG and SHA3-256 as the KDF. This construction is identical to the X-Wing construction in .
QSF-MLKEM1024-P384-SHA3256-SHAKE256:
A hybrid KEM composing ML-KEM-1024 and P-384 using the QSF scheme, 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.
QSF-MLKEM768-P256-SHA3256-SHAKE256 This hybrid KEM is heavily based on , using the QSF combiner from . In particular, it has the same exact design but uses P-256 instead of X25519 as the the traditional component of the algorithm. It has the following parameters.
  • Group_T: P-256
  • KEM_PQ: ML-KEM-768
  • PRG: SHAKE-256
  • KDF: SHA3-256
  • Label: QSF-P256-MLKEM768-SHAKE256-SHA3256
The KEM constants for the resulting hybrid KEM are as follows:
  • Nseed: 32
  • Nek: 1217
  • Ndk: 32
  • Nct: 1121
  • Nss: 32
QSF-MLKEM768-X25519-SHA3256-SHAKE256 This hybrid KEM is identical to X-Wing . It has the following parameters.
  • Group_T: Curve25519
  • KEM_PQ: ML-KEM-768
  • PRG: SHAKE-256
  • KDF: SHA3-256
  • Label: \.//^\
(This label does not follow the same pattern as the other KEMs here, but was chosen for compatibility with the X-Wing specification.) The following constants for the hybrid KEM are also defined:
  • Nseed: 32
  • Nek: 1216
  • Ndk: 32
  • Nct: 1120
  • Nss: 32
QSF-MLKEM1024-P384-SHA3256-SHAKE256 QSF-MLKEM1024-P384-SHA3256-SHAKE256 has the following parameters:
  • Group_T: P-384
  • `KEM_PQ: ML-KEM-1024
  • PRG: SHAKE-256
  • KDF: HKDF-SHA-256
  • Label: QSF-P384-MLKEM1024-SHAKE256-SHA3256
The following constants for the hybrid KEM are also defined:
  • Nseed: 32
  • Nek: 1629
  • Ndk: 32
  • Nct: 1629
  • Nss: 32
Security Considerations [[ TODO ]]
IANA Considerations This document has no IANA actions.
References Normative References SHA-3 standard :: permutation-based hash and extendable-output functions National Institute of Standards and Technology (U.S.) Module-lattice-based key-encapsulation mechanism standard National Institute of Standards and Technology (U.S.) Recommendations for Discrete Logarithm-based Cryptography:: Elliptic Curve Domain Parameters National Institute of Standards and Technology Hybrid PQ/T Key Encapsulation Mechanisms 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. Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Elliptic Curves for Security 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. HMAC-based Extract-and-Expand Key Derivation Function (HKDF) This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. Informative References Public Key Cryptography for the Financial Services Industry: the Elliptic Curve Digital Signature Algorithm (ECDSA) ANS Unbindable Kemmy Schmidt: ML-KEM is neither MAL-BIND-K-CT nor MAL-BIND-K-PK Elliptic Curve Cryptography, Standards for Efficient Cryptography Group, ver. 2 X-Wing: The Hybrid KEM You’ve Been Looking For X-Wing: general-purpose hybrid post-quantum KEM 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. Keeping Up with the KEMs: Stronger Security Notions for KEMs and automated analysis of KEM-based protocols CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security Binding Security of Implicitly-Rejecting KEMs and Application to BIKE and HQC n.d.
Test Vectors [[ TODO ]]
Acknowledgments [[ TODO ]]