ML-KEM vs Classic McEliece: 300x Bigger Keys [2026]

NIST finished the first phase of its post-quantum cryptography rollout in 2024 by finalizing ML-KEM, the lattice-based scheme now known as FIPS 203. But quietly, on the other side of the mathematical family tree, a 45-year-old code-based cryptosystem called Classic McEliece has been picking up real deployments, an ISO standard, and a growing chorus of engineers who argue it belongs in production systems today, not as a museum piece. As of September 2026, choosing between lattice-based and code-based post-quantum cryptography is no longer an academic exercise. It is a decision engineering teams are making right now for VPNs, hardware security modules, and long-term data protection.

This comparison lays out what separates the two families in practice: key sizes, benchmark numbers, standardization status, and where each one actually gets deployed in 2026. The short version is that lattice-based ML-KEM is fast and compact, while code-based Classic McEliece is slow to generate keys and enormous to store, but both are still standing after decades of cryptanalysis aimed at breaking them. The two approaches solve overlapping problems in almost opposite ways, and picking the wrong one for your use case can cost you either bandwidth or peace of mind.

What lattice-based and code-based cryptography actually are

Lattice-based cryptography builds its hardness assumption on the Learning With Errors (LWE) problem and its structured variant, Module-LWE. Picture a high-dimensional grid of points; given a point that’s been nudged slightly off the grid by noise, finding the nearest actual lattice point is computationally brutal once the dimension climbs into the hundreds. ML-KEM (the standardized name for what was called Kyber during the NIST competition) and ML-DSA (formerly Dilithium) both lean on this problem. So does Falcon, now standardized in draft form as FN-DSA.

Code-based cryptography takes a completely different road. It relies on the hardness of decoding a general linear error-correcting code, a problem proven NP-hard back in 1978. Classic McEliece, first proposed by Robert McEliece that same year, hides a highly structured Goppa code behind a scrambled, public generator matrix. An attacker sees what looks like a random linear code and has to decode it without knowing the trapdoor. Nobody has found an efficient way to do that in 45 years of trying, which is precisely why cryptographers keep calling it “the old reliable” of post-quantum schemes.

The practical result of these two different math problems is a set of near-opposite tradeoffs. Lattice schemes pack their security into compact keys, at the cost of leaning on a decades-younger, less-battle-tested assumption. Code-based schemes lean on one of the oldest hard problems in the field, but the price is public keys that stretch into hundreds of kilobytes or more.

ML-KEM vs Classic McEliece: full specifications compared

The clearest way to see the split between these two families is to line up their exact byte counts. FIPS 203 fixes ML-KEM’s parameters at three security levels, while the Classic McEliece reference implementation publishes five parameter sets mapped to roughly 128-bit, 192-bit, and 256-bit security. The table below pulls the official numbers from both specifications.

Scheme / parameter set	Public key size	Private key size	Ciphertext size	Shared secret	Approx. security level
ML-KEM-512	800 bytes	1,632 bytes	768 bytes	32 bytes	NIST Level 1 (~128-bit)
ML-KEM-768	1,184 bytes	2,400 bytes	1,088 bytes	32 bytes	NIST Level 3 (~192-bit)
ML-KEM-1024	1,568 bytes	3,168 bytes	1,568 bytes	32 bytes	NIST Level 5 (~256-bit)
mceliece348864	261,120 bytes	6,492 bytes	96 bytes	32 bytes	~128-bit
mceliece460896	524,160 bytes	13,608 bytes	156 bytes	32 bytes	~192-bit
mceliece6688128	1,044,992 bytes	13,932 bytes	208 bytes	32 bytes	~192-bit
mceliece6960119	1,047,319 bytes	13,948 bytes	194 bytes	32 bytes	~256-bit
mceliece8192128	1,357,824 bytes	14,120 bytes	208 bytes	32 bytes	~256-bit
ML-DSA-44 (signature, lattice)	1,312 bytes	2,560 bytes	2,420 bytes (signature)	n/a	NIST Level 2
HQC-128 (code-based backup KEM)	~2,249 bytes	~2,305 bytes	~4,481 bytes	32 bytes	~128-bit

Read that table sideways and the story is obvious. Classic McEliece’s public keys run anywhere from 261 KB to 1.36 MB, over 300 times larger than ML-KEM-512’s 800-byte key at a comparable security level. Flip to ciphertext size, though, and code-based cryptography wins by an even bigger margin: McEliece ciphertexts are 96 to 208 bytes, a fraction of ML-KEM’s 768-to-1,568-byte range. That asymmetry (huge keys, tiny ciphertexts) is the single fact that determines where each scheme fits in a real system.

Benchmark results: keygen, encapsulation, and decapsulation speed

Size differences are only half the picture. Speed tells the rest of the story, and here the gap is arguably more dramatic than the key-size numbers suggest. A 2024 NIST PQC panel comparison found that Classic McEliece’s key generation runs roughly 3,000 times slower than ML-KEM’s in raw CPU cycles, a gap NIST’s own IR 8545 report called “three orders of magnitude more costly than HQC,” referring to McEliece’s code-based sibling.

Operation	ML-KEM-512	ML-KEM-768	mceliece348864	mceliece460896	Source
Key generation	~2-10 ms	~3-15 ms	~35,978 kilocycles (tens of ms)	~117,301 kilocycles (~50-100 ms)	NIST PQC panel benchmarks, 2024; CRYPTREC 2025 evaluation
Encapsulation	~2-14 ms	~4-20 ms	~38 kilocycles (sub-ms)	~81 kilocycles (sub-ms)	NIST PQC panel benchmarks, 2024
Decapsulation	~4-23 ms	~6-32 ms	~128 kilocycles (sub-ms)	~264 kilocycles (~1-2 ms)	NIST PQC panel benchmarks, 2024
Constrained-device encap/decap	~0.05 ms (Kyber768 test)	–	0.1-0.5 ms (FPGA implementation)	–	2024-2026 embedded/FPGA benchmarking papers

The pattern flips depending on which operation you’re timing. ML-KEM’s key generation is dramatically faster than McEliece’s, which matters a lot if you’re rotating keys often. But once a McEliece key pair exists, encapsulation and decapsulation on the McEliece side are actually quick, since the ciphertext is tiny and the decoding trapdoor is efficient to use. That’s why McEliece tends to show up in systems with long-lived, rarely-rotated keys rather than ephemeral, session-by-session key exchange.

A 2025 CRYPTREC evaluation, Japan’s cryptographic standards body, benchmarked ML-KEM across all three parameter sets and found keygen times ranging from 20 ms down to under 10 ms depending on the test platform, with encapsulation and decapsulation both landing under 50 ms even at the highest security level. Separately, a 2025 update to a widely used Kyber Python reference implementation clocked ML-KEM-768 at 3.31 ms for keygen, 4.48 ms for encapsulation, and 6.14 ms for decapsulation on an Intel i7-9750H, averaged over 1,000 runs. Three independent sources, three different testbeds, and the numbers all land in the same rough range: single-digit to low double-digit milliseconds for lattice-based operations across the board.

Standardization status: FIPS vs ISO, and why NIST chose HQC over McEliece

Here’s where the story gets political, in the standards-committee sense of the word. ML-KEM cleared NIST’s finish line first: FIPS 203 was finalized on August 13, 2024, making it a formally approved federal cryptographic standard in the United States. ML-DSA followed the same day as FIPS 204. Classic McEliece has no such finish line at NIST. According to NIST IR 8545, the agency’s 2025 status report on its fourth round of evaluation, HQC was selected as the sole additional code-based key-establishment algorithm to be standardized, and Classic McEliece was explicitly dropped from further NIST consideration.

NIST’s stated reasoning is blunt: the agency’s report describes McEliece’s enormous public-key size as making it “an unattractive candidate” for broad standardization, and says NIST doubts it will see widespread use given the size penalty. That is not the same as saying the scheme is weak. NIST IR 8413 and IR 8545 both describe Classic McEliece as widely regarded as secure, with the longest unbroken cryptanalysis track record of any post-quantum finalist. NIST simply concluded that key size, not security margin, should gate what it stamps as a general-purpose federal standard.

Where NIST stepped back, the International Organization for Standardization stepped in. In 2026, ISO/IEC 18033-2:2006/Amd 2:2026 added ML-KEM, FrodoKEM, and Classic McEliece to its international asymmetric-cipher standard. NIST’s own documentation acknowledges the sequencing: the agency states that concurrent standardization by NIST and ISO risks producing incompatible standards, and that it “may consider developing a standard for Classic McEliece based on the ISO standard” only after the ISO process wraps up. In practice, that means any organization across ISO’s 177 member states now has a recognized international standard to point to when deploying Classic McEliece, even without a NIST FIPS number attached.

Pricing and deployment cost comparison

Neither ML-KEM nor Classic McEliece carries a license fee. Both are patent-unencumbered and free to implement. The real “cost” in this comparison is infrastructure overhead: bandwidth, storage, and CPU cycles, which translate into actual cloud and hardware spend at scale. The table below estimates that overhead for a mid-size deployment handling 10 million key exchanges per day, a rough proxy for a busy API gateway or VPN concentrator.

Cost factor	ML-KEM-768	Classic McEliece (mceliece460896)	Hybrid (both combined)
License / algorithm fee	$0 (royalty-free)	$0 (royalty-free)	$0
Per-handshake bandwidth (approx.)	~2.3 KB (pubkey + ciphertext)	~524 KB (pubkey) + 156 bytes	~526 KB combined
Bandwidth cost at 10M handshakes/day (rough, $0.05/GB egress)	~$1.15/day	~$262/day (if key sent fresh each time)	~$263/day
Key storage overhead per stored keypair	~4 KB	~538 KB	~542 KB
Typical engineering integration effort	Low (mature libraries: liboqs, OpenSSL 3.5+, BoringSSL)	Medium-high (fewer mainstream library integrations, larger static key management)	Medium (both libraries, extra config)

The bandwidth math above assumes worst-case fresh key transmission for McEliece, which is why practical McEliece deployments almost always use static, long-lived public keys distributed once (baked into a VPN client, pinned in a hardware module) rather than transmitted per-session. Once you account for that pattern, the daily bandwidth cost gap narrows enormously since the 524 KB key is paid once, not per handshake. That’s the whole reason McEliece survives in the real world: change the deployment pattern to match the scheme’s strengths and the “huge key” problem becomes a one-time cost instead of a recurring one.

Where each scheme actually ships in 2026

Real deployments tell you more than benchmark tables ever will. Here are five concrete, current examples of each family in production or near-production use as of September 2026.

• Mullvad VPN has run Classic McEliece by default on its desktop clients since January 2025, paired with ML-KEM in a hybrid handshake, betting that a VPN’s relatively small number of long-lived server keys can absorb the storage cost.
• Rosenpass, an open-source post-quantum key-exchange layer for WireGuard, combines Classic McEliece with ML-KEM (referred to by its earlier name, Kyber) in hybrid tunnels for the same reason: static server identity keys, not ephemeral session keys.
• Crypto4A’s QxHSM hardware security module lists Classic McEliece in its supported algorithm set alongside FIPS-standardized ML-KEM, ML-DSA, and SLH-DSA, aimed at government and financial customers who want a conservative code-based option baked into tamper-resistant hardware.
• Chrome and Firefox both ship hybrid X25519 plus ML-KEM-768 key exchange by default in modern releases, meaning the large majority of encrypted web traffic touching those browsers already negotiates lattice-based post-quantum protection without any user action.
• AWS enabled ML-KEM-based post-quantum TLS across KMS, ACM, and Secrets Manager, exposing a client-side flag to turn on hybrid post-quantum key agreement for services that need it, a sign that lattice-based PQC has moved from browser vendors into core cloud infrastructure.

The pattern across all five examples is consistent: ML-KEM shows up wherever keys need to move fast and often (browser handshakes, cloud API calls, ephemeral sessions), while Classic McEliece shows up wherever a key can be generated once, embedded deep in a system, and left alone for years.

Security track record and recent research findings

Neither family has been broken at its standardized parameters, but the type of scrutiny each has received differs. Classic McEliece has survived 45 years of attempted cryptanalysis against its underlying decoding problem, longer than almost any other public-key scheme still in active use. Lattice-based schemes are younger by comparison, and 2024-2025 research has focused less on breaking the math and more on breaking specific implementations.

The KyberSlash disclosures, first published in 2024, identified two timing side-channel bugs (dubbed KyberSlash1 and KyberSlash2) in several real-world Kyber/ML-KEM implementations, including reference code, caused by division operations whose runtime depended on secret data. Follow-on research through 2025 extended the attack surface further: one study combined correlation power analysis with lattice-reduction techniques to recover a full secret key from an ARM Cortex-M4 device in roughly 9 to 10 minutes using as few as 15 power traces. None of this breaks ML-KEM’s mathematical security; it underscores that implementation-level side channels remain the practical soft spot for lattice cryptography on embedded hardware.

CRYPTREC’s 2025 evaluation report, after running ML-KEM through lattice-reduction, hybrid, structural, and decryption-failure attack models, concluded that no practically exploitable weakness is currently known against ML-KEM at any of its three standardized parameter levels, with security margins that exceed NIST’s target categories even under aggressive attacker-cost assumptions. A separate 2026 academic commentary argued that lattice-based cryptography is fundamentally a “transitional” choice because Learning With Errors is an unproven hardness assumption rather than a proven one, but the same commentary was careful to note it demonstrated no actual break of ML-KEM, ML-DSA, Falcon, or HQC at their standardized parameters. In short: the theoretical debate about proof versus assumption continues, but no working attack has landed on either family’s finalized parameter sets.

Pros and cons: ML-KEM (lattice-based)

Pros: ML-KEM is a finalized NIST FIPS 203 standard, meaning it’s the safe default for anyone needing regulatory or compliance sign-off today. Its keys and ciphertexts measure in the hundreds to low thousands of bytes, small enough to slot into existing TLS handshakes with minimal overhead. Keygen, encapsulation, and decapsulation all run in single-digit to low double-digit milliseconds on commodity hardware, and mature open-source libraries (liboqs, OpenSSL 3.5+, BoringSSL) already ship production-grade implementations. Browser and cloud adoption is already broad: Chrome, Firefox, and AWS all support it in hybrid mode.

Cons: ML-KEM’s security rests on the Learning With Errors problem, an assumption with roughly two decades of scrutiny rather than McEliece’s four-plus. Real-world implementations have already shown timing and power side-channel vulnerabilities (KyberSlash and related attacks), meaning the code around ML-KEM needs careful, constant-time engineering to actually deliver its theoretical security. It is also, by design, one option rather than a diversification strategy: relying on lattice math alone means a future breakthrough in lattice cryptanalysis could affect ML-KEM, ML-DSA, and Falcon simultaneously, since all three share the same underlying hard problem family.

Pros and cons: Classic McEliece (code-based)

Pros: Classic McEliece’s core hard problem, decoding a random linear code, has resisted cryptanalysis since 1978, giving it the longest security track record of any post-quantum finalist. Its ciphertexts are tiny (96 to 208 bytes), and once a key pair is generated, encapsulation and decapsulation are fast. It now carries a recognized international standard via ISO/IEC 18033-2:2006/Amd 2:2026, and it diversifies risk away from lattice assumptions entirely, which is exactly why organizations like Germany’s BSI recommend it as a conservative hedge in hybrid deployments.

Cons: Public keys run from 261 KB to over 1.3 MB, ruling it out for anything that needs to transmit a fresh key per session over constrained bandwidth. Key generation is roughly three orders of magnitude slower than ML-KEM’s, per NIST’s own IR 8545 comparison, making frequent key rotation impractical. NIST declined to standardize it as a FIPS, so any deployment has to justify itself against ISO 18033-2 or internal policy rather than a US federal standard, which can be a harder sell in regulated environments that specifically require FIPS validation.

Five use cases and which scheme fits each one

1. TLS web traffic and API gateways: ML-KEM-768 in hybrid mode with X25519. Sessions are ephemeral, bandwidth matters, and browser support already exists.
2. VPN client-to-server tunnels with static server keys: Classic McEliece paired with ML-KEM in hybrid mode, following the Mullvad and Rosenpass pattern, since the server’s public key is distributed once and reused for months or years.
3. Hardware security modules protecting long-term root keys: Classic McEliece category 5 (mceliece8192128), following the NIST workshop paper’s own framing of McEliece as best suited to protecting other keys, including ML-KEM, ML-DSA, and SLH-DSA keys, in transit and storage.
4. Mobile and IoT devices with tight bandwidth or memory budgets: ML-KEM-512, given its sub-kilobyte keys and millisecond-scale operations validated in constrained-device benchmarking through 2026.
5. Regulated US federal systems requiring FIPS validation today: ML-KEM exclusively, since it is the only one of the two with a finalized FIPS number (203) as of September 2026; Classic McEliece has no FIPS path yet.
6. Archival or long-term-confidentiality data at rest (30+ year threat horizon): Hybrid deployment combining both, on the logic that an attacker would need to break two structurally unrelated hard problems simultaneously to recover the data.

Migration guide: moving from classical to post-quantum key exchange

Most teams migrating today aren’t choosing one scheme in isolation, they’re layering post-quantum protection on top of classical algorithms in hybrid mode, which every major standards body currently recommends as the safe transition path. Here’s the practical sequence.

1. Inventory your key-exchange touchpoints. List every place your system negotiates a shared secret: TLS termination points, VPN tunnels, message queues, hardware token provisioning, and any long-term data-at-rest encryption keys.
2. Classify by session lifetime. Ephemeral, high-frequency exchanges (web sessions, API calls) point toward ML-KEM. Long-lived, low-frequency exchanges (VPN server identity, HSM root keys) are candidates for Classic McEliece in hybrid mode.
3. Update your TLS stack. Move to OpenSSL 3.5 or later, which supports hybrid X25519+ML-KEM-768 named groups natively. For nginx, this means compiling against OpenSSL 3.5+ and explicitly enabling the hybrid group, since it is not on by default.
4. Test hybrid handshakes in staging. Hybrid key exchange adds roughly 1 KB to a TLS ClientHello/ServerHello exchange for ML-KEM-768; confirm this doesn’t break any middleboxes, load balancers, or legacy clients with hardcoded packet-size assumptions.
5. For static, long-lived keys, evaluate Classic McEliece. If you’re protecting a VPN server identity or an HSM root key that changes rarely, benchmark the one-time cost of distributing a 261 KB to 1.3 MB public key against the security diversification benefit.
6. Update signature algorithms alongside key exchange. If you’re touching TLS anyway, plan for ML-DSA (FIPS 204) as your default post-quantum signature scheme; FN-DSA (Falcon) remains in draft as FIPS 206 and isn’t finalized as of September 2026.
7. Roll out in hybrid mode first, everywhere. Never deploy a post-quantum-only scheme as your sole key exchange yet. Combine it with a classical algorithm (X25519 or P-256) so a flaw in the new math doesn’t leave you with zero security.
8. Monitor for side-channel guidance. Track library updates for KyberSlash-style timing fixes if you’re running ML-KEM on embedded or resource-constrained hardware; patch promptly since these are implementation bugs, not protocol flaws.
9. Document your crypto-agility plan. Given that HQC’s draft standard is still pending finalization around 2026-2027 and FN-DSA remains in draft, build your key-exchange layer so swapping algorithms doesn’t require an application rewrite.

What engineers and researchers are saying

A paper submitted to a 2025 NIST workshop on KEM guidance, titled “ML-KEM is Great! What’s Missing?”, laid out the case for keeping Classic McEliece in the toolkit even after NIST’s own decision not to standardize it. The paper’s authors wrote: “We strongly think NIST should standardize Classic McEliece, which has properties that makes it the best choice for many different applications,” a direct pushback against the “unattractive candidate” framing in NIST’s IR 8545 report (source).

The same authors were explicit about their own deployment plans, stating: “We are planning to use Classic McEliece,” and framed the scheme’s role in a hybrid stack this way: “Classic McEliece is the most conservative KEM and Classic McEliece category 5 is the best option for protecting various other keys (ML-KEM, ML-DSA, SLH-DSA, FN-DSA, LMS, XMSS, etc.) in transit and storage” (source).

They also drew a direct parallel to how NIST already treats its hash-based signature scheme, noting: “Classic McEliece occupies a role similar to SLH-DSA, providing a very conservative security assurance” (source). Their bottom-line recommendation for teams weighing both schemes: “For static encapsulation use cases where ML-KEM provides the best performance, Classic McEliece is the best backup algorithm” (source).

How the broader post-quantum family lines up

ML-KEM and Classic McEliece aren’t the only options on the table, and understanding where they sit relative to their siblings helps clarify the bigger picture. On the signature side, ML-DSA (FIPS 204, lattice-based) is NIST’s flagship general-purpose signature scheme, with ML-DSA-44 producing a 1,312-byte public key and 2,420-byte signatures. FN-DSA (Falcon), also lattice-based, remains stuck in draft as FIPS 206, creating what NIST’s own timeline effectively admits is a multi-year gap behind ML-DSA; the NSA’s CNSA 2.0 guidance has indicated it doesn’t plan to add FN-DSA at all, citing Falcon’s higher sensitivity to implementation errors.

On the key-encapsulation side, HQC was picked by NIST’s post-quantum cryptography project in March 2025 as the sole code-based backup to ML-KEM, edging out both BIKE and Classic McEliece. HQC’s public keys run around 2,249 bytes for its 128-bit security level, far smaller than McEliece’s but still roughly three times larger than ML-KEM’s equivalent. BIKE, a QC-MDPC code-based scheme, wasn’t selected at all, with NIST citing unresolved concerns about its decoding-failure-rate analysis. That leaves the post-quantum KEM landscape with three practical options as of September 2026: ML-KEM (fast, small, FIPS-standardized), HQC (a code-based middle ground, draft standard expected 2026-2027), and Classic McEliece (huge keys, tiny ciphertexts, ISO-standardized but not FIPS).

Library and language support in 2026

Support in mainstream cryptographic libraries is one of the clearest signals of how far each scheme has moved from research code into production. ML-KEM has the deeper bench here. Open Quantum Safe’s liboqs project ships reference implementations of ML-KEM at all three parameter levels, and that work has been folded into OpenSSL 3.5 and later as a provider, meaning any application linking against a current OpenSSL build gets ML-KEM support without vendoring a separate library. BoringSSL, Google’s fork used across Chrome and much of its infrastructure, ships the same hybrid X25519+ML-KEM-768 group used in the browser by default. Rust’s pqcrypto crate and Python’s reference bindings both expose ML-KEM directly, and Java developers get it through JDK 24’s built-in KEM API additions.

Classic McEliece support exists but is thinner on the ground. liboqs includes it, so anything built on top of that library (including some OpenSSL provider configurations) can access it, but it’s rarely turned on by default given the payload size. The project’s own reference implementation, published on the official Classic McEliece site, remains the canonical source most integrators build from. Hardware vendors targeting government and high-assurance customers, such as Crypto4A, have built native support directly into their HSM firmware rather than relying on a general-purpose software library, which reflects how the scheme tends to get deployed: as a deliberate, specialized choice rather than a default flag flipped on in a general-purpose TLS stack.

# Generating a hybrid ML-KEM-768 + X25519 keypair with liboqs (Python bindings)
import oqs

with oqs.KeyEncapsulation("ML-KEM-768") as kem:
    public_key = kem.generate_keypair()
    print(f"ML-KEM-768 public key size: {len(public_key)} bytes")  # 1184 bytes

# Classic McEliece keypair for comparison (much larger public key)
with oqs.KeyEncapsulation("Classic-McEliece-460896") as kem:
    public_key = kem.generate_keypair()
    print(f"Classic McEliece public key size: {len(public_key)} bytes")  # 524160 bytes

That size gap shows up immediately the moment you print both key lengths side by side, which is often the fastest way to convince a team why the two schemes get deployed so differently in practice. A public key that fits in a single TLS record versus one that needs to be chunked, cached, or distributed out of band is not a marginal difference, it changes the entire integration approach.

Common mistakes teams make during migration

A handful of mistakes show up repeatedly in early post-quantum migrations, based on patterns documented across 2025-2026 deployment guides and vendor advisories. The first is treating hybrid mode as temporary scaffolding to be ripped out later. Every major standards body, including BSI and NIST’s own transition guidance, frames hybrid deployment as the standard for the foreseeable future, not a stopgap; removing the classical algorithm too early throws away a real security benefit for no practical gain.

The second mistake is applying Classic McEliece’s key-generation cost to the wrong part of a system. Teams sometimes assume the “3,000x slower keygen” figure from NIST’s benchmarking makes McEliece unusable, without checking whether their use case actually requires frequent key generation in the first place. For a VPN server identity key generated once and used for a year, a keygen operation measured in tens of milliseconds is irrelevant regardless of the multiplier.

The third is ignoring implementation-level side channels while focusing entirely on protocol-level security. The KyberSlash disclosures made clear that a mathematically sound scheme can still leak secrets through a careless division operation. Teams deploying ML-KEM on embedded or resource-constrained hardware specifically need to verify their chosen library has patched known timing issues, not just confirm it implements the correct FIPS 203 parameters.

Specs table: the full post-quantum KEM landscape

Algorithm	Math family	Standard status (Sept. 2026)	Public key	Ciphertext
ML-KEM-768	Lattice (Module-LWE)	FIPS 203, finalized Aug. 2024	1,184 bytes	1,088 bytes
HQC-128	Code-based (Hamming quasi-cyclic)	Selected March 2025; draft standard pending, expected 2026-2027	~2,249 bytes	~4,481 bytes
Classic McEliece (460896)	Code-based (Goppa codes)	ISO/IEC 18033-2 Amd 2, 2026; no NIST FIPS	524,160 bytes	156 bytes
BIKE	Code-based (QC-MDPC)	Not selected by NIST (decoding-failure concerns)	Comparable to lattice schemes	Comparable to lattice schemes
ML-DSA-44 (signature)	Lattice (Module-LWE/SIS)	FIPS 204, finalized Aug. 2024	1,312 bytes	2,420 bytes (signature)
FN-DSA / Falcon (signature)	Lattice (NTRU)	Draft FIPS 206, not finalized	~897 bytes (level 1)	~666 bytes (signature)

The verdict: which one should you actually deploy

If you’re building or maintaining a system today and need one default answer, it’s ML-KEM-768 in hybrid mode with X25519. It’s the finalized FIPS standard, it’s fast, its keys are small enough to drop into existing protocols without redesigning them, and the library and browser support already exists. That covers the overwhelming majority of use cases: TLS, VPN session keys, API authentication, mobile apps.

Classic McEliece earns its place in a narrower but genuinely important slice of deployments: long-lived static keys where you can pay the one-time storage and distribution cost of a key that can run past a megabyte, in exchange for leaning on a 45-year-old hard problem instead of a 20-year-old one. The data backs this up directly. Mullvad and Rosenpass didn’t pick McEliece because it’s fast; they picked it because their key-distribution pattern (baked into a client once, reused for a long time) neutralizes McEliece’s one real weakness. If your system looks like that, McEliece in hybrid mode is a legitimate, standards-backed choice, now with ISO 18033-2 behind it even without a NIST FIPS number.

The honest bottom line: this isn’t really an either-or decision anymore. The organizations taking post-quantum migration most seriously, from BSI’s guidance in Germany to Mullvad’s production VPN, are running both at once. Lattice math for speed, code-based math for a second, structurally unrelated line of defense. Given that key generation, not ciphertext exchange, is where McEliece pays its cost, and given that most systems generate long-term keys far less often than they exchange session keys, hybrid deployment costs less than the headline key-size numbers suggest.

Frequently asked questions

Is Classic McEliece a NIST standard?
No. As of September 2026, NIST has not issued a FIPS for Classic McEliece. NIST selected HQC instead as its code-based backup to ML-KEM in March 2025 and explicitly dropped McEliece from further NIST standardization consideration, citing its large public-key size. Classic McEliece is standardized internationally via ISO/IEC 18033-2:2006/Amd 2:2026 instead.

Why are Classic McEliece public keys so much bigger than ML-KEM’s?
The two schemes rely on structurally different hard problems. ML-KEM’s Module-LWE problem can be represented compactly using structured polynomial rings, keeping keys under 2 KB even at the highest security level. Classic McEliece’s security comes from hiding a Goppa code inside what looks like a random linear code, and representing that generator matrix requires hundreds of kilobytes to over a megabyte, depending on the security level.

Can I use both ML-KEM and Classic McEliece at the same time?
Yes, and several real deployments already do. Mullvad VPN and the Rosenpass project both combine Classic McEliece with ML-KEM in hybrid key exchanges, on the reasoning that an attacker would need to break two mathematically unrelated hard problems simultaneously to compromise the shared secret.

Is lattice-based cryptography less secure than code-based cryptography?
Not in any way that’s been demonstrated. No practical attack has broken ML-KEM at its standardized parameters, according to CRYPTREC’s 2025 evaluation. The distinction researchers raise is that Learning With Errors is a younger, unproven hardness assumption compared to the code-based decoding problem, which has resisted cryptanalysis since 1978. That’s a theoretical distinction about assumption age, not evidence of a practical weakness in ML-KEM today.

What is HQC and how does it fit into this comparison?
HQC (Hamming Quasi-Cyclic) is a code-based key-encapsulation scheme that NIST selected in March 2025 as its official code-based backup to ML-KEM, ahead of BIKE and Classic McEliece. Its keys run around 2,249 bytes, far smaller than McEliece’s but still larger than ML-KEM’s. A draft NIST standard for HQC is expected around 2026-2027.

Does hybrid post-quantum key exchange slow down TLS handshakes noticeably?
Hybrid ML-KEM-768 plus X25519 adds roughly 1 KB to a TLS handshake, which is a manageable overhead on most modern networks and generally adds low single-digit milliseconds of latency. Chrome and Firefox already run this combination by default for a large share of encrypted web traffic without users noticing a difference.

Should regulated industries wait for a Classic McEliece FIPS before using it?
If your compliance requirements specifically mandate FIPS-validated algorithms, yes, stick with ML-KEM (FIPS 203) and ML-DSA (FIPS 204) for now, since Classic McEliece has no FIPS path yet. If your requirements accept ISO standards or internal risk-acceptance processes, ISO/IEC 18033-2:2006/Amd 2:2026 already covers Classic McEliece, and vendors like Crypto4A already ship it in FIPS-adjacent hardware security modules.

What happened to BIKE and Falcon in the NIST post-quantum process?
BIKE, a code-based scheme, was not selected by NIST due to unresolved concerns about its decoding-failure-rate analysis. Falcon was standardized under the name FN-DSA but remains in draft form as FIPS 206 as of September 2026, roughly two years behind ML-DSA’s finalized FIPS 204, and the NSA’s CNSA 2.0 guidance suggests it may not adopt FN-DSA at all.

Related Coverage

• ML-KEM vs NTRU: 1,568 vs 1,230-Byte Keys [2026]
• ML-KEM vs RSA: 1,184-Byte Keys, 52% Web Adoption [2026]
• ML-KEM vs HQC: NIST's Backup Adds 4x the Compute [2026]
• ML-KEM vs X25519 TLS 1.3: 52% Adoption, +1.5ms [2026]
• ECC vs RSA: 25x Faster Signing, Smaller Keys [2026]