Key Encapsulation
BIKE
Bit Flipping Key Encapsulation
non-FIPScode-based3 parameter setsQNSP tier: default+provider: liboqsalso called: Bit-Flipping KEM
Code-based KEM finalist (round 4 of NIST PQC standardisation) using QC-MDPC codes. Available in liboqs for QNSP customers seeking additional code-based alternatives.
Mechanism
How it works
BIKE uses Quasi-Cyclic Moderate Density Parity Check (QC-MDPC) codes. Decryption involves iterative bit-flipping decoders. Three parameter sets target NIST security categories 1, 3, and 5.
Parameter Sets
3 variants shipped
Each variant trades security category against key, ciphertext, or signature size. QNSP exposes all variants via the @cuilabs/liboqs-native binding; tenant crypto-policy determines which are allowed.
| Variant | NIST Level | Public Key | Secret Key | Ciphertext | Note |
|---|---|---|---|---|---|
| BIKE-L1 | L1 | 1,541 B | 5,223 B | 1,573 B | |
| BIKE-L3 | L3 | 3,083 B | 10,105 B | 3,115 B | |
| BIKE-L5 | L5 | 5,122 B | 16,494 B | 5,154 B |
NIST ACVP
Conformance evidence
QNSP runs the official NIST ACVP test vectors against every shipped algorithm. Live evidence + SHA-3-256 tamper digest at /verify/conformance.
@noble/post-quantum
non-addressablePure-JavaScript reference; cross-verification secondary on Maximum + Government tiers.
@cuilabs/liboqs-native
non-addressableNative-C primary production engine. Runs across every QNSP backend service.
Not selected for FIPS standardisation; no NIST ACVP vectors.
Use Cases
When to use it
- Customer workloads requiring code-based alternatives beyond HQC
- Research and migration analysis
Trade-offs
What you give up, what you get
- Secret keys are larger than HQC at equivalent security levels
- Not on the NIST PQC standardisation path — defer to HQC unless specific needs
References