up:: HQC (Hamming Quasi-Cyclic)
HQC-192
HQC-192 is the middle of the three parameter sets of HQC, the code-based key-encapsulation mechanism NIST selected on March 11, 2025 as the fifth post-quantum algorithm and the designated backup to ML-KEM. It targets NIST security category 3 and does the same key-establishment job as ML-KEM on a completely different mathematical foundation: the hardness of decoding a random-looking error-correcting code rather than lattice math. Its artifacts are large, a 4,514-byte public key and an 8,978-byte ciphertext, roughly four times the comparable ML-KEM-768 public key and several times its ciphertext, and those extra bytes are the price of a foundation that a lattice break cannot reach. HQC is selected but not yet finalized, so HQC-192 is 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; HQC specification, pqc-hqc.org.
The short version:
- HQC-192 is a key-encapsulation mechanism, so it establishes a shared secret. It is not a signature algorithm.
- It targets NIST security category 3, the middle of HQC’s three sets, with HQC-128 at category 1 and HQC-256 at category 5.
- Its public key is 4,514 bytes, its secret key is 4,602 bytes, and its ciphertext is 8,978 bytes.
[OPERATOR VERIFY: figures are from the HQC spec; re-verify against the NIST draft/final standard when published.] - It rests on code-based math (Quasi-Cyclic Syndrome Decoding), independent of the lattices behind ML-KEM.
- It is selected, not finalized. A draft standard is expected around 2026 and a final around 2027, so the move is to deploy ML-KEM now and track HQC.
What is HQC-192?
HQC-192 is the category-3 parameter set of HQC, a key-encapsulation mechanism from the code-based family. A KEM lets two parties agree on a shared secret over an untrusted channel: the recipient publishes a public key, the sender encapsulates a fresh secret into a ciphertext, and the recipient decapsulates it to recover the same secret, which then feeds ordinary symmetric encryption. HQC-192 runs that protocol at the middle parameter tier, stronger than HQC-128 and lighter than HQC-256.
A naming note matters here. The current HQC specification labels its three parameter sets HQC-1, HQC-3, and HQC-5 for security categories 1, 3, and 5, while earlier NIST-round submissions used the names hqc-128, hqc-192, and hqc-256. HQC-192 and HQC-3 refer to the same category-3 parameter set. The finalized NIST standard may settle the naming and could tune the parameters, so treat the figures below as the current reference rather than final FIPS values. [OPERATOR VERIFY: confirm the parameter-set name the NIST standard adopts (HQC-3 vs HQC-192) when it publishes.]
Source: HQC specification, pqc-hqc.org.
What are HQC-192’s sizes and security category?
These figures are from the HQC specification; NIST’s final standard may adjust them, since parameters are sometimes tuned during standardization.
| Property | Value |
|---|---|
| NIST security category | Category 3 |
| Public key | 4,514 bytes |
| Secret key | 4,602 bytes |
| Ciphertext | 8,978 bytes |
The number to internalize is the scale. At category 3, an HQC public key runs about four and a half kilobytes and its ciphertext runs about nine, where the comparable category-3 ML-KEM-768 has a 1,184-byte public key and a 1,088-byte ciphertext. That is roughly four times the key and more than eight times the ciphertext. The compute is not the constraint; the size on the wire is, and it is the direct cost of HQC’s independent, non-lattice foundation.
Source: HQC specification, pqc-hqc.org. [OPERATOR VERIFY: re-verify against the NIST HQC draft/final standard once published.]
Is HQC-192 finalized, and where does it fit?
HQC-192 is not finalized. NIST selected HQC on March 11, 2025 as the fifth post-quantum algorithm and the explicit backup to ML-KEM, with a draft standard expected around 2026 and a final one around 2027 after public comment. Until then, HQC-192 is not a FIPS you can point a compliance requirement at, and it should never be a reason to delay migrating to ML-KEM.
Its role is diversity, not first-line deployment. The primary NIST standard for key establishment, ML-KEM, is lattice-based, and HQC exists so that a future break in lattice cryptography would leave the encryption side of the transition with an independent second option. For nearly every program, HQC-192 is a Phase 2 consideration: deploy the recommended ML-KEM-768 now to close the harvest-now-decrypt-later exposure, build crypto-agility so a code-based KEM can slot in later, and follow the standard rather than the draft when adopting HQC.
Source: NIST, March 11, 2025.
Common misconceptions
- “HQC-192 is a standard I can require.” It is selected but not finalized. A draft is expected around 2026 and a final standard around 2027, so it is not yet a FIPS to point a requirement at.
- “The 192 means a 192-bit key.” It reflects the targeted security category, not a key length. HQC-192 (also named HQC-3) targets category 3, and its public key is 4,514 bytes.
- “HQC-192’s big artifacts mean it is 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 buy the independent, non-lattice foundation HQC exists for.
- “HQC-192 replaces ML-KEM-768.” HQC is a backup to ML-KEM for mathematical diversity, not a replacement. ML-KEM is the primary line deployed now; HQC is the second family held in reserve.
Questions people ask
Is HQC-192 finalized? No. NIST selected HQC on March 11, 2025, with a draft standard expected around 2026 and a final around 2027. Until then it is an algorithm to track and design for, not one to deploy broadly.
Is HQC-192 the same as HQC-3? Yes. The current HQC specification names its category-3 set HQC-3, and earlier NIST-round submissions named it hqc-192. They are the same parameter set. [OPERATOR VERIFY: confirm which name the NIST standard adopts.]
How much bigger is HQC-192 than ML-KEM-768? Its public key is about 4,514 bytes against ML-KEM-768’s 1,184, and its ciphertext is about 8,978 bytes against 1,088, so roughly four times the key and more than eight times the ciphertext.
Does HQC-192 do signatures? No. It is a key-encapsulation mechanism, so it handles key establishment only. Signatures are the job of ML-DSA, SLH-DSA, and FN-DSA.
Should I wait for HQC-192 before migrating? No. Deploy ML-KEM now, because it is the finalized default that addresses harvest-now-decrypt-later today, and keep HQC on the roadmap as a diversity option to add later.
Everything here is the map, given freely. When your team needs to decide where a code-based backup like HQC-192 belongs in your own protocols and estate, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.