FrodoKEM: Conservative Post-Quantum KEM

• FrodoKEM is an unstructured lattice-based post-quantum key encapsulation mechanism that uses plain LWE over matrices to offer high security.
• It avoids structured lattice shortcuts, resulting in larger keys, increased computation, and higher bandwidth compared to alternatives like Kyber.
• Hardware acceleration and protocol optimizations are explored to mitigate latency and resource costs, making it ideal for high-assurance deployments.

Searching arXiv for recent FrodoKEM papers to ground the article in published work. FrodoKEM is a post-quantum key encapsulation mechanism based directly on the Learning With Errors (LWE) problem over unstructured lattices. Within the lattice-based post-quantum cryptography landscape, it is routinely described as the conservative alternative to faster structured-lattice schemes such as Kyber and NTRU Prime: its design avoids ring and module structure, and therefore avoids reliance on ring-/module-LWE or NTRU-like assumptions, but pays a substantial cost in computation, key size, ciphertext size, and network sensitivity (Ünsal, 7 Aug 2025). Subsequent work has treated it both as a high-assurance deployment option and as a reference point for non-ideal, non-structured post-quantum design, including TLS evaluations, side-channel analyses, error-correction refinements, updatable encryption constructions, and dedicated hardware accelerators (Henrich, 2023).

1. Position in the post-quantum cryptography landscape

FrodoKEM is a lattice-based KEM whose security is based on plain LWE over matrices with integer entries modulo $q$, rather than on structured variants such as ring-LWE or module-LWE. This distinction is central to its identity: the scheme is presented as a conservative construction that uses unstructured lattices and does not depend on rings, modules, or cyclotomic fields (Ünsal, 7 Aug 2025). In comparative discussions, Kyber is treated as the high-performance module-LWE option, sntrup761 as a structured NTRU Prime option, and FrodoKEM as the “high-security / conservative assumption” option.

This conservative positioning has shaped both its standardization role and its deployment narrative. One comparative study notes that Kyber was selected by NIST as a primary KEM, whereas FrodoKEM and sntrup761 continue to be evaluated in alternate categories and remain valuable candidates for niche use cases or backup algorithms (Ünsal, 7 Aug 2025). A later hardware study states that FrodoKEM is being incorporated into ISO/IEC 18033-2 and is endorsed by BSI and ANSSI, presenting it as attractive to regulators specifically because of its robust, unstructured-LWE security profile (Li et al., 23 Jan 2026).

A recurrent theme in the literature is that FrodoKEM occupies a “maximum confidence, lower efficiency” corner of the design space. The NIST-oriented TLS study describes it as especially suitable when high trust in security is required, while warning that systems dependent on high performance, such as TLS servers, can be negatively affected by the required computations and large transmitted data (Henrich, 2023). This suggests that FrodoKEM is best understood not as a universal default, but as a portfolio component for settings where conservative assumptions are valued more highly than throughput or latency.

2. LWE formulation, protocol structure, and parameterization

At the conceptual level, FrodoKEM inherits the standard LWE form

$$(\mathbf{a}_i,\; b_i = \langle \mathbf{a}_i,\mathbf{s}\rangle + e_i \bmod q),$$

with uniformly random public vectors, a secret vector over $\mathbb{Z}_q$, and small error terms. In FrodoKEM this is lifted to matrices: a public matrix $A$, small secret and error matrices, and noisy linear relations over $\mathbb{Z}_q$ (Ünsal, 7 Aug 2025). A conceptual key-generation description writes

$B = A S + E \pmod q,$

while implementation-oriented descriptions of the standardized scheme use the same matrix-LWE core with notation such as

$$\mathbf{B} = \mathbf{A}\mathbf{S} + \mathbf{E} \pmod q.$$

Encapsulation and decapsulation are then built from fresh noisy matrix products and an encoding/decoding layer for the ephemeral secret (Ünsal, 7 Aug 2025, Li et al., 23 Jan 2026).

Two properties dominate the implementation consequences of this formulation. First, FrodoKEM uses full matrices and generic LWE rather than polynomial rings or modules. Second, it has no NTT-based acceleration path; the large matrix multiplications $\mathbf{A}\mathbf{S}$, $\mathbf{S}'\mathbf{A}$, $\mathbf{S}'\mathbf{B}$, and $$(\mathbf{a}_i,\; b_i = \langle \mathbf{a}_i,\mathbf{s}\rangle + e_i \bmod q),$$0 are therefore the dominant computational kernels (Ünsal, 7 Aug 2025, Li et al., 23 Jan 2026).

The parameter sets emphasized in recent implementation work are the standard security levels 640, 976, and 1344. A hardware-oriented specification report gives the following parameters (Li et al., 23 Jan 2026):

Parameter set	$$(\mathbf{a}_i,\; b_i = \langle \mathbf{a}_i,\mathbf{s}\rangle + e_i \bmod q),$$1	Correspondence
FrodoKEM-640	$$(\mathbf{a}_i,\; b_i = \langle \mathbf{a}_i,\mathbf{s}\rangle + e_i \bmod q),$$2	NIST security level 1
FrodoKEM-976	$$(\mathbf{a}_i,\; b_i = \langle \mathbf{a}_i,\mathbf{s}\rangle + e_i \bmod q),$$3	NIST security level 3
FrodoKEM-1344	$$(\mathbf{a}_i,\; b_i = \langle \mathbf{a}_i,\mathbf{s}\rangle + e_i \bmod q),$$4	NIST security level 5

In TLS-oriented experiments, the SHAKE variants frodo640shake, frodo976shake, and frodo1344shake were used; the same study notes that AES-based A-matrix generation also exists, but was not evaluated there (Henrich, 2023). In side-channel analysis, these same parameter sets are described through the message-embedding dimensions $$(\mathbf{a}_i,\; b_i = \langle \mathbf{a}_i,\mathbf{s}\rangle + e_i \bmod q),$$5 and the number of encoded bits per coefficient $$(\mathbf{a}_i,\; b_i = \langle \mathbf{a}_i,\mathbf{s}\rangle + e_i \bmod q),$$6, yielding message lengths $$(\mathbf{a}_i,\; b_i = \langle \mathbf{a}_i,\mathbf{s}\rangle + e_i \bmod q),$$7, $$(\mathbf{a}_i,\; b_i = \langle \mathbf{a}_i,\mathbf{s}\rangle + e_i \bmod q),$$8, and $$(\mathbf{a}_i,\; b_i = \langle \mathbf{a}_i,\mathbf{s}\rangle + e_i \bmod q),$$9 bits respectively (Berthet, 2024).

3. Empirical performance and system-level behavior

A direct comparative evaluation of Kyber512, FrodoKEM, and sntrup761 in a Python testbed measured key generation, encryption, and decryption over 400 iterations on Windows 11 with an Intel Core i5 13th Gen and 16 GB RAM. FrodoKEM recorded mean times of $\mathbb{Z}_q$0 ms for key generation, $\mathbb{Z}_q$1 ms for encryption, and $\mathbb{Z}_q$2 ms for decryption, with standard deviations $\mathbb{Z}_q$3, $\mathbb{Z}_q$4, and $\mathbb{Z}_q$5 respectively (Ünsal, 7 Aug 2025). In the same testbed, these numbers translated into roughly $\mathbb{Z}_q$6 slower key generation than Kyber512, nearly $\mathbb{Z}_q$7 slower encryption, and almost $\mathbb{Z}_q$8 slower decryption; relative to sntrup761, key generation was about $\mathbb{Z}_q$9 slower and encapsulation/decapsulation about $A$0 slower (Ünsal, 7 Aug 2025).

The same study attributes this gap directly to FrodoKEM’s unstructured-LWE design. Large matrix multiplications must be carried out without structural FFT/NTT optimizations, and this produces what the paper characterizes as significantly higher computational costs in all operations (Ünsal, 7 Aug 2025). The paper therefore frames FrodoKEM as practical mainly when strong resistance is prioritized over performance, and as problematic for latency-sensitive applications.

A second, protocol-level evaluation shows that raw computation is only part of the story. In TLS 1.3 experiments using OQS-OpenSSL 1.1.1 and NGINX over emulated network conditions, FrodoKEM is singled out as especially data-intensive, with large public keys and ciphertexts interacting unfavorably with bandwidth limits, packet loss, TCP slow start, MTU fragmentation, and congestion control (Henrich, 2023). Under a very good baseline network of 500 Mbit/s and delay of about $A$1 ms, FrodoKEM is only moderately slower than competing schemes in absolute terms, but degradation begins to dominate once the network is impaired.

The TLS study makes the sensitivity concrete. At security level 1 and client upload rate 100 Kbit/s, frodo640shake has median handshake time above $A$2 s. At higher levels, delay sensitivity becomes much more pronounced: for example, with an added $A$3 ms packet delay, FrodoKEM-976 reaches a median handshake latency of about $A$4 ms, roughly twice that of ECDH, Kyber, Saber, or NTRU in the same setting (Henrich, 2023). Packet loss also affects FrodoKEM earlier than competing lattice KEMs: frodo640shake shows a visibly earlier rise in median handshake time already around $A$5–$A$6 packet loss, and the higher-security FrodoKEM variants deteriorate sharply beyond $A$7–$A$8 loss (Henrich, 2023).

These measurements support a recurrent interpretation in the literature: FrodoKEM’s practical performance is determined not only by arithmetic cost but also by message volume. This suggests that the scheme’s “conservative security” advantage must be evaluated jointly with transport behavior in real protocols, especially for Internet-facing systems.

4. Implementations, hardware acceleration, and deployment engineering

Because FrodoKEM’s dominant operations are large unstructured matrix multiplications, hardware design has focused on scheduling, multiplier organization, and memory traffic rather than on transform-based acceleration. A 2026 FPGA crypto-processor implements all three security levels and all protocol phases in a single instruction-driven architecture, with a Keccak/SHAKE hash unit, sampler, encode/decode unit, memory subsystem, and a reconfigurable parallel multiplier array (Li et al., 23 Jan 2026). The same work emphasizes three engineering problems: the cost of the matrix multiplications, the bandwidth and size of on-chip memory, and the need to support all protocol phases in one reconfigurable core.

The principal architectural optimizations are a multiple-instruction overlapped execution scheme, a DSP-free parallel multiplier array, and compact memory scheduling. In the overlapped execution scheme, SHAKE-based generation of future rows of $A$9 is pipelined with matrix multiplication using already generated rows; on Frodo-640 this reduces key-generation cycles from $\mathbb{Z}_q$0k to $\mathbb{Z}_q$1k, and similar ratios hold for encapsulation and decapsulation, yielding roughly a $\mathbb{Z}_q$2 speedup across parameter sets (Li et al., 23 Jan 2026). The multiplier array uses 32 parallel multipliers and 8 adder trees, with separate multiply-accumulate and multiply-add modes to match the distinct dataflows of $\mathbb{Z}_q$3, $\mathbb{Z}_q$4, $\mathbb{Z}_q$5, and $\mathbb{Z}_q$6.

On an Artix-7 FPGA, that design reports support for all FrodoKEM security levels and protocol phases while consuming 13467 LUTs, 6042 FFs, and 14 BRAMs, with the fastest reported execution time and an area-time product improvement of $\mathbb{Z}_q$7–$\mathbb{Z}_q$8 times over state-of-the-art hardware implementations (Li et al., 23 Jan 2026). Reported latencies are $\mathbb{Z}_q$9 ms, $B = A S + E \pmod q,$0 ms, and $B = A S + E \pmod q,$1 ms for Frodo-640 key generation, encapsulation, and decapsulation on Artix-7, and $B = A S + E \pmod q,$2 ms, $B = A S + E \pmod q,$3 ms, and $B = A S + E \pmod q,$4 ms on UltraScale+ (Li et al., 23 Jan 2026). Even the highest-security Frodo-1344 remains in the low-millisecond range.

These results materially change the deployment picture. They do not eliminate the algorithmic heaviness of FrodoKEM relative to structured-lattice KEMs, but they show that the matrix-based design can be engineered into a compact and practical accelerator. This suggests that FrodoKEM’s deployment limitations are more severe in software-only, bandwidth-constrained, or handshake-intensive settings than in hardware-assisted environments such as HSMs, secure gateways, and FPGA-equipped systems.

5. Security assumptions, side-channel issues, and recurrent misconceptions

The principal cryptographic rationale for FrodoKEM is the use of standard LWE over unstructured lattices. Comparative work repeatedly treats this as a conservative security choice: if future cryptanalysis finds that ring-/module-LWE or NTRU-like structures are easier than generic LWE, FrodoKEM is intended to retain a larger security margin because it does not depend on those structures (Ünsal, 7 Aug 2025). This is why deployment-oriented papers consistently describe it as appropriate for high-assurance contexts, long-term confidentiality, and backup-algorithm portfolios.

A common misconception is that Fujisaki–Okamoto-style CCA security closes all chosen-ciphertext avenues at the implementation level. Side-channel work on ciphertext malleability shows that this is not the case for FrodoKEM. The problem is that the decapsulator computes the intermediate decoded message before the ciphertext-reencryption check; if the Hamming weight of that decoded message leaks through power, EM, or timing, carefully biased ciphertexts can drive efficient message-recovery attacks even though the final FO check rejects (Berthet, 2024). For Frodo-640, Frodo-976, and Frodo-1344, the paper derives full message-recovery attacks with about $B = A S + E \pmod q,$5 oracle calls in the generic model; for realistic byte-oriented implementations of Frodo-640, it further argues that the attack can be parallelized to about $B = A S + E \pmod q,$6 traces, or $B = A S + E \pmod q,$7 traces plus brute force in a reduced-search variant (Berthet, 2024).

The same study proposes a countermeasure that exploits FrodoKEM’s own ciphertext malleability defensively. Before decoding, the implementation adds an encoded random mask to the ciphertext, so that the vulnerable output becomes

$B = A S + E \pmod q,$8

Because FrodoKEM’s encoding is linear when $B = A S + E \pmod q,$9 is a power of two and $$\mathbf{B} = \mathbf{A}\mathbf{S} + \mathbf{E} \pmod q.$$0, the masked decryption integrates cleanly with FO decapsulation: the implementation can correct the reencryption path by subtracting $$\mathbf{B} = \mathbf{A}\mathbf{S} + \mathbf{E} \pmod q.$$1 from the reconstructed ciphertext component (Berthet, 2024). The paper presents this as a lightweight way to protect the decoded message share without changing the KEM semantics.

Another misconception is that FrodoKEM’s conservative arithmetic assumptions imply robust transport performance. The TLS measurements show the opposite: even when the cryptographic assumptions are conservative, deployment quality is highly sensitive to public-key and ciphertext size. In that sense, “conservative security” and “practical robustness” are separable properties, and FrodoKEM scores very differently on them under adverse network conditions (Henrich, 2023).

6. Variants, extensions, and influence on subsequent research

A notable line of work treats FrodoKEM’s underlying PKE layer, FrodoPKE, as a reusable primitive beyond key encapsulation. An updatable encryption construction builds directly on FrodoPKE, with UE.Setup, UE.KG, UE.Enc, and UE.Dec invoking the corresponding FrodoPKE routines, while new token-generation and ciphertext-update algorithms add Frodo-style gadgets, key-switching structure, and a backward-leak uni-directional security proof under the LWE assumption (Jurkiewicz et al., 2024). In a Python/NumPy prototype instantiated with FrodoPKE-640, -976, and -1344, the paper reports $$\mathbf{B} = \mathbf{A}\mathbf{S} + \mathbf{E} \pmod q.$$2 s, $$\mathbf{B} = \mathbf{A}\mathbf{S} + \mathbf{E} \pmod q.$$3 s, and $$\mathbf{B} = \mathbf{A}\mathbf{S} + \mathbf{E} \pmod q.$$4 s for key generation; $$\mathbf{B} = \mathbf{A}\mathbf{S} + \mathbf{E} \pmod q.$$5 s, $$\mathbf{B} = \mathbf{A}\mathbf{S} + \mathbf{E} \pmod q.$$6 s, and $$\mathbf{B} = \mathbf{A}\mathbf{S} + \mathbf{E} \pmod q.$$7 s for token generation; and $$\mathbf{B} = \mathbf{A}\mathbf{S} + \mathbf{E} \pmod q.$$8 s, $$\mathbf{B} = \mathbf{A}\mathbf{S} + \mathbf{E} \pmod q.$$9 s, and $\mathbf{A}\mathbf{S}$0 s for ciphertext update, showing that Frodo’s conservative LWE core can support much richer stateful encryption functionality, albeit with heavy overhead (Jurkiewicz et al., 2024).

Another line modifies only the encode/decode layer. Work on error correction with the Gosset lattice $\mathbf{A}\mathbf{S}$1 replaces FrodoKEM’s original per-coefficient thresholding with an $\mathbf{A}\mathbf{S}$2-based lattice code and derives two parameter families: one that improves concrete security by $\mathbf{A}\mathbf{S}$3 to $\mathbf{A}\mathbf{S}$4 bits by increasing the error variance, and another that reduces bandwidth by $\mathbf{A}\mathbf{S}$5 by halving the modulus $\mathbf{A}\mathbf{S}$6, in both cases improving decryption failure probability relative to the original FrodoKEM (Saliba et al., 2021). Closely related work on lattice codes for lattice-based PKE models FrodoPKE as a noisy modulo-$\mathbf{A}\mathbf{S}$7 channel and reports, for example, that “Frodo-1344-$\mathbf{A}\mathbf{S}$8” attains a $\mathbf{A}\mathbf{S}$9-bit classical security gain over Frodo-1344 (Lyu et al., 2022). These studies leave the LWE core intact and instead exploit denser low-dimensional lattice codes to shift the bandwidth–security–failure trade-off.

FrodoKEM has also become a benchmark for what unstructured post-quantum security costs in bandwidth. A rank-metric KEM based on LRPC codes with multiple syndromes explicitly compares its 128-bit unstructured variant to FrodoKEM and states that it is $\mathbf{S}'\mathbf{A}$0 times shorter in combined public-key and ciphertext size, while presenting itself as an alternative in the same non-ideal, non-structured niche (Aguilar-Melchor et al., 2022). A separate LWE-based public-key cryptosystem with a hidden trapdoor likewise presents its performance as favorable relative to FrodoKEM in batch-key scenarios, while stressing that it is significantly different from NIST’s trapdoor-less LWE candidate (Budroni et al., 2021). That comparative role is itself part of FrodoKEM’s significance: it functions not only as a deployable KEM, but also as a reference baseline for conservative post-quantum design.

Taken together, these extensions and comparisons show that FrodoKEM is more than a single KEM instantiation. It is a matrix-LWE design point whose unstructured assumptions, heavy arithmetic, and large communication footprint have made it a recurring object of optimization, critique, and reuse across hardware design, protocol engineering, side-channel defense, error-correcting modulation, and higher-level cryptographic constructions.