Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE

Status of This Memo

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 19 December 2025.¶

Copyright Notice

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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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 [I-D.ietf-pquip-pqc-engineers]. 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 [I-D.barnes-hpke-hpke]. It is the foundation of the Messaging Layer Security (MLS) protocol, the Oblivious HTTP protocol, and the TLS Encrypted ClientHello extension [RFC9420] [RFC9458] [I-D.ietf-tls-esni].¶

This document defines a collection of PQ and PQ/T KEM algorithms for HPKE, which allows HPKE to provide post-quantum security, as discussed in Section 7:¶

• 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 [FIPS203], [RFC7748], and [FIPS186], 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.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

We generally use the terminology defined in the HPKE specification [I-D.barnes-hpke-hpke].¶

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 operaiton 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.¶

3. ML-KEM

The NIST Module-Lattice-Based Key-Encapsulation Mechanism is defined in [FIPS203]. In this section, we define how to implement the HPKE KEM interface using ML-KEM.¶

The HPKE DeriveKeyPair function corresponds to the function ML-KEM.KeyGen_internal in [FIPS203]. The input ikm MUST be exactly Nsk = 64 bytes long. The d and z inputs to ML-KEM.KeyGen_internal are the first and last 32-byte segments of ikm, respectively. The output skX is the generated decapsulation key and the output pkX is the generated encapsulation key.¶

def DeriveKeyPair(ikm):
    if len(ikm) != 64:
        raise DeriveKeyPairError

    d = ikm[:32]
    z = ikm[32:]

    dk = ikm
    (ek, _) = ML-KEM.KeyGen_internal(d, z)
    return (dk, ek)

The GenerateKeyPair function is simply DeriveKeyPair with a pseudorandom ikm value. As long as the bytes supplied by random meet the randomness requirements of [FIPS203], 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.¶

def GenerateKeyPair():
    dz = random(64)
    return DeriveKeyPair(dz)

The SerializePublicKey and DeserializePublicKey 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 [FIPS203], where an ML-KEM encapsulation key check failure causes an HPKE EncapError.¶

The Decap function corresponds to the function ML-KEM.Decaps in [FIPS203], 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:¶

def Decap(enc, skR):
    d = skR[:32]
    z = skR[32:]
    (_, dk) = ML-KEM.KeyGen_internal(d, z)
    return ML-KEM.Decaps(dk, enc)

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 Table 2.¶

4. Hybrid KEMs with ECDH and ML-KEM

The HNN3, HNN5, and HNX KEMs are defined in [CONCRETE]. These KEMs combine a traditional ECDH group with ML-KEM:¶

HNN3:

P-256 + ML-KEM-768¶

HNN5:

P-384 + ML-KEM-1024¶

HNX:

X25519 + ML-KEM-768¶

These KEMs satisfy the KEM interface defined in [I-D.irtf-cfrg-hybrid-kems]. This interface is mostly the same as the KEM interface in Section 4 of [I-D.ietf-hpke-hpke], with the following mapping:¶

• The GenerateKeyPair, DeriveKeyPair, and Encap and Decap algorithms are identical.¶

• The SerializePublicKey and DeserializePublicKey algorithms are the identity, since encapsulation keys are already fixed-length byte strings.¶

• The constants map as follows:¶

  • Nsecret = Nss¶

  • Nenc = Nct¶

  • Npk = Nek¶

  • Nsk = Ndk¶

5. Single-Stage KDFs

This section defines HPKE KDFs for three eXtendable Output Functions (XOF) based on Keccak. SHAKE is defined as part of the SHA-3 specification [FIPS202], and the related TurboSHAKE XOFs is defined in [I-D.irtf-cfrg-kangarootwelve].¶

The Nh values for the KDFs defined in this section are listed in Table 1. The Derive() functions for each XOF are as follows, where <SIZE> is either 128 or 256:¶

def SHAKE<SIZE>.Derive(ikm, L):
    return SHAKE<SIZE>(M = ikm, d = 8*L)

def TurboSHAKE<SIZE>.Derive(ikm, L):
    return TurboSHAKE<SIZE>(M = ikm, D = 0x1f, L)

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

6. Selection of AEAD algorithms

As discussed in Section 2.1 of [I-D.ietf-pquip-pqc-engineers], 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.¶

7. 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 [I-D.irtf-cfrg-hybrid-kems].¶

[[ TODO: Binding properties ]]¶

8. 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.¶

9. References

Author's Address