| Internet-Draft | concrete-hybrid-kems | July 2025 |
| Connolly & Barnes | Expires 8 January 2026 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://cfrg.github.io/draft-irtf-cfrg-concrete-hybrid-kems/draft-irtf-cfrg-concrete-hybrid-kems.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-irtf-cfrg-concrete-hybrid-kems/.¶
Discussion of this document takes place on the Crypto Forum Research Group mailing list (mailto:cfrg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=cfrg. Subscribe at https://www.ietf.org/mailman/listinfo/cfrg/.¶
Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 January 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
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.¶
[HYBRID-KEMS] 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
We make extensive use of the terminology in [HYBRID-KEMS].¶
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 [HYBRID-KEMS]. Section 3.1 defines the concrete nominal groups, and Section 3.2 defines the nominal KEMs.¶
This section specifies concrete nominal groups that implement the abstraction in [HYBRID-KEMS]. It includes groups based on the NIST curves P-256 and P-384, as well as a group based on Curve25519.¶
The NIST P-256 and P-384 elliptic curves are defined in [SP800-186]. They are widely used for key agreement and digital signature. In this section, we define how they meet the Nominal Group interface described in [HYBRID-KEMS].¶
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 [SEC1].¶
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 [SP800-186].¶
RandomScalar(seed) -> k: Implemented by converting seed to an integer
using the Octet-String-to-Integer function in [SEC1], 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 [SEC1].¶
The group constants for the P-256 group are as follows:¶
The group constants for the P-384 group are as follows:¶
The following functions for the Curve25519 nominal group are defined:¶
Exp(p, x) -> q: Implemented by X25519(x, p) from [RFC7748].¶
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.¶
This section specifies concrete KEM instances that implement the KEM abstraction from [HYBRID-KEMS].¶
The ML-KEM-768 and ML-KEM-1024 KEMs are defined in [FIPS203]. The algorithms defined in that specification map to the KEM abstraction in [HYBRID-KEMS] as follows:¶
GenerateKeyPair() -> (ek, dk): Implemented as KeyGen in Section 7.1 of
[FIPS203].¶
DeriveKeyPair(seed) -> (ek, dk): Implemented as
KeyGen_internal(seed[0:32], seed[32:64]), where KeyGen_internal is defined
in Section 6 of [FIPS203].¶
Encaps(ek) -> (ct, ss): Implemented as Encaps in Section 7.2 of
[FIPS203].¶
Decaps(dk, ct) -> ss: Implemented as Encaps in Section 7.3 of
[FIPS203].¶
The KEM constants for ML-KEM-768 are as follows:¶
The KEM constants for ML-KEM-1024 are as follows:¶
This section specifies concrete PRG instances that implement the PRG abstraction from [HYBRID-KEMS] and meet the required security definitions.¶
SHAKE256 is an extendable-output function (XOF) defined in the SHA-3
specification [FIPS202]. 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.¶
This section specifies concrete KDF instances that implement the KDF abstraction from [HYBRID-KEMS] and meet the required security definitions.¶
This section instantiates the following concrete KEMs:¶
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.¶
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 [XWING-SPEC].¶
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 [HYBRID-KEMS], the label to use for domain
separation in the combiner function, as well as the PRG and KDF functions to
use throughout.¶
This hybrid KEM is heavily based on [XWING], using the QSF combiner from [HYBRID-KEMS]. 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 Section 3.1.1¶
KEM_PQ: ML-KEM-768 Section 3.2.1¶
Label: QSF-P256-MLKEM768-SHAKE256-SHA3256¶
The KEM constants for the resulting hybrid KEM are as follows:¶
This hybrid KEM is identical to X-Wing [XWING-SPEC]. It has the following parameters.¶
Group_T: Curve25519 Section 3.1.2¶
KEM_PQ: ML-KEM-768 Section 3.2.1¶
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:¶
QSF-MLKEM1024-P384-SHA3256-SHAKE256 has the following parameters:¶
Group_T: P-384 Section 3.1.1¶
`KEM_PQ: ML-KEM-1024 Section 3.2.1¶
Label: QSF-P384-MLKEM1024-SHAKE256-SHA3256¶
The following constants for the hybrid KEM are also defined:¶
[[ TODO ]]¶
This document has no IANA actions.¶
[[ TODO ]]¶
[[ TODO ]]¶