BIKE

BIKE key generation produces a keypair using QC-MDPC code structure. This page runs the BIKE Level 1 structure at reduced parameters so every step completes instantly in the browser: r = , w = (w/2 = per block), t = . Spec BIKE Level 1 is r = , w = , t = — the table below is the published spec, not what runs here.

Source: BIKE Specification, NIST Round 4 Submission

Generate a Keypair (r = , w = , t = )

Key Structure

See the trapdoor: sparse private vs dense public

Key Size Comparison

BIKE achieves much smaller keys than Classic McEliece while staying in the same code-based security family. ML-KEM has the smallest keys overall. RSA-2048 is not post-quantum secure. These are spec figures at NIST security level 1 — the simulation on this page uses far smaller r, so its keys are a few dozen bytes.

KEM Flow: Alice → Bob

1. Alice encapsulates: Using Bob's public key, generates a random error vector e of weight t ( in this simulation; at spec BIKE Level 1), computes ciphertext c = e · [1 | h]ᵀ and derives shared secret K from e.
2. Bob decapsulates: Using his private key (h₀, h₁), computes syndrome s = H · cᵀ, then applies the Black-Gray-Flip (BGF) decoder to recover e, and derives the same K.
3. Shared secret match: K_Alice = K_Bob — used to key a symmetric cipher.

The Black-Gray-Flip Decoder

BIKE uses the Black-Gray-Flip (BGF) decoder for decapsulation. The name is the algorithm: Black and Gray are two masks it builds, and the flips it makes to each are what separate BGF from an ordinary threshold bit-flipper. Each of the steps below is a phase you can watch execute in the visualization further down.

1. Compute the syndrome: s = H · cᵀ. Zero means no errors; every non-zero bit is an unsatisfied parity check.
2. Set the threshold and classify: T is recomputed from the live syndrome weight each iteration (affine rule, floored at the majority value (d+1)/2 where d = w/2 = here). Count each bit's unsatisfied checks: counter ≥ T is Black; within τ below T is Gray.
3. Flip every Black bit — all at once, against the same start-of-iteration syndrome. Gray bits are recorded and deliberately left alone for now.
4. Black correction pass (first iteration): recount against the updated syndrome and un-flip any Black bit that still shows ≥ (d+1)/2 unsatisfied checks. A bit flipped in error usually looks worse afterwards — this is how BGF walks back its own mistakes, and it is the single largest reason its failure rate beats a plain bit-flipping decoder.
5. Gray correction pass (first iteration): the bits that were on the bubble get a second look now that the Black flips have moved the syndrome underneath them; those that have crossed (d+1)/2 are flipped. Later iterations are plain threshold flips, and the decoder stops when the syndrome reaches zero — or gives up after iterations.

Decapsulation Failure Rate (DFR): BIKE has a non-zero DFR — the decoder may fail for some error patterns, so BIKE is not suitable for protocols requiring perfect correctness. Two different numbers, and they are not interchangeable:

• Spec BIKE Level 1 (r = , t = ): DFR < 2⁻¹²⁸, by design — an event nobody will ever observe. ML-KEM's < 2⁻¹³⁹ is comparably negligible.
• This page (r = , t = ): the reduced parameters are far weaker, and the measured rate is roughly 0.5% — about 2^−7.6, or 1 decode in 200. That is not a flaw in the decoder; it is what shrinking r by a factor of 21 costs you. Do not read the 2⁻¹²⁸ figure onto anything that runs in this tab.

The rate quoted above is not a constant typed into the page — measure it yourself in the DFR lab below, and push the error weight up to watch it climb.

Try It: Encapsulate & Decapsulate

DFR Lab: Break the Decoder

A decapsulation failure rate is normally a number you are asked to believe. Here it is a number you can produce. Each trial below plants a fresh random error of the weight you choose, forms the real syndrome, runs the real BGF decoder, and checks that it recovered exactly the planted error — a zero syndrome reached with a different error vector still means Alice and Bob derive different secrets, so it counts as a failure. A fresh keypair is drawn every 50 trials, so the result averages over keys instead of reporting one lucky key.

Watch for the waterfall: the rate sits near zero while t is inside what the code can correct, turns sharply over a narrow band, and pins at 100%. That knee — not the headline constant — is the shape of every code-based KEM's correctness argument. It is also why choosing r and t is the whole security-versus-correctness tradeoff in BIKE.

End-to-End: KEM + AES-256-GCM

Side-by-Side: Key Sizes, Ciphertext, Performance

Every figure in this table is a specification figure at full parameters. The simulation running on this page uses r = instead of , and its measured decoding-failure rate is around 0.5% — roughly 2^−7.6, not 2⁻¹²⁸. The DFR lab in Panel 3 measures it live.

Sources: BIKE Spec, CRYSTALS-Kyber / ML-KEM Spec (FIPS 203)

Visual: Public Key + Ciphertext Sizes

Security Assumption Diversity

Key tradeoff: BIKE has much smaller keys than Classic McEliece (the other code-based candidate) but has a non-zero decapsulation failure rate, unlike ML-KEM's essentially negligible DFR. For protocols requiring perfect correctness, ML-KEM is the better choice.

Cryptographic Diversity

The NIST post-quantum standardization process selected ML-KEM (lattice-based) as the primary KEM standard, then in March 2025 selected the code-based HQC as a backup on a different mathematical assumption — precisely because no single assumption should be a single point of failure. The isogeny-based candidate SIKE made the same diversity argument and was broken outright in 2022 by a classical attack, which is a reminder that diversity is a hedge, not a guarantee.

If a breakthrough attack against lattice problems emerges, code-based schemes like HQC, BIKE, and Classic McEliece would remain secure — and vice versa. That is the cryptographic diversity argument, and it is why the syndrome-decoding problem this page is built on is worth understanding even though BIKE itself did not advance.

45+ Years of Cryptanalysis

Robert McEliece proposed the first code-based public-key cryptosystem in 1978 — making it the oldest post-quantum proposal still considered secure. The core hardness assumption (syndrome decoding) has withstood decades of cryptanalytic effort.

• 1978: McEliece cryptosystem proposed (Goppa codes)
• 1986: Niederreiter dual formulation
• 2013: Misoczki et al. propose MDPC-McEliece — precursor to BIKE
• 2017: BIKE submitted to NIST PQC competition
• 2022: BIKE advances to NIST Round 4 alongside Classic McEliece, HQC, and SIKE
• 2025 (March): NIST selects HQC as the backup KEM to ML-KEM (NIST IR 8545). BIKE was not selected — NIST cited HQC's clearer security proof and BIKE's reliance on a decoder whose failure rate is argued rather than proven.
• Today: BIKE has no NIST standardization path. It remains a studied, implemented design (it ships in Open Quantum Safe's liboqs) and its QC-MDPC decoding problem is still unbroken — but if you need a standards-track code-based KEM, that is HQC, and if you need a KEM at all, the default is ML-KEM.

This matters for how you read the rest of this page: BIKE is worth understanding because bit-flipping decoders and the DFR tradeoff are genuinely instructive, not because you should be planning to deploy it.

BIKE's Role in the PQ Landscape

BIKE occupies a specific niche in the post-quantum ecosystem:

• Compact alternative to Classic McEliece: Public keys ~1.5 KB vs ~261 KB at Level 1
• Same mathematical family: Both rely on the hardness of decoding random codes
• Tradeoff: BIKE has non-zero DFR; Classic McEliece has zero DFR but enormous keys
• Use cases: Where ML-KEM is primary but code-based diversity is desired as a backup or in hybrid constructions

Why This Matters in 2026+

Post-quantum migration is underway across the internet. The critical lesson from decades of cryptographic history:

Don't put all your eggs in one mathematical basket.

ML-KEM should be the default choice for most deployments. But organizations with long-term security requirements should consider hybrid approaches that include code-based schemes like BIKE — ensuring that a breakthrough against lattices doesn't compromise everything at once.

Explore More