HQC (Hamming Quasi-Cyclic)
HQC is the code-based key-encapsulation mechanism that NIST selected on March 11, 2025 as the fifth post-quantum algorithm in its portfolio and the designated backup to ML-KEM. Its full name is Hamming Quasi-Cyclic, and its security rests on the difficulty of decoding a random-looking error-correcting code, a foundation completely separate from the lattice math behind the primary standard. NIST chose it for exactly that separation: if lattice cryptography were ever weakened, HQC would be unaffected, so the encryption side of the transition keeps a second, independent line of defense. It’s selected but not yet finalized, which makes it an algorithm to design for and track, not one to deploy broadly today.
Source: NIST, “NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption,” March 11, 2025.
The short version:
- HQC is a code-based KEM. It does key establishment (agreeing on a shared secret), the same job as ML-KEM, and it leaves signatures to the signature standards.
- NIST selected it on March 11, 2025 as the fifth post-quantum algorithm and the explicit backup to ML-KEM.
- Its whole strategic point is mathematical diversity: it rests on the hardness of decoding error-correcting codes, not on lattices, so a future break in lattice cryptography wouldn’t reach it.
- It’s larger than ML-KEM, with public keys roughly four times the size and ciphertexts several times larger, so the cost lands on bandwidth and protocol handling.
- It’s selected, not finalized. A draft standard is expected around 2026 and a final standard around 2027, so the move is to track it and keep it on the roadmap while you deploy ML-KEM now.
Picture a scratched CD that still plays every song. The disc wraps the music in extra redundancy so the player can reconstruct it even after some bits are lost or flipped, and that redundancy is an error-correcting code. Correcting those errors is easy when you hold the code’s hidden structure and genuinely hard when you don’t. HQC turns that gap into a lock. You publish a scrambled code that looks like random noise, and to send you a secret, someone deliberately garbles a message with a controlled burst of errors. Anyone can add the errors. Only you, holding the private structure, can strip them out and recover what’s underneath, and a quantum computer gives an attacker no shortcut through that.
What is HQC?
HQC (Hamming Quasi-Cyclic) is a key-encapsulation mechanism from the code-based family of post-quantum cryptography, standardized by NIST as the backup to ML-KEM on the encryption side of the transition. The identity in one card:
- Full name: Hamming Quasi-Cyclic.
- Common shorthand: HQC.
- Type: key-encapsulation mechanism (key establishment), not a signature scheme.
- Family: code-based cryptography, built on the Quasi-Cyclic Syndrome Decoding problem.
- Standards body: NIST, selected March 11, 2025 as the fifth post-quantum algorithm.
- Status: selected for standardization; draft standard expected around 2026, final around 2027.
- Role: the non-lattice backup to ML-KEM, chosen for mathematical diversity.
Source: NIST, March 11, 2025; NIST IR 8545, Status Report on the Fourth Round of the NIST PQC Standardization Process, March 2025.
What problem does HQC solve?
HQC solves the same problem every KEM solves: it lets two parties establish a shared secret over an untrusted channel, so that traffic can then be protected with fast symmetric encryption. One party publishes a public key, the other uses it to encapsulate a fresh secret into a ciphertext, and the key owner decapsulates that ciphertext to recover the same secret. That shared secret feeds ordinary symmetric cryptography and key derivation, exactly the downstream flow of any other KEM.
The specific problem HQC exists to hedge is concentration risk. The primary NIST standard for key establishment, ML-KEM, is lattice-based, and so is the primary signature standard. Betting the entire confidentiality future on one family of mathematical assumptions is efficient and also a single point of failure. HQC gives the portfolio a second, independent foundation for the same job, so a bad day for lattice math wouldn’t force an organization to re-migrate its key establishment from scratch. It solves confidentiality and key establishment only. It does nothing for authentication, certificates, or code signing, which belong to the signature standards.
What cryptographic family is HQC?
HQC belongs to code-based cryptography, and its security is associated with the hardness of the Quasi-Cyclic Syndrome Decoding (QCSD) problem. Decoding a random linear error-correcting code is a problem mathematicians have studied since the 1970s, the general version is NP-hard, and there’s still no known efficient way to solve it on either a classical or a quantum computer. HQC uses quasi-cyclic codes, which give it a compact algebraic structure that keeps its keys far smaller than the founding code-based scheme, Classic McEliece, while keeping the decoding problem hard.
Source: HQC official specification site, which states HQC’s security derives from the hardness of solving the Quasi-Cyclic Syndrome Decoding problem.
That foundation is the entire reason HQC exists in the portfolio. It has nothing to do with factoring or discrete logarithms, so Shor’s algorithm, which demolishes RSA and elliptic-curve cryptography, has nothing to attack. It has nothing to do with lattices either, so whatever advance might one day weaken ML-KEM leaves HQC untouched. Grover’s algorithm offers only the generic quadratic speedup on brute-force search, and the parameter sizes already absorb it.
Why did NIST choose HQC as a backup to ML-KEM?
NIST chose HQC because it wanted a serious encryption standard built on a different mathematical foundation than ML-KEM, so that a single cryptanalytic breakthrough couldn’t compromise both. NIST stated the reasoning plainly on selection: “We want to have a backup standard that is based on a different math approach than ML-KEM,” and “as we advance our understanding of future quantum computers and adapt to emerging cryptanalysis techniques, it’s essential to have a fallback in case ML-KEM proves to be vulnerable.”
Source: NIST, March 11, 2025.
HQC was the survivor of a dedicated fourth round of the standardization process, which studied four code-based and isogeny-based key-establishment candidates: BIKE, Classic McEliece, HQC, and SIKE. NIST’s fourth-round report is unambiguous about the outcome: “The only key-establishment algorithm that will be standardized is HQC, and NIST will develop a standard based on HQC to augment its key-establishment portfolio.” SIKE was withdrawn after it was broken by a classical computer, and NIST didn’t advance BIKE or Classic McEliece to standardization, which left HQC as the code-based KEM with the balance of maturity, security confidence, and workable sizes that NIST wanted for a deployable backup.
Source: NIST IR 8545, March 2025.
This is the same instinct that drives crypto-agility. You deploy the finalized default now, and you keep an independent second option ready for the question every mature program eventually asks: what happens if the assumption underneath our primary standard turns out to be weaker than we thought?
What does HQC replace?
HQC replaces the classical key-establishment algorithms, the same ones ML-KEM replaces, in the specific role of a non-lattice alternative. Those classical algorithms are:
- ECDH, the elliptic-curve key exchange behind most modern TLS handshakes.
- finite-field Diffie-Hellman, the older key-exchange method.
- Legacy RSA key transport, where RSA is used to establish a session key.
All three are broken by a cryptographically relevant quantum computer running Shor’s algorithm, which is why they need a quantum-safe successor at all. HQC does not replace signatures. It has no bearing on ECDSA, RSA signatures, certificate signing, firmware signing, or code signing, which are the job of ML-DSA, SLH-DSA, and their siblings. In practice HQC isn’t the first-choice replacement even for key establishment. It’s the backup you reach for when a program deliberately wants a second, non-lattice family in place, rather than the default first move.
What are HQC’s parameter sets and sizes?
The HQC specification defines three parameter sets, targeting NIST security categories 1, 3, and 5. The figures below are from the HQC specification; NIST’s final standard may adjust them, since parameters are sometimes tuned during standardization, so treat these as the current reference rather than final FIPS values.
| Parameter set | NIST security category | Public key | Secret key | Ciphertext |
|---|---|---|---|---|
| HQC-128 | Category 1 | 2,241 bytes | 2,321 bytes | 4,433 bytes |
| HQC-192 | Category 3 | 4,514 bytes | 4,602 bytes | 8,978 bytes |
| HQC-256 | Category 5 | 7,237 bytes | 7,333 bytes | 14,421 bytes |
Source: HQC official specification site.
The number to internalize is the scale, not the exact bytes. Even at the lowest security level, an HQC public key runs a couple of kilobytes and its ciphertext runs several kilobytes, which is where the engineering cost lives. The compute is not the constraint; the size on the wire is.
How does HQC compare to ML-KEM?
HQC and ML-KEM do the same job from different mathematics, and the practical difference is size. ML-KEM is the smaller, finalized default you deploy now; HQC is the larger, code-based backup you keep on the roadmap for diversity. Comparing the two at a similar security level makes the tradeoff concrete:
| Property | ML-KEM | HQC |
|---|---|---|
| Math family | Lattice-based (Module-LWE) | Code-based (Quasi-Cyclic Syndrome Decoding) |
| Role in the portfolio | Primary, finalized default | Backup, for mathematical diversity |
| Status | Finalized in FIPS 203, August 2024 | Selected March 2025; draft ~2026, final ~2027 |
| Public key (Category 3) | 1,184 bytes | 4,514 bytes |
| Ciphertext (Category 3) | 1,088 bytes | 8,978 bytes |
| Best use today | Deploy now as the default KEM | Track and design for; a Phase 2 diversity option |
Sources: ML-KEM sizes from FIPS 203, August 2024; HQC sizes from the HQC specification site; status from NIST, March 11, 2025.
At a comparable security level, HQC’s public key is roughly four times ML-KEM’s and its ciphertext is several times larger. Those extra bytes are the price of independence, and they land on bandwidth, protocol message limits, and storage rather than on CPU. For a program that wants a second family that a lattice break can’t reach, that’s a price worth planning for; for a first move, ML-KEM’s smaller, finalized profile is why it deploys first.
What is HQC’s status and timeline?
HQC is selected for standardization but not yet finalized, which is the single most important thing to state correctly about it. NIST announced the selection on March 11, 2025 and said a draft standard would follow in about a year, with a final standard expected in 2027 after public comment.
| Milestone | When |
|---|---|
| Selected as the fifth PQC algorithm and ML-KEM backup | March 11, 2025 |
| Draft standard expected | About a year from selection, around 2026 |
| Final standard expected | 2027, after public comment |
Source: NIST, March 11, 2025.
The correct reading of that status has three parts. HQC is not finalized, so it isn’t a FIPS you can point a compliance requirement at yet. It’s not the current deployment default, so it should never be a reason to delay migrating to ML-KEM. And it is a genuinely selected, standards-track algorithm worth tracking closely and building crypto-agility around, so a code-based option can slot in when the standard lands. That’s the difference between “wait for HQC” (wrong) and “design so HQC can be added later” (right).
What does tracking HQC actually look like?
For nearly every program, HQC is a Phase 2 consideration rather than a first move, and the practical work around it is architectural, not a deployment. That means:
- Deploy ML-KEM now. ML-KEM is the finalized default, and it’s what closes the harvest-now-decrypt-later exposure today. HQC’s existence changes none of that urgency.
- Build for a second family. Crypto-agility is what lets you add or swap a KEM without re-plumbing everything, so a code-based backup can be introduced when its standard is final.
- Follow the standard, not the draft. Early library support may reflect pre-standard or draft-era conventions, so anything built against HQC before the final FIPS should be treated as provisional and revisited when the standard settles.
The honest framing is that HQC matters right now for roadmap and architecture decisions, and it matters later for deployment. Reading “NIST selected it” as “wait for it before starting” gets the sequencing exactly backward.
Common misconceptions
“HQC is the new default KEM.” The finalized default for key establishment is ML-KEM, and that’s what most programs deploy first. HQC is the selected backup, valued for diversity, and its existence should never delay an ML-KEM migration.
“HQC replaces ML-KEM.” NIST positioned HQC as a backup to ML-KEM, not a replacement. Both are KEMs, but they serve different roles: ML-KEM is the primary line, HQC is the independent second family held in reserve.
“HQC is already a standard I can require.” HQC is selected but not finalized. A draft standard is expected around 2026 and a final one around 2027, so treating it as an existing FIPS the way you’d treat FIPS 203 is a factual error.
Source: NIST, March 11, 2025.
“HQC’s big keys mean it’s less secure.” The larger public key and ciphertext are a deployment cost, not a weakness. They reflect the code-based family’s size profile, and they buy the very thing HQC exists for, a foundation independent of lattices.
“Post-quantum means signatures, so HQC handles those too.” HQC does key establishment only. It solves the confidentiality half of the transition and does nothing for authentication, certificates, or code signing, which belong to the signature standards.
Questions people ask
Is HQC finalized? No. NIST selected HQC on March 11, 2025, but the standard isn’t final. A draft is expected around 2026 and a final standard around 2027 after public comment. Until then it’s an algorithm to track and design for, not one to deploy broadly.
Should I wait for HQC before migrating? No, and that’s the most common sequencing mistake. Deploy ML-KEM now, because it’s the finalized default that addresses the harvest-now-decrypt-later problem today. Keep HQC on the roadmap as a diversity option to add later.
Why did NIST pick HQC over Classic McEliece or BIKE? Of the fourth-round key-establishment candidates, NIST chose to standardize only HQC. Classic McEliece has extremely large public keys that don’t fit most protocols, BIKE wasn’t advanced, and SIKE was broken and withdrawn, which left HQC as the code-based KEM with the workable balance of security confidence and size.
How much bigger is HQC than ML-KEM? At a comparable security level (NIST Category 3), HQC’s public key is about 4,514 bytes against ML-KEM’s 1,184, and its ciphertext is about 8,978 bytes against 1,088, so roughly four times the key and several times the ciphertext. The cost lands on bandwidth and protocol handling, while the compute stays cheap.
Does HQC replace ML-KEM in TLS? Not as a default. ML-KEM is what’s going into TLS now, typically as a hybrid key exchange alongside a classical algorithm. HQC is a backup family to have available if the lattice assumption behind ML-KEM ever needs reinforcement, not the primary handshake choice.
Can HQC do digital signatures? No. HQC is a key-encapsulation mechanism, so it handles key establishment and confidentiality only. Signatures are the job of ML-DSA, SLH-DSA, and FN-DSA.
What is HQC’s security based on? The Quasi-Cyclic Syndrome Decoding problem, a code-based hardness assumption completely separate from the lattice math behind ML-KEM. Decoding a random-looking error-correcting code has no known efficient solution on a classical or a quantum computer, which is the ground HQC stands on.
Where does HQC fit in a migration plan? It’s a Phase 2 diversity option. The first-move work is deploying ML-KEM and building crypto-agility so a second, non-lattice KEM can be added cleanly. HQC slots into that architecture once its standard is final.
HQC is the code-based backup you keep on the roadmap so that a single bad day for lattice math isn’t a bad day for your whole estate. Everything here is the map, given freely. When your team needs to decide where a code-based backup actually belongs in your protocols and estate, that’s what an alignment briefing is for.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.