BIKE and HQC Explained: Why NIST Kept These Post-Quantum Algorithms as Backup in 2026

What Problem Do BIKE and HQC Solve?

Classic McEliece has a 45-year security track record but requires 524,160-byte public keys for 128-bit security. ML-KEM-512 provides 128-bit security with 800-byte public keys. The gap is 655x. BIKE and HQC are code-based key encapsulation mechanisms that attempt to close this gap by using quasi-cyclic codes instead of random Goppa codes, at the cost of introducing algebraic structure that requires additional cryptanalysis.

Both schemes were submitted to NIST's post-quantum standardization process and advanced to Round 4 (announced March 2022) as backup candidates. They are not yet standardized. NIST is continuing evaluation to determine whether they will receive a formal standard, with publication expected in the 2025 to 2027 timeframe. They represent the most viable path to code-based post-quantum cryptography with practical key sizes.

For context on where these schemes sit in the broader standardization landscape, the NIST PQC standards implementation guide covers the primary standards (ML-KEM, ML-DSA, SLH-DSA) and the relationship between primary and backup candidates.

BIKE: Bit Flipping Key Encapsulation

BIKE (Bit Flipping Key Encapsulation) is based on quasi-cyclic moderate density parity check (QC-MDPC) codes. QC-MDPC codes have a parity check matrix with a specific quasi-cyclic structure: the matrix consists of circulant blocks, where each block is a cyclic rotation of a single row. This structure allows the entire matrix to be described by one row per block, dramatically reducing the key size.

BIKE's security reduces to two problems: the decoding problem for QC-MDPC codes, and the syndrome decoding problem for quasi-cyclic codes. The quasi-cyclic structure is what enables small keys. It is also what introduces algebraic structure that might be exploitable.

BIKE uses a two-key construction: public and private keys each consist of two circulant polynomials. The public key is compact: for BIKE-L1 (128-bit security), the public key is 1,541 bytes. The ciphertext is 1,573 bytes. Compare this to McEliece-460896's 524,160-byte public key and 188-byte ciphertext. BIKE's total transmission cost (public key plus ciphertext) is 3,114 bytes vs McEliece's 524,348 bytes.

BIKE Parameter Sets and Security Levels

BIKE defines three security levels:

• BIKE-L1: NIST Level 1 (128-bit classical security). Public key: 1,541 bytes. Ciphertext: 1,573 bytes. Private key: 281 bytes.
• BIKE-L3: NIST Level 3 (192-bit classical security). Public key: 3,083 bytes. Ciphertext: 3,115 bytes. Private key: 417 bytes.
• BIKE-L5: NIST Level 5 (256-bit classical security). Public key: 5,122 bytes. Ciphertext: 5,154 bytes. Private key: 580 bytes.

BIKE uses a Black-Gray-Flip decoder for error correction. The decoder is probabilistic: it has a nonzero decryption failure rate (DFR) on the order of 2^-128 for the BIKE-L1 parameter set. This DFR must be accounted for in security proofs, and it creates a subtle security concern: an adversary who can trigger and observe decryption failures might extract information about the private key. BIKE's current submission addresses this through a transform that converts the scheme to IND-CCA2 security even in the presence of decryption failures.

HQC: Hamming Quasi-Cyclic

HQC (Hamming Quasi-Cyclic) is based on the hardness of decoding random quasi-cyclic codes in the Hamming metric. The Hamming metric measures code distance as the number of positions where two codewords differ, the standard metric in classical coding theory.

HQC's public key is a quasi-cyclic code description: two polynomials in the ring Z_2[x]/(x^n - 1) where n is chosen to be prime for the desired security level. Private key polynomials are sparse (low Hamming weight), which enables efficient decoding. Public key polynomials are random-looking, which prevents an attacker from recovering the sparse structure.

HQC parameter sets:

• HQC-128: NIST Level 1 (128-bit security). Public key: 2,249 bytes. Ciphertext: 4,497 bytes. Private key: 40 bytes.
• HQC-192: NIST Level 3. Public key: 4,481 bytes. Ciphertext: 8,961 bytes. Private key: 40 bytes.
• HQC-256: NIST Level 5. Public key: 7,245 bytes. Ciphertext: 14,469 bytes. Private key: 40 bytes.

HQC has larger ciphertexts than BIKE and ML-KEM but has a cleaner security reduction to the quasi-cyclic syndrome decoding problem. It also achieves a negligible decryption failure rate by design, unlike BIKE which manages DFR through parameterization. The private key is remarkably small (40 bytes) because it is just two sparse polynomial seeds.

IND-CCA2 Security and Why It Matters

IND-CCA2 (Indistinguishability under Chosen Ciphertext Attack 2) is the standard security model for key encapsulation mechanisms. An IND-CCA2 secure KEM remains secure even if an adversary can submit arbitrary ciphertexts for decryption and observe the results, subject to not submitting the challenge ciphertext itself.

This security level is necessary for any KEM used in practice. An IND-CPA secure scheme (secure against passive adversaries only) is not sufficient for TLS or any protocol where an active adversary can trigger decryption operations. Both BIKE and HQC claim IND-CCA2 security via the Fujisaki-Okamoto transform, which converts IND-CPA secure schemes to IND-CCA2 by adding a hash check on the decrypted message.

For BIKE, the FO transform requires that the decryption failure rate be negligible to avoid known attacks. The 2020 paper by Guo, Johansson, and Nilsson demonstrated that non-negligible DFR in BIKE allows key recovery attacks. The current BIKE specification uses parameters where the DFR is below 2^-128, which makes the attack infeasible but required parameter increases from earlier rounds.

The Security Basis: Quasi-Cyclic Codes vs. Lattices

Understanding why BIKE and HQC offer different security guarantees from ML-KEM requires understanding what makes their hardness assumptions distinct at a mathematical level.

ML-KEM (CRYSTALS-Kyber) bases its security on the Module Learning With Errors (Module-LWE) problem over polynomial rings. This problem has been studied since 2005 and has security reductions to worst-case lattice problems via Ajtai's foundational 1996 work. The security analysis benefits from decades of lattice geometry research. A detailed primer on lattice cryptography explains why these problems resist quantum attacks.

BIKE and HQC base their security on the hardness of decoding quasi-cyclic linear codes — specifically the QC-MDPC decoding problem for BIKE and the quasi-cyclic syndrome decoding problem for HQC. These problems are in the family of syndrome decoding problems, which have been studied since the 1970s under the NP-hardness results of Berlekamp, McEliece, and van Tilborg.

The critical difference is structure. McEliece's original random Goppa codes have no algebraic structure beyond what is needed for efficient decoding. Quasi-cyclic codes introduce cyclic symmetry specifically to reduce key sizes. That symmetry also creates a potential attack surface: algebraic attacks that exploit the cyclic structure have been attempted and must be accounted for in the security analysis.

The quasi-cyclic syndrome decoding problem is believed to be NP-hard in general, but its quasi-cyclic instances may be easier than worst-case instances. This is the key uncertainty: the security of BIKE and HQC depends on the hardness of structured instances of code decoding, not worst-case instances. ML-KEM's security reduces to worst-case lattice problems, which is a stronger guarantee.

No efficient quantum algorithm is known for quasi-cyclic syndrome decoding. Grover's algorithm provides a generic quadratic speedup for any search problem, but for the specific structure of QC-MDPC and QC-LDPC codes, no better quantum algorithm has been found. The information-set decoding attacks that historically drove McEliece parameter selection apply to quasi-cyclic codes with modifications, but current attack estimates still require quantum effort above 2^128 for the NIST Level 1 parameters.

See also the Classic McEliece deep dive for a full treatment of code-based cryptographic security history and why the 45-year track record matters for evaluating the code-based family as a whole.

NIST Round 4 Status: Where the Standardization Process Stands

NIST announced its Round 4 selections in March 2022, keeping BIKE, HQC, and Classic McEliece as backup candidates for key encapsulation. This was a deliberate decision to maintain algorithmic diversity beyond the lattice-based primary standard (then CRYSTALS-Kyber, now ML-KEM).

The rationale stated in NIST's Round 4 announcement is specific: BIKE and HQC were not advanced to primary standards because "the security of these systems is somewhat less well understood than the lattice-based schemes," and because their security arguments involve structured code instances whose hardness is not as thoroughly mapped as Module-LWE. They are backup candidates, not failed candidates.

NIST's evaluation of Round 4 candidates continued after the primary standards were finalized in August 2024. As of 2026, NIST has not announced a final decision on whether BIKE or HQC will receive a formal standard. The evaluation covers three areas: continued cryptanalysis of the hardness assumptions, implementation security (side-channel resistance), and performance benchmarking across hardware profiles.

Key milestones in the Round 4 timeline:

• March 2022: NIST announces Round 4 with BIKE, HQC, and Classic McEliece as backup KEM candidates.
• August 2024: NIST finalizes primary standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA).
• 2025–2026: NIST continues Round 4 evaluation. No final decision on backup candidate standardization announced.
• 2026–2027 (expected): NIST expected to publish a decision on Round 4 candidates — either a formal standard, an informational publication, or a statement that the primary standards are sufficient.

The practical implication for implementers: BIKE and HQC are not yet standards. Production systems requiring standards compliance should use ML-KEM. Systems designing for cryptographic agility should implement the KEM abstraction layer so that BIKE or HQC can be added when standardized without re-architecting the key management layer.

Why BIKE and HQC Are Backup Candidates, Not Primary Standards

NIST's rationale for keeping BIKE and HQC as backup candidates rather than advancing them to primary standards in the first wave is explicitly stated in the Round 4 announcement: "the security of these systems is somewhat less well understood than the lattice-based schemes."

Lattice-based schemes (ML-KEM, ML-DSA) have security reductions to worst-case lattice problems that have been studied since the 1980s. The Module-LWE problem underlying ML-KEM has been analyzed by hundreds of researchers over more than a decade. The algebraic structure of quasi-cyclic codes in BIKE and HQC has been analyzed for a shorter period, and the attack surface introduced by that structure is less thoroughly mapped.

Additionally, BIKE's DFR-related attack history and the requirement to bound the failure rate carefully add complexity to security arguments that ML-KEM does not have. ML-KEM has a negligible decryption failure rate by construction, not by parameterization.

Detailed Parameter Comparison: BIKE, HQC, and ML-KEM Side by Side

The following table provides a complete comparison across all three security levels for BIKE, HQC, and ML-KEM, plus Classic McEliece for reference. All sizes are in bytes.

Several observations from the data. ML-KEM dominates on both public key size and ciphertext size at every security level: BIKE-L1 requires 3,114 bytes total (PK + CT) versus ML-KEM-512's 1,568 bytes, and HQC-128 requires 6,746 bytes versus ML-KEM-512's 1,568 bytes. HQC has an unusually small private key (40 bytes at all levels) because it stores only two sparse polynomial seeds. BIKE's private key grows with security level because it stores the full sparse polynomial representation. McEliece's numbers put BIKE and HQC in perspective: both are vastly more bandwidth-efficient than McEliece while being somewhat larger than ML-KEM.

Relevance for Blockchain and Post-Quantum Migration

BIKE and HQC are not yet standardized, so production blockchain deployments should use ML-KEM for key encapsulation and ML-DSA for transaction signing today. However, a cryptographically agile blockchain architecture should design its key management layer to accommodate future code-based KEMs if NIST standardizes BIKE or HQC.

Concretely, this means: key registration transactions should include a version byte that identifies the KEM algorithm, so nodes can begin advertising BIKE-L1 or HQC-128 public keys alongside ML-KEM-768 keys when those standards finalize. Transport-layer encryption should use negotiated algorithm identifiers so peers can use the best mutually supported scheme.

For on-chain signing (transaction authorization), ML-DSA remains the correct choice regardless of what happens with code-based KEMs, because BIKE and HQC are key encapsulation mechanisms, not signature schemes. The distinction between signing and key exchange is discussed in detail in the ML-KEM explainer. Designing for cryptographic agility now avoids hard migrations later when the standardization landscape evolves.

Key Takeaways: BIKE and HQC as NIST Backup Candidates

BIKE and HQC are NIST Round 4 backup candidates for post-quantum key encapsulation, based on quasi-cyclic code decoding hardness. BIKE-L1 achieves 1,541-byte public keys (vs McEliece's 524KB) by using QC-MDPC codes. HQC-128 uses 2,249-byte public keys with a cleaner decryption failure rate profile. Neither is yet standardized. Both are smaller than McEliece but larger than ML-KEM-512 (800 bytes). Their role is to provide algorithmic diversity beyond lattice-based schemes. Production deployments should use ML-KEM today and design for BIKE or HQC as a future backup layer when NIST completes standardization.

Frequently Asked Questions

What are BIKE and HQC, and how do they differ from ML-KEM?

BIKE (Bit Flipping Key Encapsulation) and HQC (Hamming Quasi-Cyclic) are code-based key encapsulation mechanisms that derive security from the hardness of decoding quasi-cyclic linear codes. ML-KEM derives security from the Module Learning With Errors (Module-LWE) lattice problem. The fundamental difference is mathematical family: code-based vs. lattice-based. Both resist Shor's algorithm, but through entirely different mathematical structures. BIKE and HQC are NIST Round 4 backup candidates; ML-KEM is a finalized FIPS 203 standard. For production use today, ML-KEM is the correct choice.

What is NIST Round 4, and does it mean BIKE and HQC are nearly standardized?

NIST Round 4 is the final evaluation phase for backup KEM candidates, announced in March 2022. "Round 4" does not mean imminent standardization — it means NIST is conducting deeper analysis to determine if formal standards are warranted. The three primary standards (ML-KEM, ML-DSA, SLH-DSA) were finalized in August 2024. A decision on Round 4 candidates has not been announced as of 2026. NIST may publish formal standards for BIKE and HQC, informational publications, or conclude that the primary standards are sufficient. Do not treat Round 4 status as equivalent to standardization.

Why does BIKE have a decryption failure rate, and does it affect security?

BIKE's Black-Gray-Flip decoder is a probabilistic algorithm. For BIKE-L1 parameters, there is roughly a 2^-128 probability that decryption fails on a legitimate ciphertext — meaning one in every 340 undecillion decryptions will fail. This nonzero failure rate creates a subtle security concern: an adversary who can observe decryption failures and control ciphertext inputs could potentially extract private key information via a reaction attack. The 2020 Guo-Johansson-Nilsson attack demonstrated this. Current BIKE parameters are chosen to make the DFR small enough to close this attack, but it requires careful parameterization that ML-KEM's negligible DFR does not require.

Are BIKE and HQC safe to deploy in production today?

Not for compliance-sensitive production deployments. BIKE and HQC are under active evaluation and have not been finalized as NIST standards. Organizations requiring standards-backed post-quantum key exchange must use ML-KEM (FIPS 203). BIKE and HQC are appropriate for research implementations, gaining implementation experience, or applications that explicitly want code-based cryptographic diversity alongside lattice-based ML-KEM as an additional defensive layer. Any dual-algorithm deployment should treat ML-KEM as the primary and BIKE/HQC as supplemental.

Why might a blockchain architect choose BIKE or HQC over ML-KEM in the future?

The primary motivation is cryptographic diversity across mathematical hardness assumptions. A deployment running both ML-KEM and BIKE-L1 (or HQC-128) simultaneously has defense in depth: a breakthrough against Module-LWE does not compromise the code-based layer, and vice versa. NIST and ENISA both recommend deploying multiple algorithm families for high-assurance, long-lived applications. For blockchain transport security (node-to-node TLS), a dual-KEM configuration — ML-KEM-768 as primary, BIKE-L1 as backup — would be the likely architecture once BIKE is standardized. The bandwidth overhead (3,114 bytes for BIKE-L1 vs 2,272 bytes for ML-KEM-768) is marginal for transport handshakes.