up:: KEM (Key Encapsulation Mechanism)
ML-KEM vs HQC
What is the difference between ML-KEM and HQC?
They perform the identical function on completely unrelated mathematics. ML-KEM is the finalized standard, built on lattices, and it is NIST’s general-purpose default. HQC is built on error-correcting codes, was selected in 2025 as a backup, is not yet finalized, and its keys and ciphertexts are several times larger. The size penalty is the price of a foundation that a break in lattice mathematics could not reach.
The short version:
- Both are key-encapsulation mechanisms, so both establish a shared secret and neither signs anything. Signatures are ML-DSA and its siblings.
- ML-KEM rests on lattices (Module-LWE); HQC rests on error-correcting codes (Quasi-Cyclic Syndrome Decoding). The two fields are unrelated, which is the entire reason both were standardized.
- ML-KEM is finalized in FIPS 203, August 2024. HQC was selected on March 11, 2025 and is not yet finalized, with a draft expected around 2026.
- At security category 3, HQC’s artifacts are several times larger: a 4,514-byte public key against 1,184, and an 8,978-byte ciphertext against 1,088.
- ML-KEM is the general-purpose default and HQC is the designated backup, held on an independent mathematical basis rather than as a stronger option.
What is ML-KEM?
ML-KEM is the key-encapsulation mechanism standardized in FIPS 203 in August 2024, known during the NIST competition as CRYSTALS-Kyber. It lets two parties agree on a shared secret across an untrusted network, which is the job ECDH does today and which Shor’s algorithm destroys.
Its security rests on the Module-LWE problem, a lattice assumption with no known efficient solution on a classical or a quantum computer. ML-KEM-768 is the parameter set NIST recommends as the general-purpose default, and it is the ML-KEM half of X25519MLKEM768, the hybrid key agreement the IETF standardized for TLS 1.3 and the one browsers and major TLS libraries negotiate today.
Sources: NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, §8, August 2024, for the recommended default: “NIST recommends using ML-KEM-768 as the default parameter set, as it provides a large security margin at a reasonable performance cost.” FIPS 203 says nothing about TLS, browsers or hybrid key exchange; for X25519MLKEM768 see K. Kwiatkowski, P. Kampanakis, B. E. Westerbaan, D. Stebila, “Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3,” RFC 10024, August 2026, rfc-editor.org.
What is HQC?
HQC, Hamming Quasi-Cyclic, is a key-encapsulation mechanism from the code-based family, selected by NIST on March 11, 2025 as the fifth post-quantum algorithm and the designated backup to ML-KEM.
It does the same key-establishment job on a different foundation: the hardness of decoding a random-looking error-correcting code, specifically Quasi-Cyclic Syndrome Decoding, rather than lattice mathematics. It is selected but not finalized, with a draft standard expected around 2026 and a final around 2027.
A naming note matters here. The current specification labels its parameter sets HQC-1, HQC-3 and HQC-5 for security categories 1, 3 and 5, while earlier NIST-round submissions used hqc-128, hqc-192 and hqc-256. HQC-192 and HQC-3 are the same category-3 parameter set.
ML-KEM vs HQC at a glance
Compared at NIST security category 3, the like-for-like tier, using ML-KEM-768 and HQC-192.
| Dimension | ML-KEM-768 | HQC-192 |
|---|---|---|
| Mathematical basis | Module-LWE, a lattice problem | Quasi-Cyclic Syndrome Decoding, a code problem |
| Standardization status | Finalized, FIPS 203, August 2024 | Selected March 11, 2025, not finalized. Draft expected ~2026, final ~2027 |
| Public key | 1,184 bytes | 4,514 bytes |
| Private key | 2,400 bytes | 4,602 bytes |
| Ciphertext | 1,088 bytes | 8,978 bytes |
| Security category | Category 3, anchored to an AES-192 search | Category 3 |
| Role in NIST’s portfolio | General-purpose default | Designated backup on an independent basis |
| Deployed in production TLS | Yes, as the ML-KEM half of X25519MLKEM768 (RFC 10024) | No published production deployment |
Sources: NIST FIPS 203, Table 3 and §8, August 2024, for the ML-KEM sizes and the recommended default; RFC 10024, August 2026, rfc-editor.org, for X25519MLKEM768 (FIPS 203 carries nothing about TLS). HQC figures are from the HQC specification as carried in HQC-192; NIST’s final standard may adjust them, since parameters are sometimes tuned during standardization.
How do they actually differ?
The mathematics is the whole point, and everything else follows from it.
ML-KEM’s security reduces to a lattice problem. HQC’s reduces to a coding-theory problem. Those are unrelated fields, so an advance that breaks one is not expected to touch the other. That independence is the reason NIST holds both rather than a matter of one being better.
The size difference is substantial and it is structural. At category 3, HQC’s public key is roughly 3.8 times ML-KEM’s and its ciphertext is roughly 8.3 times larger. Those bytes travel in every handshake, so the cost lands on protocols with tight size budgets and on constrained devices rather than on a general-purpose web server.
The maturity difference is the one most often understated. ML-KEM is a finalized federal standard with production deployment behind it. HQC is selected, and a selected algorithm is one whose parameters can still move before a final standard exists.
Where do they agree?
More than the contrast suggests, and readers consistently miss this.
Both are key-encapsulation mechanisms, so both solve confidentiality rather than authentication. Neither signs anything. Signatures are ML-DSA and its siblings, and conflating the two is the most common error in this subject.
Both target the same NIST security categories and can be compared tier for tier.
Both address the same threat, which is Shor’s algorithm breaking the key exchange protecting traffic today, including traffic recorded now for later decryption. See Harvest Now Decrypt Later.
And neither addresses the authentication lane, which remains classical almost everywhere in deployment.
When is ML-KEM the right answer?
Where a finalized standard, published parameters and production maturity are required, which describes most general-purpose key establishment today. It is NIST’s stated default, it is what regulators reference, and it is the algorithm with real deployment history in TLS.
When is HQC the right answer?
Where the requirement is basis diversity rather than performance. An estate that wants its long-lived confidentiality to survive a break in lattice mathematics has one standardized option on an independent foundation, and this is it.
The condition that makes it relevant is a long confidentiality horizon combined with tolerance for large artifacts. The condition that rules it out is a tight size budget, a constrained device, or a requirement for a finalized standard today.
Why did NIST standardize two KEMs?
Because the entire ML-KEM family rests on one branch of mathematics, and standardizing only that branch concentrates risk.
Lattice cryptography is well studied and no efficient attack is known. It is also the basis for ML-KEM and for the primary signature standard, so a fundamental advance against lattices would reach a large share of the migration at once. Selecting a code-based KEM buys an option on a different foundation, and that is the purpose the selection served rather than any deficiency in ML-KEM.
Is one replacing the other?
No, and the trajectory does not point that way. ML-KEM is the default and the deployed algorithm. HQC is the hedge, awaiting finalization. The published position is that ML-KEM is what to migrate to now and HQC is what to track.
Common misconceptions
“HQC is more secure than ML-KEM.” They are claimed at the same NIST security categories. HQC’s value is an independent mathematical basis rather than a higher security level.
“HQC replaces ML-KEM.” It was selected as a backup on a different foundation. Nothing published positions it as a successor.
“You have to pick one.” They are alternatives at the same layer, and holding an option on a second basis is the reason both exist.
“Bigger keys mean stronger.” Size here reflects the mathematics of the underlying problem rather than security margin. Both sit at the same category.
“HQC is available now.” It is selected, not finalized, with a draft expected around 2026.
Questions people ask
Which one should I use? Published guidance treats ML-KEM as the general-purpose default and HQC as the backup to track. This page teaches the distinction rather than making a selection for a particular estate.
Why did NIST standardize two? To avoid concentrating the migration on a single branch of mathematics. See above.
Is HQC a backup for ML-KEM? Yes, explicitly, and on a deliberately independent basis.
Which one is faster? HQC’s artifacts are several times larger at the same security category, which costs bandwidth in every handshake. Published performance figures vary by implementation and platform, so this page states the size figures, which are specified, rather than speed figures, which are not.
Which has bigger keys? HQC, substantially. At category 3 its public key is 4,514 bytes against ML-KEM’s 1,184.
Do regulators require one specifically? Federal migration guidance references the finalized NIST standards. HQC is not finalized, so it does not yet appear as a requirement.
What happens if lattices get broken? That is the scenario HQC exists for. An estate holding an option on a code-based KEM has a path that a lattice break does not close.
Can I use both? They occupy the same slot in a protocol, so the practical question is which is negotiated rather than running both. Combining a post-quantum KEM with a classical one is a different question, covered at Hybrid Cryptography.
Is this the same as Kyber? ML-KEM is the standardized form of the algorithm submitted as CRYSTALS-Kyber. HQC has no comparable rename.
Why are the HQC parameter names confusing? The current specification uses HQC-1, HQC-3 and HQC-5 while earlier rounds used hqc-128, hqc-192 and hqc-256. They map to security categories 1, 3 and 5.
Last verified 2026-08-10 · Maintained by Addie LaMarr, LaMarr Labs. Work with Addie at lamarrlabs.com.