Classic McEliece
Intro
Comparison
Implementation
Specification
NIST
ISO
Papers
Talks
People
Credits

There is a guide for implementors aimed at readers upgrading cryptographic applications to use Classic McEliece.

For applications with cryptographic performance constraints: Classic McEliece has very large public keys but very small ciphertexts. Public keys can be reused for many ciphertexts, so Classic McEliece can reach lower total costs than other post-quantum encryption systems. For "static keys" (such as identity keys), Classic McEliece is typically the lowest-cost option; for "ephemeral keys", other options typically have lower cost.

The rest of this page describes the Classic McEliece sizes, the official Classic McEliece software, how the official software protects against timing attacks, and various unofficial Classic McEliece implementations and integrations.

Sizes

The "f" variants have the same size and are not listed here. The "pc" variants have 32 extra bytes in ciphertexts.

public key private key ciphertext session key
261120 6492 96 32 mceliece348864
524160 13608 156 32 mceliece460896
1044992 13932 208 32 mceliece6688128
1047319 13948 194 32 mceliece6960119
1357824 14120 208 32 mceliece8192128

Official software

The official Classic McEliece implementations are the following four software implementations for each of the selected parameter sets:

The official Classic McEliece integration is libmceliece, which packages slightly modified versions of vec and avx into an easy-to-use shared library, including automatic selection of avx on CPUs that support it and vec otherwise. All of the official software is in the public domain.

Updates of the official Classic McEliece implementations are released via updates of the SUPERCOP benchmarking package. Updates of the official Classic McEliece integration are released via libmceliece updates. Speeds are reported in the eBATS KEM benchmarks and the libmceliece speed page respectively. The main focus of the official Classic McEliece development work is now libmceliece, although various improvements have also been backported to the SUPERCOP releases.

Release history:

Protection against timing attacks

Timing attacks are an important class of attacks against cryptographic software. To protect against these attacks, the official Classic McEliece software was designed from the outset to run in constant time, using techniques introduced in the "McBits" and "McBits revisited" papers. Specifically, the software has no data flow from secrets to branch conditions, array indices, and integer multiplications. Note that integer multiplications take variable time on many CPUs, possibly including Intel CPUs.

The implementations starting in November 2021 have full support for TIMECOP, which runs the compiled software while checking for any data flow from secrets to branch conditions and array indices. The libmceliece test suite starting in July 2024 automatically runs TIMECOP-type tests on the compiled libmceliece library.

The importance of testing binaries. TIMECOP's tests are not just a double-check on the data flow in the source code: they also protect against any problems introduced by compilers.

In particular, unfortunate recent changes to compilers often "optimize" cryptographic source code without branches into binaries with branches, by recognizing some common types of 1-bit data paths and converting those into booleans, which produce branches by default. The rationale for a November 2021 gcc patch was a code sample in which branches were then removed by a subsequent compiler pass, saving time overall. However, the patch applies the same conversion even in cases where the branches are not removed. This would have been caught by more comprehensive benchmarking, but compiler authors allow patches on the basis of single code samples. Similar comments apply to a July 2022 llvm patch. These patches ended up in released versions of gcc and clang, introducing timing variations throughout the existing cryptographic software ecosystem.

Daniel J. Bernstein, a member of the Classic McEliece team, issued a public alert in April 2024 regarding this compiler problem. The problem was caught because TIMECOP's binary testing started covering compiler releases that included the problematic patches. Bernstein then integrated TIMECOP-type tests into the libmceliece test suite (included in the July 2024 libmceliece release, as noted above), so the libmceliece binaries are tested even if the compiler used for libmceliece is not covered by the continual TIMECOP runs within SUPERCOP.

Porting software to handle dangerous compilers. Testing binaries before deployment protects the end user by preventing the source code from being used with compiler versions that cause problems. Porting the source code to those compiler versions then requires changing the source code, preferably in advance or at the latest in response to test failures. To support this process, Bernstein developed a library called cryptoint that takes central responsibility for safely carrying out basic integer operations. For example, crypto_int64_bottombit_01(x) has the same effect as x&1 but prevents a compiler from recognizing the 1-bit data path.

As of November 2025, Bernstein has proactively changed 4731 lines of code in 184 different cryptographic primitives in SUPERCOP to call the cryptoint functions. For Classic McEliece, conversion has focused on the vec and avx implementations used in libmceliece. The slower ref and sse implementations are not used in libmceliece but have been partially converted. See the cryptoint paper for further information on cryptoint.

Unofficial software

Various authors have released the following further Classic McEliece software:

There is also pqc-classic-mceliece, an implementation of Classic McEliece for FPGAs. See paper. See also earlier paper and implementation covering the core mathematical operations inside key generation, encapsulation, and decapsulation. See also earlier paper regarding key generation.

Links to unofficial Classic McEliece software are provided here for informational purposes, not for endorsement. Often software is suitable only for experiments. For example, as of November 2025, the liboqs web page says "WE DO NOT CURRENTLY RECOMMEND RELYING ON THIS LIBRARY IN A PRODUCTION ENVIRONMENT OR TO PROTECT ANY SENSITIVE DATA"; presumably this warning also applies to PQClean, which is the main source of implementations in liboqs.

Version: This is version 2025.11.20 of the "Implementation" web page.