Classic McEliece

Classic McEliece is a code-based key-encapsulation mechanism built on binary Goppa codes. A NIST Round-4 candidate not selected by NIST; it is on the ISO/IEC standardization track, not the NIST FIPS track. It is prized for its extreme conservatism — the underlying problem has resisted attack since 1978 — and for tiny ciphertexts, at the price of enormous public keys.

How it works

Classic McEliece is a KEM whose security rests on the hardness of decoding a random-looking linear code. The public key is a scrambled generator/parity-check matrix for a binary Goppa code; the private key is the structured description that allows efficient decoding. Encapsulation encodes a random error vector and derives a shared secret; decapsulation uses the secret Goppa structure to decode the error and recover the secret.

The original McEliece scheme dates to 1978 and has survived more than forty-five years of cryptanalysis essentially intact — an unusually strong track record. "Classic McEliece" is the modern, IND-CCA2-secure KEM packaging of that idea.

Parameter sets

Sizes vary widely across parameter sets. Note the contrast: ciphertexts are tiny, but public keys are hundreds of kilobytes to over a megabyte. Approximate values in bytes. Classic McEliece has many parameter sets, and different document versions keep different recommended sets; overall the public keys range from about 255 KB to 1.3 MB and the ciphertexts from about 96 to 208 bytes.

Strengths & tradeoffs

• Extremely conservative. Unbroken since 1978; the security assumption is among the most trusted in all of cryptography.
• Tiny ciphertexts. Only ~96-208 bytes — smaller than ML-KEM ciphertexts — which is great for high-volume encapsulation traffic.
• Tradeoff — huge public keys. 255 KB to over 1 MB. This makes it unsuitable for protocols that transmit a fresh public key per handshake (like ephemeral TLS), but acceptable when keys are long-lived and distributed infrequently.

When to use it

Classic McEliece shines when the public key can be installed once and reused for a long time — pinned keys, pre-provisioned devices, or static infrastructure endpoints — and you want the strongest possible confidence in long-term confidentiality (defending against Harvest Now, Decrypt Later). For general ephemeral key exchange where keys are sent per connection, prefer ML-KEM or the code-based HQC.

Code example

import oqs

kem = "Classic-McEliece-348864"
with oqs.KeyEncapsulation(kem) as server:
    public_key = server.generate_keypair()
    print("public key bytes:", len(public_key))  # ~261120 (~255 KB!)

    with oqs.KeyEncapsulation(kem) as client:
        ciphertext, ss_c = client.encap_secret(public_key)
        print("ciphertext bytes:", len(ciphertext))  # ~96

    ss_s = server.decap_secret(ciphertext)
    assert ss_c == ss_s

Related

Standards & references

• Classic McEliece project — official specification, reference implementation, and parameter sets.
• NIST PQC project — Round-4 KEM evaluation and status.
• Resources — full standards register