← Back to Blog Research

NIST IR 8528: Round 4 KEM Status Report

12 min read

When NIST announced the first set of post-quantum standards in July 2022, it picked one main key encapsulation mechanism (KEM): CRYSTALS-Kyber, now known as ML-KEM. But picking one algorithm was always going to be risky. If a researcher discovered a flaw in the lattice math behind ML-KEM, the entire post-quantum migration would stall. So NIST decided to keep three more candidates running in a fourth round of evaluation. The goal: pick at least one backup KEM built on different mathematical assumptions.

NIST Internal Report (IR) 8528, published in March 2025, documents the outcome of that fourth round. It explains why HQC was selected as the backup, why Classic McEliece was kept on hold, and why BIKE was eliminated. For anyone planning a long-term migration to quantum-safe encryption, IR 8528 is a key reference. It shapes the second wave of NIST PQC standards.

This post walks through what IR 8528 contains, the reasoning behind each decision, and what HQC's selection means for software like QNSQY that has to support both primary and backup algorithms.

Why a Fourth Round Was Needed

The NIST PQC competition started in 2017 with 69 submissions. By 2022 it had narrowed to four winners: Kyber for KEM, Dilithium and Falcon for signatures, and SPHINCS+ as a hash-based signature backup. All but SPHINCS+ rely on lattice problems. That single mathematical foundation worried cryptographers.

A practical example: the lattice attack progress in 2022 and 2023 saw new techniques (BKZ improvements, dual sieve attacks) that did not break ML-KEM but did slightly tighten its security margin. If those improvements had gone further, NIST would have needed a non-lattice fallback ready to deploy. SPHINCS+ covers signatures, but until a non-lattice KEM was selected, key exchange had no diverse alternative.

So in July 2022 NIST kept three KEM candidates active for further analysis:

Classic McEliece (code-based, McEliece 1978)
BIKE (code-based, QC-MDPC codes)
HQC (code-based, quasi-cyclic codes with Hamming distance)

All three are code-based, meaning they rely on the hardness of decoding random linear codes rather than lattice problems. This gives the diversification NIST wanted.

The Selection Criteria

IR 8528 lists the criteria used to evaluate the three candidates:

Security: confidence in cryptanalysis after years of public review
Performance: key sizes, ciphertext sizes, encapsulation and decapsulation time
Implementation: ease of constant-time implementation, side-channel resistance
Diversity: mathematical hardness assumption different from lattice

Performance matters because KEMs are used in handshakes, where every kilobyte of public key or ciphertext costs latency. Security matters because the goal is a 30-year-plus encryption guarantee. Implementation matters because constant-time code is hard to write for some algorithms.

Classic McEliece: Trusted but Heavy

Classic McEliece is the oldest candidate. The original McEliece cryptosystem was proposed in 1978, before RSA was widely deployed. After 47 years of public scrutiny, no significant attack has dented its security claim. That historical record is unmatched.

The downside is key size. A Classic McEliece public key for the highest security level is over 1.3 megabytes. Compare that to ML-KEM-1024's 1568-byte public key, and the gap is roughly 800x. For a TLS handshake, that size is a non-starter on most networks.

NIST's IR 8528 decision: Classic McEliece is mature and trusted, but it is held in reserve for niche use cases (long-term static keys, government archival). It was not standardized as a general-purpose backup KEM in the second wave. NIST may publish a separate FIPS for it later if a clear use case emerges.

BIKE: Eliminated for Decryption Failures

BIKE uses quasi-cyclic moderate-density parity-check (QC-MDPC) codes. It has small public keys (around 1.5 KB) and good performance. On paper it looked like a strong candidate.

The problem turned out to be decryption failures. BIKE has a non-zero probability that decryption returns the wrong shared secret, even with correctly formed inputs. The probability is small (roughly 2^-128), but it is not zero. Worse, the failure rate depends on the secret key in subtle ways. Several papers between 2020 and 2024 showed how an attacker who can observe many decryption attempts on the same key can use failure patterns to recover the secret.

Mitigations exist (rejection sampling, constant-weight encoding), but they complicate implementation and reduce performance. NIST decided that the risk of subtle implementation failures outweighed the benefits, and BIKE was removed from the standardization track in IR 8528.

This does not mean BIKE is broken in practice today. It means NIST is not willing to put its name on a standard where wrong implementations could leak keys. For a CISO making a 30-year bet on key exchange, that conservatism is welcome.

HQC: The Selected Backup

HQC (Hamming Quasi-Cyclic) won the fourth round. IR 8528 announced it as the backup KEM in March 2025. HQC will be standardized in a FIPS document, likely numbered FIPS 209, in 2025 or 2026.

HQC bases its security on the syndrome decoding problem for quasi-cyclic codes with Hamming weight constraints. It avoids BIKE's decryption failure issue by using a different decoding approach. Its key sizes are larger than ML-KEM but smaller than Classic McEliece:

HQC-128: 2249-byte public key, 4481-byte ciphertext
HQC-192: 4522-byte public key, 9026-byte ciphertext
HQC-256: 7245-byte public key, 14421-byte ciphertext

Encapsulation and decapsulation are slower than ML-KEM but acceptable for most applications. The bigger sizes are noticeable but not prohibitive: a TLS handshake with HQC-128 adds a few kilobytes, not megabytes.

How HQC Fits Alongside ML-KEM

For software designers, the question is what to do with two standardized KEMs.

The IR 8528 guidance is clear: ML-KEM is the primary. Use it for new deployments. HQC is the diversification. Hold it ready for the case where ML-KEM is found to have a weakness, or for users who want defense in depth across mathematical assumptions.

Some organizations will deploy hybrid HQC + ML-KEM, combining shared secrets from both. This gives security as long as either algorithm holds. The cost is added bandwidth and CPU. For ultra-high-assurance use cases (national security, long-term legal records), the trade-off is worth it.

QNSQY supports both ML-KEM (in Free, Pro, and Business tiers) and HQC (in Business tier) precisely because IR 8528 made HQC a first-class standard. Users who care about cryptographic diversification can opt into HQC for sensitive data, while general use stays on faster ML-KEM. For more on the lattice math behind ML-KEM, see ML-KEM explained.

What IR 8528 Means for Migration Plans

If you are building a PQC migration plan today, IR 8528 has three implications:

Plan for two KEMs, not one. Federal systems will eventually need to support ML-KEM and HQC, especially for long-lived data.
Watch the FIPS 209 publication (expected 2026). That sets the formal compliance date for HQC.
Use hybrid mode. Combining classical (X25519) with PQC (ML-KEM or HQC) hedges against both quantum attacks and PQC algorithm flaws. See hybrid encryption.

For organizations under CNSA 2.0 mandates (US national security systems), the timeline aligns with NIST's. CNSA 2.0 requires PQC by 2030 to 2033, and HQC support will need to ride alongside.

Implementation Concerns for HQC

HQC is more complex to implement correctly than ML-KEM. Constant-time decoding is harder for code-based schemes. Side-channel attacks (timing, cache) on early HQC implementations have been demonstrated. Production deployments need:

FIPS 140-3 validated modules for HQC
Constant-time reference implementations from the HQC team or ENISA
Side-channel testing during integration

NIST's CAVP and CMVP programs are extending validation criteria to HQC. Expect formal validated modules to appear through 2026. Until then, software that ships HQC should clearly mark it as a non-validated backup.

QNSQY ships HQC implementations from the pqcrypto-hqc Rust crate, wrapped in catch_unwind for crash safety because the underlying C reference code can abort on malformed inputs. This DoS protection is a practical example of the kind of hardening HQC integrations need.

Comparing HQC to Other Code-Based Schemes

For people new to code-based cryptography, here is a brief contrast:

Classic McEliece: Goppa codes, large keys, oldest
BIKE: QC-MDPC codes, small keys, decryption failures
HQC: quasi-cyclic codes with Hamming weight, mid-size keys, no decryption failure
LEDAcrypt (also evaluated): similar to BIKE, eliminated earlier

HQC's selection is partly because it has a clean security proof reducing to syndrome decoding without the failure-rate caveats that hurt BIKE. The IND-CCA2 transformation HQC uses (Fujisaki-Okamoto) is well-studied.

How HQC Performs on Common Hardware

The IR 8528 evaluation included performance benchmarks across server, laptop, and embedded platforms. The headline numbers from the HQC submission package and the pqcrypto-hqc reference benchmarks are:

HQC-128 keygen: 2.5 ms on a 3 GHz Intel Xeon
HQC-128 encap: 0.4 ms
HQC-128 decap: 0.7 ms
HQC-256 keygen: 11 ms
HQC-256 encap: 1.6 ms
HQC-256 decap: 2.9 ms

ML-KEM-768 by comparison runs at roughly 50 microseconds for any single operation on the same hardware, so HQC is 5x to 50x slower depending on the operation and parameter set. For a TLS handshake performed once per connection, this is invisible. For high-volume API endpoints performing thousands of handshakes per second, it matters but does not block deployment with appropriate horizontal scaling.

On embedded hardware (an ARM Cortex-M4 at 200 MHz), HQC-128 encapsulation runs in about 35 ms. This is borderline acceptable for IoT key exchange but slower than ML-KEM-512's 4 ms on the same chip. The IR 8528 guidance is explicit that HQC is the diversification choice for high-assurance deployments, not the lightweight option for resource-constrained devices.

HQC Side-Channel Considerations

NIST's IR 8413 supplementary report on side-channel considerations applies equally to HQC. The reference implementation is not constant-time in some operations (notably the Reed-Muller decoder), and several academic papers have demonstrated cache-timing attacks against early HQC code. The HQC team published a constant-time variant in 2023, and the reference implementation in the pqclean repository tracks this version.

For QNSQY, HQC support in the Business tier uses the constant-time pqcrypto-hqc Rust binding wrapped in catch_unwind for DoS protection. Side-channel testing as part of the broader hardening pass identifies remaining timing variation, with corrections fed back upstream where possible. The R56 audit (March 2026) found no exploitable side-channel leak in QNSQY's HQC code path.

For deployers planning to use HQC, the practical advice is to (1) use the constant-time reference, (2) avoid running HQC alongside attacker-influenced workloads on the same physical core, and (3) prefer HQC for at-rest encryption where the attacker has no real-time observation channel.

FAQ

Why did NIST select HQC over Classic McEliece?

Both are code-based and both have strong security records. HQC has key sizes that are practical for TLS handshakes and other interactive protocols. Classic McEliece's public keys are over a megabyte, which makes it impractical for general use. NIST may still standardize Classic McEliece for niche cases, but HQC fits more deployments.

Is HQC slower than ML-KEM?

Yes, modestly. HQC encapsulation and decapsulation take roughly two to four times the CPU of ML-KEM at equivalent security levels, depending on parameter set and implementation. For most applications this is unnoticeable, but for high-volume servers it matters. Bandwidth is also larger because HQC ciphertexts are bigger.

When will HQC be available in TLS, SSH, and IPsec?

The IETF is working on HQC code points for hybrid TLS handshakes. Drafts in the TLS and PQUIP working groups are tracking the FIPS 209 publication. Realistic deployment in standard libraries (OpenSSL, BoringSSL) is 2026 to 2028. See IETF PQUIP drafts for the current status.

Does QNSQY support HQC today?

Yes, QNSQY's Business tier supports HQC-128, HQC-192, and HQC-256. The Free and Pro tiers focus on ML-KEM with hybrid X25519. HQC is a Business feature because it is the diversification option for users who need cryptographic agility across mathematical assumptions. See pricing for tier details.

What if HQC also gets broken?

This is the worst-case scenario NIST is trying to avoid. The agency continues to fund research on alternative KEM constructions (isogeny-based, multivariate, hybrid lattice-code schemes). If both ML-KEM and HQC fall, NIST has the structure in place to launch a fifth round and select replacements. The hybrid approach (PQC + classical) also provides a fallback during any transition.

Does IR 8528 cover signatures?

No. IR 8528 is specifically the round-4 KEM status report. Signatures are tracked in a separate process: the on-ramp signature competition that started in 2023 is evaluating additional signature candidates beyond ML-DSA, FN-DSA, and SLH-DSA. Updates appear in NIST IR 8528A and follow-up reports.

Should I deploy HQC today, or wait for FIPS 209?

For non-regulated use cases, deploying HQC today as part of a defense-in-depth strategy is reasonable. The algorithm has been studied for several years and the IR 8528 selection signals NIST's confidence. For regulated use cases (federal systems, healthcare, financial), waiting for FIPS 209 and the corresponding CMVP-validated modules is the safer path. QNSQY's Business tier offers HQC for both audiences: users who want it now have it; users who need formal validation can wait for the validated module path.

Sources

NIST Internal Report 8528, "Status Report on the Fourth Round of the NIST Post-Quantum Cryptography Standardization Process," March 2025. https://csrc.nist.gov/pubs/ir/8528/final
NIST Computer Security Resource Center, "Post-Quantum Cryptography Standardization." https://csrc.nist.gov/projects/post-quantum-cryptography
NIST IR 8413, "Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process," July 2022. https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8413.pdf
HQC Submission Specification, NIST PQC Round 4 Submission. https://pqc-hqc.org/
Aguilar Melchor, C. et al, "HQC: Hamming Quasi-Cyclic," IACR ePrint 2017/1004. https://eprint.iacr.org/2017/1004
NIST IR 8413A, "Side-Channel Considerations for the NIST Post-Quantum Cryptography Algorithms." https://csrc.nist.gov/pubs/ir/8413/upd1/final
PQClean repository, constant-time HQC. https://github.com/PQClean/PQClean

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY