up:: The New Standards MOC

Classic McEliece

Classic McEliece is a post-quantum key encapsulation mechanism whose security rests on the hardness of decoding a random-looking binary Goppa code, the exact construction Robert McEliece published in 1978. That makes it the oldest scheme in the whole post-quantum field, unbroken after more than 40 years of cryptanalysis, and the most conservative, highest-assurance option in code-based cryptography. Its size profile mirrors everything else: the ciphertext is tiny, on the order of 100 bytes, while the public key is enormous, from a quarter-megabyte to about 1.3 megabytes. NIST didn’t pick it as a primary standard, choosing the lattice KEM ML-KEM and the code-based HQC backup instead, yet it keeps a place in conservative European guidance like Germany’s BSI TR-02102 for the narrow high-assurance cases where that huge key is acceptable.

The short version:

• Classic McEliece is a code-based KEM that secures key establishment on the difficulty of decoding random binary Goppa codes, a problem Shor’s algorithm doesn’t touch.
• It’s the oldest and most-studied post-quantum construction, unbroken since McEliece proposed it in 1978, which is the entire reason people trust it.
• Its defining tradeoff is inverted size: ciphertexts are around 100 bytes, but public keys run from about 261 KB up to roughly 1.3 MB depending on the parameter set.
• NIST did not standardize it. It was a fourth-round candidate; NIST standardized ML-KEM and chose HQC as the code-based backup, and Classic McEliece is being pursued separately.
• It fits niche high-assurance and long-term use where a static key can be loaded once and only the tiny ciphertext crosses the wire, and it’s favored by some conservative European guidance like BSI TR-02102.

Picture a padlock whose key is a filing cabinet and whose “unlock code” fits on a sticky note. Classic McEliece is like that. Setting it up means publishing something huge and unwieldy, the scrambled description of an error-correcting code, and that description is your public key.

But once it’s in place, sending you a secret takes almost nothing. Someone garbles a short message with a precise burst of errors, and that garbled scrap, about the size of a sticky note, is the whole ciphertext. Anyone can add the errors. Only you, holding the code’s hidden structure, can strip them off and read what’s underneath. The cabinet is a pain to move around, but the daily traffic is featherlight.

What is Classic McEliece?

Classic McEliece is a key encapsulation mechanism in the code-based family, submitted to the NIST post-quantum standardization process as a merger and modernization of the 1978 McEliece cryptosystem and the closely related 1986 Niederreiter variant. Its job is key establishment: two parties end up sharing a secret they can feed into ordinary symmetric encryption, without a quantum computer being able to recover that secret from what crosses the wire.

Three facts pin down its identity:

1. Canonical name and aliases. The scheme is “Classic McEliece.” People also call it the McEliece cryptosystem or a Goppa-code KEM, and its parameter sets carry names like mceliece348864 and mceliece6960119.
2. Mathematical family. It’s code-based, and specifically it uses binary Goppa codes. Its security rests on the hardness of the syndrome decoding problem, recovering the original message from a codeword that’s been deliberately corrupted with errors, when you don’t know the code’s hidden structure.
3. Provenance. The core idea is Robert J. McEliece’s, published in a 1978 JPL Deep Space Network progress report, which makes it the earliest public-key scheme still considered secure today.

Source: R. J. McEliece, “A Public-Key Cryptosystem Based On Algebraic Coding Theory,” DSN Progress Report 42-44, Jet Propulsion Laboratory, 1978, report PDF.

Source: Classic McEliece submission team, “Classic McEliece: conservative code-based cryptography,” project overview, classic.mceliece.org.

How does Classic McEliece work?

Classic McEliece hides an efficiently decodable Goppa code behind a scrambling transformation, publishes the scrambled result as a public key that looks like a random code, and relies on the fact that decoding a random code is hard. The flow has the same three moves as any KEM:

1. Key generation. You pick a binary Goppa code you can decode quickly because you know its secret structure, then apply a transformation that disguises it. The disguised version is your public key, and it looks like an ordinary random linear code with no exploitable pattern. The structure you kept is your private key.
2. Encapsulation. A sender uses your public key to encode a fresh random value and adds a carefully bounded pattern of errors on top of it. Adding the errors is easy and needs nothing but the public key. The result is the ciphertext, and from it both sides derive the shared secret.
3. Decapsulation. You use the hidden Goppa structure in your private key to correct the errors and recover the value, which yields the same shared secret. Anyone without that structure is stuck solving the general decoding problem, which has no known efficient solution.

The modern submission uses the Niederreiter dual form of the scheme and wraps it so that it’s IND-CCA2 secure, the strong security notion a KEM needs to be safe against active attackers.

Source: classic.mceliece.org, design overview and security definitions.

A quantum computer doesn’t help an attacker here. Shor’s algorithm breaks RSA and elliptic-curve cryptography by solving factoring and discrete logarithms, and neither of those is anywhere in this construction. Grover’s algorithm gives only the generic square-root speedup on brute-force search, and the parameter sizes are chosen with that speedup already accounted for. That quantum resistance is why the scheme sits in the post-quantum toolbox at all.

Why are Classic McEliece’s keys so large?

The public key is large because it has to describe an entire error-correcting code, and doing that takes a big matrix. A Goppa code strong enough to resist decades of cryptanalysis needs thousands of dimensions, and the disguised generator or parity-check matrix that becomes the public key grows with the square of those parameters. There’s no shortcut: the security comes from the code’s size, so shrinking the key would shrink the security.

The ciphertext, by contrast, is just a short syndrome, a compact fingerprint of the error pattern, so it stays tiny no matter how large the key gets. This is the exact opposite concentration from lattice schemes like ML-KEM, where the key and the ciphertext are both moderate and roughly comparable.

That inversion is the whole story of where Classic McEliece is usable. In any protocol that ships the public key on every connection, a quarter-megabyte-to-a-megabyte key is a non-starter, because it lands on every handshake. In a setting where the key can be installed once, out of band, and reused, the cost is paid a single time and the ongoing traffic is lighter than almost any alternative. The size isn’t a weakness in the cryptography. It’s a deployment constraint that rules the scheme in or out depending on how the key gets distributed.

What are the Classic McEliece parameter sets and key sizes?

The submission defines several parameter sets across NIST security levels 1, 3, and 5, each in a plain variant and a faster f variant with identical sizes. The numbers below are the exact byte counts from the reference implementation.

Parameter set	NIST level	Public key (bytes)	Ciphertext (bytes)	Secret key (bytes)
mceliece348864	1	261,120	96	6,492
mceliece460896	3	524,160	156	13,608
mceliece6688128	5	1,044,992	208	13,932
mceliece6960119	5	1,047,319	194	13,948
mceliece8192128	5	1,357,824	208	14,120

Source: Open Quantum Safe project, liboqs algorithm datasheet, “Classic McEliece,” openquantumsafe.org, reproducing the parameter sizes from the Classic McEliece specification.

Two things jump out of the table. The public key ranges from about 255 KB at the lowest security level to about 1.3 MB at the highest, which is 1,000 to 14,000 times larger than an ML-KEM public key. And the ciphertext never exceeds about 208 bytes across every level, which is smaller than an ML-KEM ciphertext. For comparison, ML-KEM-768 uses a 1,184-byte public key and a 1,088-byte ciphertext, so Classic McEliece trades a roughly thousandfold-larger key for a ciphertext several times smaller.

Where does Classic McEliece actually fit?

Classic McEliece fits the narrow set of cases where the large public key can be provisioned once and reused, and where minimal per-session traffic and maximum long-term assurance matter more than handshake convenience. Three situations describe most of its real use:

1. Static-key channels with out-of-band provisioning. When a device’s public key can be loaded during manufacturing or setup and then reused for a long time, the huge key is paid for once and never crosses the wire again. Only the roughly 100-byte ciphertext travels per session, which makes the scheme unusually bandwidth-light in steady state. This is the classic fit for constrained links and long-lived embedded or infrastructure endpoints.
2. Conservative, high-assurance, long-horizon systems. For data that must stay confidential for decades, some planners want the scheme with the longest unbroken track record and a security assumption that has nothing to do with lattices. Classic McEliece’s 40-plus-year history is the strongest such argument available.
3. Mathematical-diversity reserves. Alongside HQC, it serves as a non-lattice backup whose security is independent of any advance against lattice cryptography. Keeping an independent family in reserve is the instinct behind crypto-agility.

The one property to keep in mind is that a long-lived static key provides no forward secrecy. If that static secret is ever compromised, past sessions protected only by it are exposed, so the static-key pattern suits settings where that tradeoff is acceptable and rotation is handled deliberately.

What is Classic McEliece’s standardization status?

Classic McEliece was a fourth-round candidate in the NIST post-quantum standardization process, and NIST did not select it as a standard. In the fourth round NIST studied four key-establishment candidates, BIKE, Classic McEliece, HQC, and SIKE, and concluded that the only key-establishment algorithm it would standardize from that round is HQC.

Source: NIST, NIST IR 8545, Status Report on the Fourth Round of the NIST PQC Standardization Process, March 2025: “The only key-establishment algorithm that will be standardized is HQC.”

So on the NIST track, the code-based standard is HQC, and Classic McEliece is not a FIPS standard. That doesn’t make it disused. It’s being carried forward through other channels, and it holds a real place in conservative guidance:

1. Separate standardization track. The Classic McEliece team continues to maintain and promote the scheme outside the NIST FIPS process, and Germany’s BSI records that it’s being standardized through ISO.
2. European conservative guidance. BSI keeps Classic McEliece on the recommended list in its TR-02102 cryptographic-mechanisms guideline as a conservative code-based option, next to the unstructured-lattice FrodoKEM, for entities that want a larger margin against a future structured-lattice break.

Source: BSI, TR-02102-1 Version 2026-01, PDF, §2.4, which lists Classic McEliece among recommended key-agreement mechanisms and notes its ISO standardization.

The net picture is a scheme that lost the NIST efficiency contest but keeps a distinct role: NIST chose HQC as the deployable code-based KEM, while Classic McEliece remains the conservative, longest-tenured option that several non-NIST authorities still recommend. [OPERATOR VERIFY the current ISO/IEC standardization stage for Classic McEliece against the primary ISO/IEC docket before quoting a specific ISO standard number in a client deliverable; this note asserts only that BSI records it as being standardized by ISO.]

How does Classic McEliece compare to HQC and ML-KEM?

The cleanest way to place Classic McEliece is against the two KEMs it’s most often confused with: HQC, the code-based scheme NIST actually selected, and ML-KEM, the primary lattice standard. All three do key establishment; they differ on math family, NIST status, and size profile.

Property	Classic McEliece	HQC	ML-KEM
Math family	Code-based (binary Goppa codes)	Code-based (quasi-cyclic codes)	Lattice-based (module-LWE)
NIST status	Round 4 candidate, not standardized	Selected March 2025 as the code-based backup	Finalized standard (FIPS 203)
Public key size	Very large (about 261 KB to 1.3 MB)	Larger than ML-KEM, far smaller than McEliece	Small (about 1.2 KB at level 3)
Ciphertext size	Very small (about 100 to 208 bytes)	Larger than ML-KEM	Small (about 1.1 KB at level 3)
Track record	Longest of any PQC scheme, since 1978	Newer quasi-cyclic construction	Newer lattice construction
Best fit	Static-key, out-of-band, high-assurance niches	The deployable code-based diversity option	The general-purpose default, deploy first

Source: NIST, NIST IR 8545, March 2025 (statuses); Open Quantum Safe liboqs datasheets for Classic McEliece and ML-KEM (sizes).

The practical reading: ML-KEM is what almost every program deploys first because it’s the finalized, balanced default. HQC is the code-based backup to track for mathematical diversity. Classic McEliece is the specialist you reach for only when a static key can be provisioned out of band and the longest possible assurance argument is worth the bandwidth of that key.

Common misconceptions

1. “Classic McEliece is a NIST standard.” It isn’t. It was a fourth-round candidate, and NIST chose HQC as the code-based KEM to standardize. Treating Classic McEliece as a FIPS standard is a factual error.
2. “The giant public key means it’s insecure.” The large key is a deployment cost, not a cryptographic weakness. In fact, the size is directly tied to the security, and the scheme has the longest unbroken track record in the field.
3. “McEliece is brand-new post-quantum tech.” It’s the opposite. The construction dates to 1978, which makes it older than RSA is famous and the earliest public-key scheme still considered secure.
4. “Classic McEliece and HQC are interchangeable code-based KEMs.” They share a family but not a profile. HQC uses quasi-cyclic codes with moderate keys and is the NIST-selected backup; Classic McEliece uses Goppa codes with enormous keys and tiny ciphertexts and wasn’t selected.
5. “Big keys make it useless.” In the narrow static-key, out-of-band case, the huge key is loaded once and only the tiny ciphertext crosses the wire, which makes it one of the most bandwidth-light options in steady-state operation.

Questions people ask

Is Classic McEliece a NIST standard? No. It was a fourth-round candidate in the NIST post-quantum process, and NIST decided the only code-based key-establishment algorithm it will standardize from that round is HQC. Classic McEliece is being carried forward on a separate track, including ISO standardization per BSI.

Why is Classic McEliece’s public key so large? Because the public key has to describe an entire error-correcting code, and a code strong enough to resist decades of attack needs thousands of dimensions, which produces a matrix of hundreds of kilobytes to over a megabyte. The security comes from that size, so it can’t be shrunk without weakening the scheme.

How small is the ciphertext? Very. Across parameter sets it stays between about 96 and 208 bytes, which is smaller than an ML-KEM ciphertext and orders of magnitude smaller than the public key.

When would anyone actually use it? When the public key can be installed once and reused, such as a static key loaded onto a device during setup, so that only the tiny ciphertext travels afterward, and when maximum long-term assurance or mathematical diversity outweighs handshake convenience.

Is it quantum-safe? Yes. Its security rests on decoding random codes, which Shor’s algorithm doesn’t address, and Grover’s algorithm offers only a square-root speedup that the parameter sizes already absorb.

Why do BSI and other European bodies still recommend it if NIST didn’t pick it? NIST’s decision weighed efficiency heavily, and Classic McEliece’s keys are impractical for general use. Conservative guidance like BSI’s TR-02102 values its long track record and non-lattice security basis, so it keeps the scheme on the recommended list as a cautious alternative for entities that want a larger margin.

Does Classic McEliece provide forward secrecy? Not in the static-key deployment pattern it’s best suited for. A long-lived static key gives no forward secrecy, so if that secret is ever exposed, past sessions protected only by it are at risk. That’s an acceptable tradeoff in the specific settings where it’s used, provided rotation is handled deliberately.

Should my organization deploy Classic McEliece instead of ML-KEM? For general-purpose key establishment, no. ML-KEM is the finalized, balanced default and the right first move. Classic McEliece is a specialist tool for out-of-band-keyed, high-assurance niches, not a replacement for the mainstream standard.

---

Classic McEliece is the scheme you reach for when you’d rather move a filing cabinet once than mail a sticky note a thousand times, and when the longest track record in the field is worth the weight. Everything here is the map, given freely. When your team needs to decide whether a code-based KEM like this belongs anywhere in your protocols and estate, that’s what an alignment briefing is for.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.