wolfSSL is pleased to announce support for FrodoKEM in wolfCrypt. FrodoKEM joins ML-KEM (FIPS 203), ML-DSA (FIPS 204), LMS/HSS and XMSS/XMSS^MT in our growing post-quantum portfolio, and it fills a specific gap: a conservative, unstructured-lattice KEM for users who want their quantum-safe key exchange to rest on a different hardness assumption.
Why FrodoKEM?
ML-KEM is fast because it is built on module lattices, an algebraic structure that makes the arithmetic cheap and the keys small. That same structure is extra surface for a cryptanalyst to attack: should someone find a way to exploit it, the structured lattice schemes are exposed together. FrodoKEM is designed without it. Its security rests on plain Learning With Errors over generic matrices, with no ring or module structure at all. Keys and ciphertexts are an order of magnitude larger and the operations cost more, that is the price of the assumption, paid deliberately.
Where FrodoKEM is allowed
FrodoKEM is not a NIST algorithm, it was a round-3 alternate candidate and is not part of FIPS 203. It is, however, an approved or recommended option in a number of standards and national guidelines, and that is where wolfSSL customers keep asking for it:
- ISO/IEC 18033-2 – FrodoKEM is standardized as an asymmetric encryption mechanism in ISO/IEC 18033-2:2006/Amd 2. wolfSSL’s key and certificate encoding uses the object identifiers from that arc (1.0.18033.2.2.7.x).
- BSI TR-02102-1 (Germany) – the BSI assesses FrodoKEM-976 and FrodoKEM-1344 as suitable for protecting confidential information on a long-term basis. They are one of the two post-quantum KEM families the BSI recommends for long-term confidentiality, alongside Classic McEliece.
- ANSSI (France) – ANSSI’s post-quantum transition position papers name FrodoKEM as a valid, conservative option for high-assurance applications, accepting the performance cost for the unstructured-lattice assumption.
- IETF CFRG – the specification wolfCrypt implements, draft-longa-cfrg-frodokem, is the CFRG Internet-Draft of the ISO variant.
It is the natural second algorithm in a hybrid or belt-and-braces deployment, and the natural first choice for long-lived secrets that must stay secret for decades.
What’s in the implementation
wolfCrypt implements the FrodoKEM specification from draft-longa-cfrg-frodokem-03 (the ISO/CFRG salted variant), covering all twelve variants:
- Three parameter sets – FrodoKEM-640, -976 and -1344, targeting NIST security categories 1, 3 and 5 (128-, 192- and 256-bit shared secrets).
- Two matrix-A generation methods – SHAKE-128 and AES-128, independently selectable at build time.
- Both flavours – standard, salted FrodoKEM, and eFrodoKEM, the ephemeral, salt-less variant for key-exchange-only use.
| Parameter set | Public key | Private key | Ciphertext |
|---|---|---|---|
| FrodoKEM-640 | 9,616 B | 19,888 B | 9,752 B |
| FrodoKEM-976 | 15,632 B | 31,272 B | 15,792 B |
| FrodoKEM-1344 | 21,520 B | 43,056 B | 21,696 B |
Beyond the raw KEM operations, this release includes:
- ASN.1 key encoding – PKCS#8 private keys and SubjectPublicKeyInfo public keys, DER and PEM, using the ISO/IEC 18033-2 OID arc (1.0.18033.2.2.7.x). That arc assigns identifiers to the 976 and 1344 sets, the BSI-recommended ones, in both SHAKE and AES flavours, FrodoKEM and eFrodoKEM.
- X.509 support – FrodoKEM public keys can be carried in certificates and PKCS#10 requests (signed, as any KEM must be, by a signing key such as ECDSA or ML-DSA). Test material ships in certs/frodokem/.
- Crypto callback support, so FrodoKEM operations can be offloaded to hardware or an external module via devId.
- Deterministic entry points (wc_FrodoKemKey_MakeKeyWithRandom,wc_FrodoKemKey_EncapsulateWithRandom) for testing and KAT validation.
Fast, on every platform we support
FrodoKEM is the expensive one of the lattice KEMs, so we did not settle for a portable-C implementation. wolfCrypt ships hand-written assembly for the matrix arithmetic, the Gaussian sampler and the matrix-A generation, selected at run time from CPU feature detection:
- x86-64: AVX2 and AVX-512, including a new 8-way AVX-512 Keccak permutation for SHAKE-based generation, and a fused VAES AES-128-ECB matrix generator for the AES-based variants.
- AArch64: NEON, with optional SVE and SME acceleration, plus the Armv8 crypto extensions for the AES variants. Windows on ARM (armasm64) included.
- Armv7-A and Thumb-2: NEON and crypto-extension paths for 32-bit Arm.
Here is wolfCrypt’s own benchmark on an AMD Ryzen 9 9950X3D (./configure –enable-experimental –enable-frodokem=aes –enable-intelasm), in operations per second:
| Variant | Key gen | Encapsulate | Decapsulate |
|---|---|---|---|
| FrodoKEM-640 SHAKE | 4,727 | 4,416 | 4,650 |
| FrodoKEM-640 AES | 10,703 | 9,091 | 10,106 |
| FrodoKEM-976 SHAKE | 2,342 | 2,202 | 2,331 |
| FrodoKEM-976 AES | 5,430 | 4,872 | 5,555 |
| FrodoKEM-1344 SHAKE | 1,333 | 1,242 | 1,302 |
| FrodoKEM-1344 AES | 3,244 | 2,844 | 3,158 |
Compared on the same hardware, wolfSSL’s FrodoKEM is faster than other open source implementations on every parameter set, every variant and every operation we benchmarked.
Correctness is not traded for speed: all twelve variants are validated against the published FrodoKEM and eFrodoKEM known-answer test vectors, 1,200 vectors checked on public key, private key, ciphertext, shared secret and decapsulation, alongside wolfSSL’s own API, ASN.1 and X.509 test suites. Secret material is zeroized as soon as it is finished with, the noise sampler is constant time, and decapsulation’s implicit rejection is branch-free.
Small enough for embedded targets, too
FrodoKEM’s key sizes are large, so build-time control matters. Everything is individually selectable: enable only the parameter sets you need (–enable-frodokem-640/976/1344), only the operations you perform (–enable-frodokem-make-key/-encapsulate/-decapsulate, a device that only encapsulates need not carry key generation code), only SHAKE or only AES, and –enable-frodokem-small for a looped rather than unrolled matrix core when code size matters more than throughput. CMake mirrors every option.
If you have questions about any of the above, please contact us at facts@wolfSSL.com, +1 425 245 8247, or open an issue on GitHub. Download the latest wolfSSL from wolfssl.com or GitHub, and if you like what we’re doing, give us a star!
Download wolfSSL Now