Key Encapsulation
FrodoKEM
Frodo Key Encapsulation Mechanism
non-FIPSlattice-based3 parameter setsQNSP tier: maximum+provider: liboqsalso called: Frodo
Plain Learning With Errors (LWE) KEM — same lattice family as ML-KEM but without the additional ring or module structure. Larger keys and ciphertexts but built on the most conservative lattice assumption.
Mechanism
How it works
FrodoKEM operates on plain LWE (no ring / module structure), avoiding any potential structural cryptanalysis advances against ring-LWE / module-LWE. The trade-off is significantly larger parameters. Two hash function variants (AES, SHAKE) × three security categories.
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 |
|---|---|---|---|---|---|
| FrodoKEM-640-AES / SHAKE | L1 | 9,616 B | 19,888 B | 9,720 B | |
| FrodoKEM-976-AES / SHAKE | L3 | 15,632 B | 31,296 B | 15,744 B | |
| FrodoKEM-1344-AES / SHAKE | L5 | 21,520 B | 43,088 B | 21,632 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.
Use Cases
When to use it
- Customers requiring plain-LWE assumption (no module structure)
- Conservative lattice-based fallback under defence-in-depth policies
Trade-offs
What you give up, what you get
- ~10x larger keys and ciphertexts than ML-KEM at equivalent security levels
- Most conservative lattice assumption available
References