Hamming Quasi-Cyclic (HQC) Key Encapsulation Mechanisms for Hybrid Public Key Encryption (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 17 April 2027.¶

Copyright Notice

Copyright (c) 2026 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

Hybrid Public Key Encryption (HPKE) [HPKE] combines a key encapsulation mechanism (KEM), a key derivation function (KDF), and an authenticated encryption with associated data (AEAD) algorithm. Its KEM interface allows additional algorithms to be specified independently of an application protocol.¶

This document adds HQC to that interface. HQC offers a code-based alternative to the lattice-based ML-KEM mechanisms specified for HPKE in [PQ-HPKE]. NIST selected HQC for standardization following its fourth-round evaluation [NIST.IR.8545].¶

This document specifies three standalone HQC KEMs and three PQ/T hybrid KEMs: HQC3-P256, HQC3-X25519, and HQC5-P384. The hybrid KEMs combine HQC with an elliptic-curve group using the framework of [GENERIC]. The standalone KEMs provide security against quantum attackers as long as HQC remains secure. The hybrid KEMs additionally provide security against classical attackers as long as either component remains secure. The word "hybrid" in HPKE refers to its public-key and symmetric construction. The term "PQ/T hybrid" is used as defined in [RFC9794].¶

This specification does not change the HPKE key schedule or message encryption.¶

2. Conventions and Terminology

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

The notation and interfaces of [HPKE] apply. All lengths below are in octets unless stated otherwise. || denotes byte-string concatenation. Quoted strings in pseudocode denote ASCII byte strings, and "" denotes an empty byte string.¶

pk denotes an encoded public encapsulation key. sk denotes the private seed representation defined in this document. expanded_sk denotes an internal HQC decapsulation key. enc is the complete HQC KEM ciphertext, and shared_secret is the KEM output supplied to HPKE. kem_id is the assigned two-octet HPKE KEM identifier.¶

3. HQC KEMs for HPKE

ExpandSeed(seed):
    Require length(seed) == 32
    Run HQC-KEM.Keygen for the selected parameter set,
        with seedKEM set to seed instead of sampling it.
    Return (dkKEM, ekKEM) as (expanded_sk, pk).

def GenerateKeyPair():
    sk = random(32)
    (_expanded_sk, pk) = ExpandSeed(sk)
    return (sk, pk)

suite_id = "KEM" || I2OSP(kem_id, 2)

def DeriveKeyPair(ikm):
    sk = SHAKE256.LabeledDerive(ikm, "DeriveKeyPair", "", 32)
    (_expanded_sk, pk) = ExpandSeed(sk)
    return (sk, pk)

def Encap(pkR):
    Check the length and encoding of pkR for the selected KEM.
    (K, cKEM) = HQC-KEM.Encaps(pkR)
    return (K, cKEM)

def Decap(enc, skR):
    Require length(enc) == Nenc
    Require length(skR) == 32
    (expanded_sk, _pkR) = ExpandSeed(skR)
    return HQC-KEM.Decaps(expanded_sk, enc)

4. PQ/T Hybrid KEMs

This section defines three PQ/T hybrid KEMs that combine HQC with an elliptic-curve group: HQC3-P256, HQC3-X25519, and HQC5-P384. Each instantiates the C2PRI Combiner with a Nominal Group (CG) framework of Section 5.5 of [GENERIC].¶

C2PRI denotes ciphertext second-preimage resistance: given an honestly generated ciphertext, it is infeasible to find a different ciphertext that decapsulates to the same shared secret. The CG framework relies on this property of the PQ component. Its combiner hashes the traditional ciphertext and public key but not the PQ ciphertext or public key, which avoids hashing the large HQC values in every operation. HQC provides C2PRI through the re-encryption check in HQC-KEM.Decaps (Section 3.6 of [HQC]). [CHH25] proves this property, and Section 6.1.2 of [GENERIC] lists HQC among the KEMs that have it.¶

[CONCRETE] instantiates [GENERIC] only for ML-KEM. This document therefore instantiates [GENERIC] directly for HQC. Each hybrid KEM uses the same framework, PRG function, and KDF as the ML-KEM hybrids in [CONCRETE], and the same nominal group as its ML-KEM counterpart: HQC3-P256 as MLKEM768-P256, HQC3-X25519 as MLKEM768-X25519, and HQC5-P384 as MLKEM1024-P384.¶

Each hybrid KEM uses the following components:¶

• KEM_PQ: HQC-3 or HQC-5, as defined in Section 3. KEM_PQ.DeriveKeyPair(seed) is ExpandSeed(seed) of Section 3.2, with Nseed equal to 32.¶

• Group_T: a nominal group of Section 3.1 of [CONCRETE].¶

• PRG: SHAKE256 [FIPS202].¶

• KDF: SHA3-256 [FIPS202].¶

• Label: an ASCII string that identifies the hybrid KEM.¶

The functions GenerateKeyPair, DeriveKeyPair, Encaps, and Decaps of each hybrid KEM are those of Sections 5.2 and 5.5 of [GENERIC], instantiated with its components.¶

The hybrid KEMs have the following constants, in octets:¶

Nseed is 32 for each hybrid KEM, as for the ML-KEM hybrids in [CONCRETE]. The PRG expands the seed to the length required by the components.¶

Each hybrid KEM maps to the HPKE KEM interface as follows:¶

• DeriveKeyPair derives a 32-octet seed with the SHAKE256 KDF of Section 5 of [PQ-HPKE] and then applies the DeriveKeyPair function of the hybrid KEM:¶

def DeriveKeyPair(ikm):
    seed = SHAKE256.LabeledDerive(ikm, "DeriveKeyPair", "", 32)
    return KEM_H.DeriveKeyPair(seed)

• GenerateKeyPair, Encap, and Decap are the GenerateKeyPair, Encaps, and Decaps functions of the hybrid KEM.¶

• SerializePublicKey and SerializePrivateKey return the key unchanged. The public key is ek_PQ || ek_T, and the private key is the seed.¶

• DeserializePublicKey and DeserializePrivateKey reject input whose length is not Npk or Nsk, respectively, with DeserializeError, and otherwise return the input unchanged.¶

• Nsecret is Nss, Nenc is Nct, Npk is Nek, and Nsk is Ndk.¶

The suite_id used in LabeledDerive is "KEM" || I2OSP(kem_id, 2), where kem_id is the value assigned to each hybrid KEM.¶

5. HPKE Modes and Ciphersuites

These KEMs can be used with the Base and PSK modes of [HPKE]. HPKE's setup, encryption, sequence-number handling, and export procedures apply unchanged. The KDF and AEAD are selected independently subject to the security requirements of Sections 9.3 and 9.4 of [HPKE].¶

The SHAKE256 KDF in [PQ-HPKE] can also be used for the HPKE key schedule. HKDF-based ciphersuites remain possible. This document does not register a new KDF or AEAD or mandate a single application ciphersuite.¶

The AuthEncap and AuthDecap interfaces of RFC 9180 are not defined for these KEMs. The HPKE KEM registry's legacy Auth column is no. This does not prevent using the PSK mode, which is part of the HPKE key schedule rather than asymmetric sender authentication by the KEM.¶

A KEM identifier is a cryptographic parameter, not a complete message format. Applications remain responsible for selecting and conveying ciphersuites and for transporting enc and the HPKE ciphertext.¶

6. Security Considerations

The security considerations of [HQC], [HPKE], and [PQ-HPKE] apply. HQC provides mathematical diversity from ML-KEM, but selecting HQC alone does not provide the security of a combined hybrid KEM.¶

HPKE requires a CCA-secure KEM with the shared-secret properties specified in Section 9.2 of [HPKE]. This specification uses the complete HQC-KEM construction and its shared-secret output.¶

HQC-KEM derives its shared secret from H(ek), and an accepted ciphertext is uniquely determined by ek, m, and salt through re-encryption. HQC-KEM is therefore expected to provide LEAK-BIND-K-PK and LEAK-BIND-K-CT by the same argument as ML-KEM in [CDM23]. No published analysis covers this HQC revision.¶

The security of a complete ciphersuite is limited by its components, including any PSK and the KDF and AEAD. As discussed in Section 6 of [PQ-HPKE], the use of a post-quantum KEM does not by itself require a change of AEAD algorithm. However, some compliance regimes call for AEAD algorithms with longer keys, such as AES-256-GCM or ChaCha20Poly1305.¶

All secret randomness MUST come from a cryptographically secure source. The private seed is sufficient to reconstruct the entire private key and MUST receive the same protection as an expanded private key. Implementations SHOULD erase temporary secret material when no longer needed and SHOULD use constant-time implementations for secret-dependent computations. They MUST preserve implicit rejection and avoid exposing secret-dependent behavior through timing, logs, or error handling.¶

Recipient public keys require authenticated distribution appropriate to the application. Base mode does not authenticate the sender. Long-term recipient key compromise permits decapsulation of recorded messages; this construction does not provide forward secrecy against that compromise. PSK selection and handling follow [HPKE].¶

The domain separator in Section 3.4 prevents accidental equivalence of key derivations between KEM identifiers, but does not authorize seed or ikm reuse across protocols. Implementations MUST enforce the selected parameter set and MUST NOT retry with a different KEM or older HQC revision when input validation or decryption fails.¶

HQC's public keys and ciphertexts impose substantial per-recipient message overhead. Applications SHOULD bound allocation and processing before performing expensive cryptographic operations. Transport, fragmentation, reassembly, and total message-size limits need to account for the values in Table 1 and Table 3.¶

7. IANA Considerations

8. References

Authors' Addresses