HQC

HQC (Hamming Quasi-Cyclic) is a code-based key-encapsulation mechanism selected by NIST on March 11, 2025 as the fifth algorithm of the PQC standardization process. It is intended as a backup to ML-KEM: a standardized alternative whose security rests on error-correcting codes rather than lattices.

#Why NIST wanted a non-lattice KEM

ML-KEM, ML-DSA, and FN-DSA all build on lattice-based cryptography. That concentration is a portfolio risk: a single mathematical breakthrough against structured lattice problems would strike the primary KEM and the primary signature at once. The process had already seen two mature schemes fall to unexpected classical attacks (Rainbow in February 2022 and SIKE in mid 2022), so NIST kept a fourth evaluation round running specifically to pick a KEM on different foundations. HQC won that round; the reasoning is documented in NIST IR 8545. NIST's guidance is explicit that ML-KEM remains the recommended default and HQC exists as insurance.

#How it works

HQC encrypts by hiding a message inside deliberately corrupted codewords. Security reduces to the hardness of decoding random quasi-cyclic linear codes in the Hamming metric (a syndrome decoding problem), which has resisted decades of cryptanalysis and gains only limited speedup from a quantum computer via Grover's algorithm-style search.

Two design choices distinguish HQC within code-based cryptography. First, unlike McEliece-style schemes, it does not need to hide the structure of a decodable code in the public key; decryption uses a fixed, public concatenated code (Reed-Muller combined with Reed-Solomon), so the security assumption is cleaner. Second, its decryption failure rate can be analyzed rigorously and set below the threshold needed for chosen-ciphertext security. That analyzability was a deciding factor against its closest competitor BIKE, whose failure-rate analysis NIST judged less mature. Like ML-KEM, HQC wraps an IND-CPA encryption core in a Fujisaki-Okamoto style transform to reach IND-CCA2 security as a KEM.

#Parameters and sizes

HQC trades bandwidth for its different security basis: keys and ciphertexts are several times larger than ML-KEM's, and operations are slower, though still practical (sub-millisecond to a few milliseconds on desktop processors). Sizes below are in bytes, from the fourth-round specification at pqc-hqc.org; the exact figures for the final standard could shift slightly during drafting.

For comparison, ML-KEM public keys run 800 to 1568 bytes; full tables are in post-quantum algorithm comparison.

#Standardization timeline

At selection, NIST projected a draft standard about a year out and a final standard in 2027, so the working expectation is a draft around 2026 and a finished FIPS around 2027. Until then, HQC deployments track the fourth-round specification, and early adoption is mostly experimental, including availability in liboqs. Hybrid deployment alongside classical key exchange follows the same logic as for ML-KEM; see hybrid cryptography.

#BIKE and Classic McEliece

HQC's selection closed the fourth round, and the fates of the other candidates explain its role:

• SIKE was withdrawn after a classical key-recovery attack in 2022.
• BIKE, also a quasi-cyclic code-based KEM with sizes similar to HQC, was not selected; NIST cited greater residual uncertainty in its decryption failure analysis, which matters for chosen-ciphertext security.
• Classic McEliece, based on the oldest code-based assumption (1978) and widely viewed as extremely conservative, was not standardized by NIST: its public keys run from roughly 261 kilobytes to over 1 megabyte, which NIST judged impractical for general Internet use. NIST noted that interested parties can follow its separate standardization track at ISO.

The outcome leaves the NIST portfolio with two KEMs on independent mathematical foundations, which is exactly the diversity the fourth round was designed to buy.