BIKE (Bit Flipping Key Encapsulation)
BIKE is a code-based key-encapsulation mechanism built on quasi-cyclic moderate-density parity-check (QC-MDPC) codes that competed in the fourth round of the NIST post-quantum standardization process and was not selected. Its full name is Bit Flipping Key Encapsulation, and it was one of four code-based and isogeny-based candidates NIST studied for key establishment. In March 2025, NIST chose HQC as the single code-based backup to ML-KEM and left BIKE out, because BIKE’s decoding-failure-rate analysis stayed an open problem while HQC’s was stable. So BIKE is a road not taken, a serious and well-studied design that lost a two-way finalist race, and not a standard you deploy.
Source: NIST IR 8545, Status Report on the Fourth Round of the NIST Post-Quantum Cryptography Standardization Process, March 2025, nvlpubs.nist.gov.
The short version:
- BIKE is a code-based KEM on QC-MDPC codes. It does the same job as ML-KEM and HQC, establishing a shared secret over an untrusted channel, and it does nothing for signatures.
- NIST studied BIKE, Classic McEliece, HQC, and SIKE in a dedicated fourth round, then selected only HQC on March 11, 2025 as the code-based backup to ML-KEM.
- BIKE was HQC’s closest rival, similar code-based math and smaller keys and ciphertexts, so the two were the real finalists for the general-purpose code-based slot.
- NIST didn’t pick BIKE because its decoding failure rate (DFR) analysis stayed uncertain, and a low, well-understood DFR is exactly what BIKE needs to be secure against active attackers. HQC’s DFR analysis was stable, so HQC won.
- BIKE isn’t broken, and it isn’t a standard either. It’s an algorithm to understand for context and not one to build a compliance requirement on.
Picture a scratched CD that still plays every song. The disc wraps the music in extra redundancy so the player can rebuild it even after some bits are lost, and that redundancy is an error-correcting code. Correcting the errors is easy when you hold the code’s hidden structure and hard when you don’t, and code-based cryptography turns that gap into a lock.
BIKE’s particular design uses a lightweight “bit-flipping” decoder, a fast method that walks through the garbled message and flips the bits it thinks are wrong, one pass at a time. That decoder is what makes BIKE small and quick. It’s also the thing that tripped it up. On rare, unlucky keys the flipping process can march off in the wrong direction and fail to recover the message, and pinning down exactly how rare that is, across every possible key, turned out to be the hard problem NIST couldn’t see resolved in time.
What is BIKE?
BIKE (Bit Flipping Key Encapsulation) is a key-encapsulation mechanism from the code-based family of post-quantum cryptography, built on binary linear quasi-cyclic moderate-density parity-check codes. NIST describes it exactly that way: “BIKE (Bit-Flipping Key Encapsulation) is a KEM based on binary linear quasi-cyclic moderate density parity check (QC-MDPC) codes.” The identity in one card:
- Full name: Bit Flipping Key Encapsulation.
- Common shorthand: BIKE.
- Type: key-encapsulation mechanism (key establishment), not a signature scheme.
- Family: code-based cryptography, built on QC-MDPC codes.
- Security basis: the decisional Quasi-Cyclic Syndrome Decoding (QCSD) problem, plus a quasi-cyclic codeword-finding assumption.
- NIST status: fourth-round candidate, not selected for standardization.
- Key use: originally designed for ephemeral keys, and it now claims to support static keys too.
Source: NIST IR 8545, §3.2, March 2025.
BIKE sits in the same corner of the field as HQC and Classic McEliece. All three are code-based KEMs, and all three were on NIST’s fourth-round list. Of the three, HQC is the one that became a standards-track algorithm, McEliece is the conservative elder with enormous keys, and BIKE is the compact QC-MDPC design that came closest to HQC and still lost.
How does BIKE work?
BIKE does what every KEM does. One party publishes a public key, the other encapsulates a fresh random secret into a ciphertext, and the key owner decapsulates that ciphertext to recover the same secret, which then feeds ordinary fast symmetric encryption. What’s specific to BIKE is the machinery underneath, which follows a Niederreiter-style construction over QC-MDPC codes:
- Key generation. The secret key is a parity-check matrix for a quasi-cyclic moderate-density code, made of two circulant blocks whose rows carry a fixed low Hamming weight. Because circulant matrices behave like polynomials, that secret is really just a pair of polynomials, and the public key is the same object rearranged into systematic form so it reveals no exploitable structure.
- Encapsulation. The sender encodes a message as a low-weight error vector and computes the ciphertext by multiplying it against the public key. Adding the errors takes nothing but the public key, so anyone can send.
- Decapsulation. The key owner multiplies the ciphertext by the private structure to produce a syndrome, then runs an iterative bit-flipping decoder, the recommended Black-Grey-Flip decoder, to recover the original error vector and with it the shared secret.
Source: NIST IR 8545, §3.2, March 2025.
The bit-flipping decoder is the heart of BIKE and the source of both its speed and its trouble. It’s an iterative guesser. It looks at the syndrome, decides which bits are most likely to be in error, flips them, and repeats until the message resolves. That’s cheap and fast, which is why BIKE’s keys and ciphertexts come out small. The catch is that an iterative decoder doesn’t always converge. On most keys it recovers the message every time, but on rare, structurally unlucky keys it can flip the wrong bits early and never recover, which is a decapsulation failure. How often that happens, across the whole space of keys and messages, is a number BIKE has to bound tightly, and bounding it precisely is genuinely hard.
What is BIKE’s security based on?
BIKE’s security rests on the hardness of decoding a random-looking quasi-cyclic code, formalized as the decisional Quasi-Cyclic Syndrome Decoding (QCSD) problem, together with a quasi-cyclic codeword-finding assumption. NIST states that BIKE’s proof of IND-CPA security “depends on the difficulty of solving the decisional QCSD and QCCF problems.” Decoding a random linear code is a decades-old, NP-hard problem with no known efficient solution on a classical or a quantum computer, which is what makes the family quantum-resistant in the first place.
Source: NIST IR 8545, §3.2, March 2025.
That foundation is completely separate from the math that classical cryptography rests on. There’s no factoring and no discrete logarithm anywhere in BIKE, so Shor’s algorithm, which demolishes RSA and elliptic-curve cryptography, has nothing to attack. It’s also separate from the lattice math behind ML-KEM, which is the whole reason a code-based KEM was attractive as a backup. Grover’s algorithm offers only the generic quadratic speedup on brute-force search, and the parameter sizes already absorb it.
The wrinkle is the gap between IND-CPA and IND-CCA2 security. IND-CPA is the weaker guarantee, security against an attacker who can only watch. IND-CCA2 is the strong guarantee a general-purpose KEM actually needs, security against an attacker who can feed the system chosen ciphertexts and learn from the responses. BIKE reaches IND-CCA2 by applying a standard transform to its IND-CPA scheme, and that transform only holds if the decoder’s failure rate is provably tiny, at most 2 raised to the negative security level. That single requirement, a provably low DFR, is the pivot the whole selection turned on.
Why didn’t NIST select BIKE?
NIST didn’t select BIKE because it couldn’t get comfortable with BIKE’s decoding-failure-rate analysis in time, and a low, well-characterized DFR is a hard requirement for the strong security a general-purpose KEM needs. NIST said it plainly: “The decisive factor in favor of HQC relative to BIKE is HQC’s stable DFR analysis,” and “there have been persistent uncertainties regarding BIKE’s DFR.” NIST added that “understanding the DFR of BIKE has remained an open problem during the fourth round.”
Source: NIST IR 8545, §3.1 and §3.2, March 2025.
The specifics show why this was more than a paperwork gap. Iterative bit-flipping decoders on QC-MDPC codes resist closed-form analysis, and the DFR falls in two regimes, a fast “waterfall” region and a slow “error floor” region, with the target failure rate too low to measure directly. Over the fourth round, real weaknesses kept surfacing:
- Weak keys. A class of weak keys with a “gathering” property was shown to push the average DFR to at least 2 to the power of negative 117 for BIKE’s level 1 parameters, which is enough to defeat its IND-CCA2 security. The BIKE team answered with a new “BIKE-flip” decoder that sets a high flipping threshold on the first iteration and lowers it gradually, which reduced the problem.
- Near codewords. Low-weight error patterns known as near codewords were shown to dominate BIKE’s error-floor behavior, and modeling their effect is what makes the true DFR so hard to pin down.
- Post-selection tweaks. NIST’s read was blunt: “previous inaccurate DFR estimates have resulted in BIKE being attacked as late as the fourth round, and BIKE would likely require post-selection tweaks to achieve IND-CCA2 security.” Recent work suggested that roughly a 9% increase in block size would give a sufficiently low DFR at level 1 (for example, raising the level 1 block length from r = 12,323 to r = 13,477 for a conservative estimate near 2 to the power of negative 129.5), but that fix arrived as a proposed adjustment, not a settled analysis.
By contrast, HQC’s DFR estimates stayed stable across the entire process and its IND-CCA2 security hadn’t been successfully attacked since 2020. NIST’s summary judgment: “NIST found the security analysis of HQC to be more mature and stable than that of BIKE. As such, NIST has not selected BIKE for standardization.” This wasn’t a claim that BIKE is broken. It’s that a backup standard has to be something NIST is highly confident in, and the confidence bar is exactly where BIKE fell short.
Source: NIST IR 8545, §3.1 and §3.2, March 2025.
What are BIKE’s parameter sets and sizes?
BIKE defines three parameter sets targeting NIST security categories 1, 3, and 5. The sizes below are the figures NIST published in the fourth-round report, in bytes. These are the candidate’s numbers, not a finalized FIPS, because BIKE was never standardized.
| Parameter set | NIST category | Public key | Secret key | Ciphertext |
|---|---|---|---|---|
| BIKE Level 1 | 1 | 1,541 bytes | 281 bytes | 1,573 bytes |
| BIKE Level 3 | 3 | 3,083 bytes | 419 bytes | 3,115 bytes |
| BIKE Level 5 | 5 | 5,122 bytes | 580 bytes | 5,154 bytes |
Source: NIST IR 8545, Table 6, March 2025.
The thing to internalize is that these are compact for a code-based scheme. BIKE’s public keys and ciphertexts run a couple of kilobytes at the low security level, far below Classic McEliece’s hundreds of kilobytes, and even smaller than HQC’s. That compactness was BIKE’s headline advantage, and it’s why the race between BIKE and HQC was genuinely close on paper.
How does BIKE compare to HQC?
BIKE and HQC are close cousins that were the two finalists for the code-based backup slot, and the comparison is what makes NIST’s decision legible. BIKE is smaller on the wire, HQC is faster to compute, and HQC’s security analysis is the more settled of the two, which is the property that decided it.
| Property | BIKE | HQC |
|---|---|---|
| Code type | QC-MDPC (bit-flipping decoder) | Concatenated Reed-Muller and Reed-Solomon codes |
| Key and ciphertext size | Smaller (roughly 70% of HQC’s public key, 30% of its ciphertext) | Larger |
| Speed | Slower key generation and decapsulation | Roughly 5-6 times faster on those steps |
| DFR analysis | Stayed an open problem through round 4 | Stable across the whole process |
| NIST IND-CCA2 confidence | Lower | Higher |
| Outcome | Not selected | Selected March 11, 2025 as the code-based backup |
Source: NIST IR 8545, §3.1, §3.2, and Table 6, March 2025.
NIST was candid that on raw performance the two were hard to separate: it “was unable to make a definitive assessment as to which performance profile is better” and found either “would be acceptable for most general applications.” BIKE’s smaller messages are a real edge for bandwidth-constrained links, and studies even found BIKE beating HQC in TLS handshakes under lossy network conditions. The deciding factor lived entirely in the security analysis, not the benchmarks. When two candidates are close on cost and one has a settled failure-rate story while the other doesn’t, the settled one is the responsible pick for something meant to be a fallback the world can trust for decades.
Is BIKE dead, or can I still use it?
BIKE isn’t a NIST standard and isn’t on a standards track, so for practical migration decisions it sits outside the plan. NIST was explicit that non-selected algorithms “are not under consideration for standardization by NIST as part of the current NIST PQC Standardization Process.” That means BIKE has no FIPS to validate against, and it should never anchor a compliance requirement or a procurement clause. The code-based option that belongs on a roadmap is HQC, as the tracked backup to ML-KEM.
Source: NIST IR 8545, §3.1, March 2025.
BIKE the research object is very much alive. Its team continues to refine the decoder and the DFR analysis, implementations exist in libraries like the Open Quantum Safe project, and the QC-MDPC line remains an active area of study. The honest framing is that BIKE is a strong design that lost a close finalist race on one specific, decisive criterion, and understanding why is useful for grasping how NIST actually weighs a candidate. Deploying it as if it were a standard is a different thing, and that’s the mistake to avoid.
Common misconceptions
“BIKE is a NIST post-quantum standard.” It isn’t. BIKE was a fourth-round candidate that NIST studied and did not select. The code-based algorithm NIST chose is HQC, announced March 11, 2025.
“NIST rejected BIKE because it was broken.” BIKE was never practically broken as a cryptosystem. NIST didn’t select it because its decoding-failure-rate analysis stayed uncertain through the round, and a provably low DFR is required for the strong IND-CCA2 security a general-purpose KEM needs.
“BIKE lost because it was slower or bigger.” The opposite on size. BIKE’s keys and ciphertexts are smaller than HQC’s, and it beats HQC on some network conditions. The decision turned on the maturity of the security analysis, where HQC was the more settled of the two.
“BIKE and HQC are basically the same, so it doesn’t matter which won.” They share the broad code-based family and were close finalists, but they use different codes and decoders. BIKE’s iterative bit-flipping decoder is exactly what made its failure rate hard to bound, which is the difference that decided the outcome.
Source: NIST IR 8545, March 2025.
“Since BIKE is code-based, it can do signatures too.” No. BIKE is a KEM, so it handles key establishment and confidentiality only. Signatures are the job of ML-DSA, SLH-DSA, and their siblings.
Questions people ask
Is BIKE a finalized standard? No. BIKE was a fourth-round candidate in the NIST process and was not selected for standardization. There’s no FIPS for BIKE and no draft on a NIST standards track, so it can’t be the basis of a compliance requirement.
Why did NIST pick HQC over BIKE? Because HQC’s decoding-failure-rate analysis was stable across the whole process while BIKE’s remained an open problem, and a low, well-understood DFR is what a general-purpose KEM needs for strong (IND-CCA2) security. NIST called HQC’s stable DFR analysis “the decisive factor” and judged HQC’s overall security analysis more mature.
What is a decoding failure rate and why did it matter so much? It’s the probability that decapsulation fails to recover the right secret, across all keys and messages. BIKE reaches strong security only if that rate is provably tiny, and its iterative bit-flipping decoder is hard to analyze precisely, so the true rate stayed uncertain. That uncertainty, including weak-key classes that pushed the rate high enough to defeat security, is what NIST couldn’t get comfortable with.
Is BIKE broken or insecure? It was never practically broken as a cryptosystem. The issue was confidence in the failure-rate analysis, not a working attack that recovers keys. “Not selected” is a statement about assurance for a standard, not a verdict that BIKE is unsafe to study or experiment with.
How does BIKE compare to Classic McEliece? Both are code-based KEMs that NIST studied and didn’t standardize, but their profiles are opposite. BIKE uses QC-MDPC codes and has small keys with a decoder-failure question; Classic McEliece uses binary Goppa codes, has perfect correctness and no failure-rate problem, but carries a very large public key that most protocols can’t ship.
Can I still use BIKE in code? Implementations exist in research libraries like Open Quantum Safe, so you can experiment with it, but you shouldn’t deploy it as a production or compliance choice. For a code-based option that’s actually on the standards track, track HQC instead.
Does BIKE protect against a quantum computer? Its underlying hard problem, decoding a random quasi-cyclic code, has no known efficient quantum attack, so the math is quantum-resistant in the same sense as the rest of the code-based family. That quantum resistance was never the reason BIKE lost. The failure-rate analysis was.
Should the fact that BIKE wasn’t selected change my migration plan? No. Deploy ML-KEM now as the finalized default, and keep HQC on the roadmap as the code-based backup. BIKE simply isn’t part of the plan, and building crypto-agility is what lets a chosen backup slot in cleanly when it’s final.
BIKE is the close runner-up in the code-based race, worth understanding precisely because the reason it lost, an unsettled failure-rate analysis rather than a broken cipher, is exactly how a standards body separates a good design from a trusted one. Everything here is the map, given freely. When your team needs the post-quantum standards turned into a migration sequenced against your own systems, that’s the work I do, and there’s an alignment briefing for it.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.