HQC

HQC (Hamming Quasi-Cyclic) is a code-based key-encapsulation mechanism that NIST selected on 2025-03-11 as a fourth-round selection — the fifth algorithm chosen for NIST PQC standardization overall — a code-based backup to ML-KEM, and the second KEM selected for standardization (after ML-KEM, and not finalized at the same time). It provides algorithm diversity — a backup whose security rests on coding theory rather than lattices — with moderate, practical key and ciphertext sizes. HQC has been selected for standardization, but no final FIPS standard has been published yet. Its FIPS number has not yet been assigned by NIST. A draft is projected roughly a year after selection and a final standard is expected around 2027; until then it remains a selected candidate, not a published standard.

How it works

HQC is a KEM built on the hardness of decoding in the Hamming metric using quasi-cyclic codes. Encapsulation adds a structured error to a codeword; recovering the message requires decoding that error, which is hard without the secret. HQC pairs an outer error-correcting code (for reliable decoding) with the quasi-cyclic structure (for compact keys), and applies a transform to reach IND-CCA2 security.

A key engineering advantage of HQC over some other code-based schemes is its clean, analyzable decoding-failure rate (DFR): the probability that decapsulation fails can be bounded tightly and made negligibly small, which simplifies security analysis and constant-time implementation.

Parameter sets

Three parameter sets target NIST categories 1, 3, and 5. Approximate sizes in bytes for the category-1 set are shown; higher levels scale up.

These are larger than ML-KEM but far more practical than Classic McEliece's hundred-kilobyte keys. The 64-byte shared secret in the table is the round-4 specification value; defer to the final NIST standard draft, as the final standard may adjust it slightly.

Strengths & tradeoffs

• Algorithm diversity. Code-based security gives a hedge against any future break of lattice assumptions, making HQC a natural backup or hybrid partner for ML-KEM.
• Clean DFR. The decoding-failure rate is well understood and easy to bound, which aids robust, constant-time implementations.
• Tradeoff: public keys and ciphertexts are noticeably larger than ML-KEM's, and performance is slower. It is a backup, not a wholesale replacement for ML-KEM.

When to use it

Use HQC when you want defense-in-depth against a lattice break: as the second component of a hybrid alongside ML-KEM, or as a primary KEM in environments that mandate non-lattice cryptography. For most performance-sensitive deployments where a single algorithm suffices, ML-KEM remains the default.

Code example

When using HQC as a backup or hybrid component, size your buffers, KDF inputs, and protocol fields according to the lengths exposed by the specific specification or library.

import oqs

kem = "HQC-128"
with oqs.KeyEncapsulation(kem) as server:
    public_key = server.generate_keypair()
    print("public key bytes:", len(public_key))  # ~2249

    with oqs.KeyEncapsulation(kem) as client:
        ciphertext, ss_c = client.encap_secret(public_key)
        print("ciphertext bytes:", len(ciphertext))  # ~4433

    ss_s = server.decap_secret(ciphertext)
    assert ss_c == ss_s

Related

Standards & references

• HQC project — official specification, reference code, and parameter sets.
• NIST PQC project — HQC selected for standardization as an additional KEM.
• Resources — full standards register