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

For "static" public keys (such as long-term server-identity keys, long-term token keys, other long-term authentication keys, and long-term encryption keys), Classic McEliece uses less network traffic than other post-quantum systems. For example, mceliece6688128 uses just 208 bytes per ciphertext, compared to 660 bytes per signature for falcon512 (the final fndsa512 is expected to be similar), 768 bytes per ciphertext for mlkem512, or 2420 bytes per signature for mldsa44. What makes this comparison even more lopsided is that mceliece6688128 provides many more bits of security against known attacks than falcon512, mlkem512, and mldsa44 do.

For "one-time" public keys, alternatives use less network traffic than Classic McEliece because their public keys are smaller. For intermediate types of keys, the size comparison depends on the number of ciphertexts sent per key.

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

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

Official software

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

• ref, portable C software. This implementation is designed for clarity, not performance. This is the reference implementation of Classic McEliece.
• vec, portable C software. This implementation vectorizes across 64-bit integers. This is faster than ref and has the same portability.
• sse, C software using machine-specific intrinsics. This implementation uses the Intel/AMD 128-bit vector instructions.
• avx, C software using machine-specific intrinsics. This implementation uses the Intel/AMD 256-bit vector instructions. This is faster than sse and has approximately the same portability.

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:

• December 2017, in the round-1 NISTPQC submission package.
• August 2018, in SUPERCOP.
• April 2019, in the round-2 NISTPQC submission package. This was the first release with the 348864, 460896, and 6688128 parameter sets.
• July 2019, in SUPERCOP.
• June 2020, in SUPERCOP.
• October 2020, in the round-3 NISTPQC submission package.
• November 2021, in SUPERCOP.
• October 2022, in the round-4 NISTPQC submission package and in SUPERCOP. This was the first release supporting the non-pc parameter sets.
• June 2023, first libmceliece release (from members of the Classic McEliece team but not official at that point).
• April 2024, in SUPERCOP.
• May 2024, libmceliece.
• June 2024, in SUPERCOP. Includes improvements backported from libmceliece.
• July 2024, libmceliece.
• July 2024, in SUPERCOP. Includes improvements backported from libmceliece.
• August 2024, libmceliece.
• August 2024, in SUPERCOP. Includes improvements backported from libmceliece.
• October 2024, libmceliece.
• May 2025, libmceliece.

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.

By November 2025, Bernstein had 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:

• Debian packaging of libmceliece.
• Ubuntu packaging of libmceliece.
• pymceliece: Python wrapper for libmceliece, available through PyPI.
• python-mceliece: another Python wrapper for libmceliece, available in Debian and Ubuntu.
• PQClean: includes a (much slower) modification of the official implementations.
• liboqs: integration of the PQClean implementations.
• libgcrypt: includes integration of the official mceliece6688128 implementation.
• node-mceliece-nist: Node integration of the official implementations.
• classic-mceliece-rust: Rust translation of the official implementations.
• Bouncy Castle: includes Java and C# translations and integrations of the official implementations.
• Botan: C++ implementation of Classic McEliece.
• McTiny: includes stateless encapsulation software for clients streaming ephemeral Classic McEliece keys through a stateless network server.
• mceliece-arm-m4: implementations of key generation, encapsulation, and decapsulation for ARM Cortex-M4 microcontrollers. A small part of the speedup in these implementations comes from using integer multiplication, which is constant-time on the Cortex-M4. See paper. See also earlier Cortex-M4 paper.
• McOutsourcing: very-low-memory key generation.

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 June 2026, the liboqs web page warns against all usage of liboqs: "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. The PQClean project closed in 2026.