Security Considerations for FrodoKEM
draft-longa-cfrg-frodokem-security-considerations-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Patrick Longa , Joppe W. Bos , Stephan Ehlen , Douglas Stebila | ||
| Last updated | 2026-06-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-longa-cfrg-frodokem-security-considerations-00
CFRG P. Longa
Internet-Draft Microsoft
Intended status: Informational J. W. Bos
Expires: 24 December 2026 NXP Semiconductors
S. Ehlen
Federal Office for Information Security (BSI)
D. Stebila
University of Waterloo
22 June 2026
Security Considerations for FrodoKEM
draft-longa-cfrg-frodokem-security-considerations-00
Abstract
ISO standardized FrodoKEM in June 2026 [ISO18033-2-AMD2]. This
document provides security guidance for FrodoKEM for use in
protocols. It explains what security claims protocol designers may
rely on, what assumptions and conditions are required, what parameter
sets are in scope, and what implementors need to do to use FrodoKEM
safely. The scope follows the current FrodoKEM Internet-Draft
[I-D.FrodoKEM].
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-longa-cfrg-frodokem-security-
considerations/.
Source for this draft and an issue tracker can be found at
github.com/patricklonga/frodokem-security-considerations-draft.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Longa, et al. Expires 24 December 2026 [Page 1]
Internet-Draft FrodoKEM Security Considerations June 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Standard and Ephemeral FrodoKEM . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Using FrodoKEM . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Key Generation . . . . . . . . . . . . . . . . . . . . . 4
3.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Decapsulation . . . . . . . . . . . . . . . . . . . . . . 5
4. Parameter Sets . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Parameter-Set Selection and Defaults . . . . . . . . . . 7
5. Is FrodoKEM Safe to Use? . . . . . . . . . . . . . . . . . . 8
5.1. Authoritative Specifications . . . . . . . . . . . . . . 8
5.2. Security Notions and Security Strength . . . . . . . . . 8
5.3. Basis for Confidence . . . . . . . . . . . . . . . . . . 9
5.4. Protocol-Relevant Considerations . . . . . . . . . . . . 10
5.5. Implementation security . . . . . . . . . . . . . . . . . 11
5.6. Public implementations . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Longa, et al. Expires 24 December 2026 [Page 2]
Internet-Draft FrodoKEM Security Considerations June 2026
1. Introduction
FrodoKEM is a conservative post-quantum key encapsulation mechanism
(KEM) whose security derives from a parameterization of the well-
studied Learning with Errors (LWE) problem. Thus, FrodoKEM's most
distinctive feature is its use of generic, algebraically unstructured
lattices, which provides an additional layer of security in case
future cryptanalytic attacks are able to exploit structured lattices.
As a key encapsulation mechanism, FrodoKEM is a three-tuple of
algorithms (key generation, encapsulation, decapsulation):
* Key generation is given by a randomized algorithm that takes no
inputs, and outputs a public key and a private key;
* Encapsulation is given by a randomized algorithm that takes as
input a public key, and outputs a ciphertext and a shared secret;
* Decapsulation is given by an algorithm that takes as input a
ciphertext and a private key, and outputs a shared secret.
With these algorithms, two parties, Alice and Bob, can perform a two-
pass protocol to derive a shared secret as follows. First, Alice
generates a public/private keypair during key generation. In the
first protocol pass, Bob uses Alice's public key to produce a
ciphertext and a shared secret with the encapsulation algorithm. In
the second protocol pass, Alice uses her private key and the
ciphertext to execute the decapsulation operation and produce a
shared secret. The shared secret is indistinguishable from random by
an adversary and can be used directly to establish a secure
communication channel using a symmetric-key algorithm.
A KEM protocol like FrodoKEM is not always a drop-in replacement for
Diffie–Hellman. Unlike Diffie–Hellman, where both parties exchange
public keys and jointly derive a shared secret (often computing
intermediate values independently and in parallel), a KEM requires a
recipient’s public key before encapsulation and produces ciphertexts
bound to that specific key. Consequently, KEMs are less flexible in
asynchronous or precomputation settings.
Nevertheless, KEMs can serve as drop-in replacements in several
common protocol patterns, as explained in the introduction of
[MLKEM-SC]. In ephemeral–ephemeral key exchange (e.g., TLS 1.3, SSH
and WireGuard), or in static–ephemeral settings where one party has a
long-term public key (e.g., ECIES and HPKE), a KEM can replace
Diffie–Hellman. In contrast, KEMs do not directly support
constructions that rely on joint, bidirectional derivation of shared
secrets. This includes Diffie–Hellman ratchets (e.g., Signal),
Longa, et al. Expires 24 December 2026 [Page 3]
Internet-Draft FrodoKEM Security Considerations June 2026
implicit ephemeral–static authentication patterns (e.g., Noise and
WireGuard), and static–static key establishment, where both parties
hold long-term public keys.
1.1. Standard and Ephemeral FrodoKEM
FrodoKEM consists of two main variants:
* "Standard" (or "salted") FrodoKEM: this variant can freely reuse
public/private keypairs, as it includes countermeasures that
protect against multi-ciphertext attacks [FrodoAnnex].
Concretely, standard FrodoKEM doubles the length of the seed
seedSE and incorporates a public random salt value during
encapsulation.
* "Ephemeral" FrodoKEM (or eFrodoKEM): this variant does not include
countermeasures against multi-ciphertext attacks and, hence, is
intended for applications in which the number of ciphertexts
produced relative to any single public key is small. As stated in
[I-D.FrodoKEM], ephemeral FrodoKEM must not be used in
applications in which a single public key may produce 2^8
ciphertexts or more.
Ephemeral FrodoKEM is available mostly for backwards compatibility.
For most applications, standard FrodoKEM is the recommended option,
and it is the option this document refers to, unless explicitly
stated.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Using FrodoKEM
FrodoKEM consists of three algorithms (executed in this order): key
generation, encapsulation, and decapsulation.
3.1. Key Generation
In this first step, Alice generates a public and private keypair.
The procedure is described in Section 7.1 of [I-D.FrodoKEM].
Longa, et al. Expires 24 December 2026 [Page 4]
Internet-Draft FrodoKEM Security Considerations June 2026
The algorithm internally calls the random number generator (RNG) to
produce seeds s, seedSE and z (s is used as a fallback random secret,
seedSE is used to sample error/secret matrices and z is used to
generate the so-called public matrix A). The seeds (s, seedSE, z)
can be securely stored to enable later reconstruction of the fully
expanded private key. These seeds must be protected as private key
material.
Intermediate data other than the matrix A should be securely deleted
when no longer needed. When there is enough storage capacity, matrix
A may be saved for repeated decapsulation operations with the same
private key.
3.2. Encapsulation
In the second step, Bob generates a ciphertext and a shared secret.
The procedure is described in Section 7.2 of [I-D.FrodoKEM].
The algorithm internally requires fresh randomness to generate the
message value u and the public salt. The value u is secret
encapsulation randomness. The salt is released as part of the
ciphertext and is intended to be public, but it must be freshly
generated with sufficient entropy and must be independent of u.
Implementations must use a cryptographically secure RNG or DRBG whose
public outputs do not compromise past or future secret outputs.
Intermediate data other than data corresponding to the ciphertext or
public key (including matrix A) should be securely deleted when no
longer needed. When there is enough storage capacity, matrix A may
be saved for repeated encapsulation operations with the same public
key.
The ciphertext can be sent back to Alice; if the protocol is
successful, the shared secret will be the key shared with Alice.
3.3. Decapsulation
In the third and final step, Alice generates the shared secret using
her private key and the ciphertext sent by Bob. The procedure is
described in Section 7.3 of [I-D.FrodoKEM].
The algorithm reconstructs the ciphertext that would result from the
decoded message and compares it with the received ciphertext. If the
comparison fails, decapsulation uses the fallback secret s to derive
the shared secret. This implicit-rejection step is essential for CCA
security and must not be skipped, exposed as a distinguishable error,
or implemented with timing, memory-access, logging, or control-flow
behavior that reveals whether the received ciphertext was valid. The
Longa, et al. Expires 24 December 2026 [Page 5]
Internet-Draft FrodoKEM Security Considerations June 2026
comparison of the reconstructed and received ciphertext components
and the selection between k' and s must be performed in constant time
with respect to the secret key, the decoded candidate message, and
the comparison result.
Intermediate data other than data corresponding to the ciphertext
sent by Bob or to matrix A should be securely deleted when no longer
needed.
If the protocol is successful, the shared secret generated by Alice
and Bob will be the same.
4. Parameter Sets
Standard FrodoKEM includes six parameter sets:
1. FrodoKEM-640-⟨PRG⟩, which matches or exceeds the brute-force
security of AES128.
2. FrodoKEM-976-⟨PRG⟩, which matches or exceeds the brute-force
security of AES192.
3. FrodoKEM-1344-⟨PRG⟩, which matches or exceeds the brute-force
security of AES256.
The options for ⟨PRG⟩ are AES or SHAKE, when either AES128 or
SHAKE128, respectively, is used for the generation of matrix A.
Thus, FrodoKEM consists of the parameter sets FrodoKEM-640-AES,
FrodoKEM-976-AES, FrodoKEM-1344-AES, FrodoKEM-640-SHAKE, FrodoKEM-
976-SHAKE and FrodoKEM-1344-SHAKE.
The AES variants are suitable for platforms featuring AES hardware
acceleration (such as AES-NI on Intel platforms), while the SHAKE
variants generally provide competitive or better performance in
comparison with the AES variants in the absence of such hardware
acceleration.
Table 1 summarizes the input and output sizes for the different
FrodoKEM parameter sets.
Longa, et al. Expires 24 December 2026 [Page 6]
Internet-Draft FrodoKEM Security Considerations June 2026
+===============+===============+========+============+===========+
| Scheme | secret key sk | public | ciphertext | shared |
| | | key pk | ct | secret ss |
+===============+===============+========+============+===========+
| FrodoKEM-640 | 19,888 | 9,616 | 9,752 | 16 |
+---------------+---------------+--------+------------+-----------+
| FrodoKEM-976 | 31,296 | 15,632 | 15,792 | 24 |
+---------------+---------------+--------+------------+-----------+
| FrodoKEM-1344 | 43,088 | 21,520 | 21,696 | 32 |
+---------------+---------------+--------+------------+-----------+
Table 1: Sizes (in bytes) of inputs and outputs for the
FrodoKEM parameter sets.
Similarly, ephemeral FrodoKEM consists of six parameter sets, each
analogous to the standard FrodoKEM variants above. Thus, ephemeral
FrodoKEM consists of the parameter sets eFrodoKEM-640-AES, eFrodoKEM-
976-AES, eFrodoKEM-1344-AES, eFrodoKEM-640-SHAKE, eFrodoKEM-976-SHAKE
and eFrodoKEM-1344-SHAKE.
Table 2 summarizes the input and output sizes for the different
ephemeral FrodoKEM parameter sets. All the sizes are identical to
standard FrodoKEM, with the exception of the ciphertexts, which do
not include the salt value.
+================+===============+========+============+===========+
| Scheme | secret key sk | public | ciphertext | shared |
| | | key pk | ct | secret ss |
+================+===============+========+============+===========+
| eFrodoKEM-640 | 19,888 | 9,616 | 9,720 | 16 |
+----------------+---------------+--------+------------+-----------+
| eFrodoKEM-976 | 31,296 | 15,632 | 15,744 | 24 |
+----------------+---------------+--------+------------+-----------+
| eFrodoKEM-1344 | 43,088 | 21,520 | 21,632 | 32 |
+----------------+---------------+--------+------------+-----------+
Table 2: Sizes (in bytes) of inputs and outputs for the
ephemeral FrodoKEM parameter sets.
The complete set of parameters that characterizes each parameter set
is listed in Section 9.1 of [I-D.FrodoKEM].
4.1. Parameter-Set Selection and Defaults
For most applications, the default choice should be one of the
standard (salted) FrodoKEM variants, not an ephemeral variant, unless
the protocol can guarantee that fewer than 2^8 ciphertexts are ever
produced under a public key.
Longa, et al. Expires 24 December 2026 [Page 7]
Internet-Draft FrodoKEM Security Considerations June 2026
It is recommended to use the highest security level supported by a
given application. For most applications, it is recommended to use
either FrodoKEM-976 or FrodoKEM-1344. FrodoKEM-640 may be used in
applications that cannot accommodate the performance or bandwidth
requirements of the higher parameter sets and do not require long-
term confidentiality.
A short decision guide is therefore:
* choose *standard FrodoKEM*, not eFrodoKEM, by default;
* choose *FrodoKEM-976* or *FrodoKEM-1344* for most applications;
* choose *FrodoKEM-640* only when short-term security is the
intended use case;
* choose *AES* variants if the target environment has AES
acceleration; otherwise, *SHAKE* is a reasonable choice.
5. Is FrodoKEM Safe to Use?
5.1. Authoritative Specifications
For protocol designers and implementors, the authoritative FrodoKEM
specification is detailed in the FrodoKEM Internet-Draft
[I-D.FrodoKEM]. As of version draft-longa-cfrg-frodokem-03, the
FrodoKEM I-D is fully aligned with the ISO standard
[ISO18033-2-AMD2], with the sole exception that the FrodoKEM-640
parameter set is *not* included in [ISO18033-2-AMD2]. In addition,
the FrodoKEM I-D specifies a seed-based private key format as an
optional serialization method (Section 7.1 of [I-D.FrodoKEM]),
whereas [ISO18033-2-AMD2] does not describe this option.
Both documents are in turn derived from FrodoKEM's Round 3
specification [FrodoSpec2021] and the 2023 annex that provides the
algorithm specification and the salted update materials [FrodoAnnex].
5.2. Security Notions and Security Strength
For protocol use, the relevant cryptographic notion is IND-CCA2 KEM
security. In practice, this means that users can freely reuse
public/private keypairs for multiple encapsulation/decapsulation
operations (this applies specifically to the case of standard
FrodoKEM).
A related notion is multi-target security, in which the adversary is
given multiple ciphertexts, each generated under a public key of its
choice. The 2025 FrodoKEM paper [FrodoPaper2025] proves that
Longa, et al. Expires 24 December 2026 [Page 8]
Internet-Draft FrodoKEM Security Considerations June 2026
FrodoKEM tightly achieves multi-target security by means of the
salted Fujisaki-Okamoto (SFO) transform in conjunction with the
hashing of the public key in the computation of random strings during
encapsulation.
FrodoKEM's Round 3 specification [FrodoSpec2021] provides a security
proof that shows that the IND-CCA2 security of FrodoKEM is tied to
the security of concrete instances of the decisional normal-form LWE
problem in the classical ROM. A similar (non-tight) proof is given
in the QROM. These results were revisited in the 2025 FrodoKEM paper
[FrodoPaper2025].
As is customary in cryptography, security strength is better
quantified by an analysis of the best-known cryptanalytic attacks
against a given cryptographic scheme. An up-to-date cryptanalysis of
FrodoKEM LWE instances was carried out in [FrodoPaper2025]. The
results for the 'beyond-core-SVP' methodology showed security
estimates of 149.8 bits for (e)FrodoKEM-640, 212.6 bits for
(e)FrodoKEM-976 and 266.8 bits for (e)FrodoKEM-1344, which support
the security level claims for the FrodoKEM parameter sets.
5.3. Basis for Confidence
The LWE problem, which underlies the security of FrodoKEM, has been
extensively studied for about two decades. Examples of cryptanalysis
papers include [ACD_18], [ADH_19], [AGP_20], [DDG_20], to name a few.
FrodoKEM has a substantial public record that dates back to the start
of NIST's Post-Quantum Cryptography Standardization process in 2017.
In addition to the security analysis presented as part of the NIST
submission, FrodoKEM's security has been studied in [Gla24], [GHS25]
and [FrodoPaper2025].
FrodoKEM was selected as a third-round alternate candidate, and
ultimately was not selected by NIST due to performance reasons, as
explained in Section 4.3.1 of [NIST-3rd-round]. In that same report,
NIST acknowledges that "In terms of security, Frodo’s conservative
design choices are laudable".
FrodoKEM's conservative design has gained the support of multiple
government agencies, which have emphasized the need for a
conservative option with less underlying algebraic structure.
FrodoKEM has been recommended as a conservative alternative by the
German BSI [BSI24], the French ANSSI [ANSSI23], and the Dutch NLNCSA
and AIVD [AIVD24]. This support ultimately led to the
standardization of FrodoKEM by ISO [ISO18033-2-AMD2].
Longa, et al. Expires 24 December 2026 [Page 9]
Internet-Draft FrodoKEM Security Considerations June 2026
5.4. Protocol-Relevant Considerations
As a KEM, FrodoKEM does not provide authentication of the
communicating parties. Therefore, the surrounding protocol must
ensure authentication of public keys and must bind protocol messages
to the identities of the participating parties. This is typically
achieved using digital signatures or authenticated key exchange
constructions.
Similar to ML-KEM, FrodoKEM employs implicit rejection: when
decapsulation is performed on an invalid ciphertext, it returns a
pseudorandom shared secret rather than signaling an error. As a
result, the communicating parties may derive different shared
secrets. In well-designed authenticated key exchange protocols,
where the derived shared secret is used to produce symmetric
cryptographic keys, such a mismatch causes subsequent protocol steps
(e.g., key confirmation or integrity checks) to fail without
compromising security.
Likewise, FrodoKEM has a (negligible) probability that decapsulation
of a valid ciphertext does not recover the same shared secret
produced during encapsulation. This failure probability is extremely
small for the standardized parameter sets and is accounted for in the
security analysis. In practice, such an event results in a mismatch
between the parties’ derived shared secrets. As discussed above, in
well-designed protocols that derive symmetric keys from the shared
secret, this mismatch causes subsequent integrity checks or key
confirmation steps to fail, leading to a safe termination of the
protocol without compromising security.
Implementations must validate the exact lengths of public keys,
secret keys and ciphertexts for the selected parameter set before any
further processing. The FrodoKEM Internet-Draft presents fixed
formats and does not describe flexible wire encodings for these
values.
It is safe to reuse (standard) FrodoKEM public keys for multiple
encapsulations, and doing so produces independent shared secrets for
each ciphertext. However, this does not provide perfect forward
secrecy: if the private key is later compromised, past sessions can
be recovered. Therefore, when a protocol already transmits an
unauthenticated public key (e.g., as part of a handshake), it is
recommended to generate a fresh keypair per session and immediately
delete the private key after decapsulation to obtain perfect forward
secrecy.
Longa, et al. Expires 24 December 2026 [Page 10]
Internet-Draft FrodoKEM Security Considerations June 2026
Because lattice-based KEMs are relatively new compared to the
classical mechanisms they are intended to replace, deployments are
encouraged to use FrodoKEM in a hybrid construction with a
traditional key-establishment mechanism. Such use should follow a
specified hybrid KEM or protocol construction employing a security-
analyzed combiner; e.g., see Section 4.6 of [NIST-SP800-227].
5.5. Implementation security
FrodoKEM is simple to implement and facilitates writing
implementations that are compact and run in constant time. At its
core, FrodoKEM consists of simple matrix-vector operations that are
easy to scale to different matrix dimensions. Also, FrodoKEM uses a
modulus q that is either 2^15 or 2^16. These design choices enable
full reuse of the same matrix functions across parameter sets, with
only parameter instantiation required at build time.
The use of a power-of-two modulus further simplifies implementation.
Arithmetic modulo q is efficient and easy to do in constant time on
modern architectures; for example, reduction modulo 2^16 is
automatically achieved when using 16-bit data types. Moreover, the
chosen matrix dimensions are divisible by 16, facilitating vectorized
implementations and simplifying the use of AES128 for generation of
the matrix A.
Error sampling is likewise designed for simplicity and code reuse.
Across all security levels, each sample requires 16 bits, and the
corresponding discrete cumulative distribution function (CDF) tables
contain values strictly below 2^15. This allows for a uniform
inversion-sampling routine instantiated with precomputed tables.
Because these tables are small, constant-time lookup used to mitigate
timing side-channel attacks can be implemented with negligible
complexity and performance overhead.
The byte encoding rules, the separate packing/unpacking byte
encoding, and the matrix encoding and decoding rules are explicitly
specified in the current FrodoKEM Internet-Draft [I-D.FrodoKEM].
Implementations must follow those rules exactly.
Special care should be given to the ciphertext consistency check
during decapsulation, ensuring that the implementation reads both k'
and s (the secret and the fallback random secret, resp., used for the
shared secret computation), the required comparisons are done in a
constant-time way that avoids early termination, and the final value
for kHat is set using data-independent evaluation.
Longa, et al. Expires 24 December 2026 [Page 11]
Internet-Draft FrodoKEM Security Considerations June 2026
In some scenarios, such as embedded applications, implementors may
need to consider additional countermeasures (e.g., masking) to
protect against more powerful side-channel attacks beyond timing
attacks. While resistance to certain classes of side-channel attacks
remains an active area of research, the simplicity of FrodoKEM’s
design significantly reduces the attack surface compared to other
LWE-based schemes that rely on FFT-based multiplication techniques.
5.6. Public implementations
Reference [FrodoCode] provides portable and optimized implementations
of FrodoKEM written in C, as well as reference implementations
written in Python that are intended to be readable and close to a
line-by-line mapping of the FrodoKEM algorithms. These
implementations include functional tests and known answer tests.
The Botan cryptography library also contains a C++ implementation of
FrodoKEM [Botan].
6. IANA Considerations
This document has no IANA actions.
7. References
7.1. Normative References
[I-D.FrodoKEM]
Longa, P., Bos, J. W., Ehlen, S., and D. Stebila,
"FrodoKEM: key encapsulation from learning with errors
(IETF Internet-Draft, draft-longa-cfrg-frodokem)", March
2026, <https://datatracker.ietf.org/doc/draft-longa-cfrg-
frodokem/>.
[ISO18033-2-AMD2]
ISO, "ISO/IEC 18033-2:2006/Amd 2, Information technology —
Security techniques — Encryption algorithms — Part 2:
Asymmetric ciphers, Amendment 2", June 2026,
<https://www.iso.org/standard/86890.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Longa, et al. Expires 24 December 2026 [Page 12]
Internet-Draft FrodoKEM Security Considerations June 2026
7.2. Informative References
[ACD_18] Albrecht, M. R., Curtis, B. R., Deo, A., Davidson, A.,
Player, R., Postlethwaite, E. W., Virdia, F., and T.
Wunderer, "Estimate all the LWE, NTRU schemes!", 2018,
<https://eprint.iacr.org/2018/331>.
[ADH_19] Albrecht, M. R., Ducas, L., Herold, G., Kirshanova, E.,
Postlethwaite, E. W., and M. Stevens, "The General Sieve
Kernel and New Records in Lattice Reduction", 2019,
<https://eprint.iacr.org/2019/089>.
[AGP_20] Albrecht, M. R., Gheorghiu, V., Postlethwaite, E. W., and
J. M. Schanck, "Estimating quantum speedups for lattice
sieves", 2020, <https://eprint.iacr.org/2019/1161>.
[AIVD24] (TNO), G. I. and S. S. (AIVD) and C. W. & I. (CWI) and N.
O. for A. S. R., "The PQC Migration Handbook: Guidelines
for Migrating to Post-Quantum Cryptography (second
edition)", 2024,
<https://publications.tno.nl/publication/34643386/
fXcPVHsX/TNO-2024-pqc-en.pdf>.
[ANSSI23] (ANSSI), N. C. A. of F., "ANSSI views on the Post-Quantum
Cryptography transition (2023 follow up)", 2023,
<https://cyber.gouv.fr/en/publications/follow-position-
paper-post-quantum-cryptography>.
[Botan] "Botan: Cryptography Toolkit",
<https://botan.randombit.net/>.
[BSI24] (BSI), F. O. for I. S., "Cryptographic Mechanisms:
Recommendations and Key Lengths, BSI TR-02102-1, Version:
2024-1", January 2024,
<https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/
TechGuidelines/TG02102/BSI-TR-
02102-1.pdf?__blob=publicationFile&v=7>.
[DDG_20] Dachman-Soled, D., Ducas, L., Gong, H., and M. Rossi, "LWE
with side information: Attacks and concrete security
estimation", 2020, <https://eprint.iacr.org/2020/292>.
[FrodoAnnex]
Alkim, E., Bos, J. W., Ducas, L., Longa, P., Mironov, I.,
Naehrig, M., Nikolaenko, V., Peikert, C., Raghunathan, A.,
and D. Stebila, "Annex on FrodoKEM updates", April 2023,
<https://frodokem.org/files/FrodoKEM-annex-20230418.pdf>.
Longa, et al. Expires 24 December 2026 [Page 13]
Internet-Draft FrodoKEM Security Considerations June 2026
[FrodoCode]
Alkim, E., Bos, J. W., Ducas, L., Longa, P., Mironov, I.,
Naehrig, M., Nikolaenko, V., Peikert, C., Raghunathan, A.,
and D. Stebila, "Reference C and Python implementations of
FrodoKEM and eFrodoKEM",
<https://github.com/microsoft/PQCrypto-LWEKE>.
[FrodoPaper2025]
Glabush, L., Longa, P., Naehrig, M., Peikert, C., Stebila,
D., and F. Virdia, "FrodoKEM: A CCA-Secure Learning With
Errors Key Encapsulation Mechanism", October 2025,
<https://eprint.iacr.org/2025/1861.pdf>.
[FrodoSpec2021]
Alkim, E., Bos, J. W., Ducas, L., Longa, P., Mironov, I.,
Naehrig, M., Nikolaenko, V., Peikert, C., Raghunathan, A.,
and D. Stebila, "FrodoKEM: Learning With Errors Key
Encapsulation, Algorithm Specifications And Supporting
Documentation (FrodoKEM Round 3 specification)", June
2021, <https://frodokem.org/files/FrodoKEM-specification-
20210604.pdf>.
[GHS25] Glabush, L., Hövelmanns, K., and D. Stebila, "Tight multi-
target security for key encapsulation mechanisms", 2025,
<https://eprint.iacr.org/2025/343>.
[Gla24] Glabush, L., "Tight multi-target security for key
encapsulation mechanisms", 2024,
<https://uwspace.uwaterloo.ca/
items/8871c4b1-c2c6-4a42-9485-1466f1772985>.
[MLKEM-SC] Fluhrer, S., Dang, Q., Mattsson, J. P., Milner, K., and D.
Shiu, "ML-KEM Security Considerations (IETF Internet-
Draft, draft-sfluhrer-cfrg-ml-kem-security-
considerations)", May 2026, <https://github.com/sfluhrer/
ml-kem-security-considerations>.
[NIST-3rd-round]
(NIST), N. I. of S. and T., "Status Report on the Third
Round of the NIST Post-Quantum Cryptography
Standardization Process", July 2022,
<https://nvlpubs.nist.gov/nistpubs/ir/2022/
NIST.IR.8413-upd1.pdf>.
Longa, et al. Expires 24 December 2026 [Page 14]
Internet-Draft FrodoKEM Security Considerations June 2026
[NIST-SP800-227]
Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A.,
Silberg, H., and N. Waller, "Recommendations for Key-
Encapsulation Mechanisms (NIST Special Publication 800,
NIST SP 800-227)", September 2025,
<https://doi.org/10.6028/NIST.SP.800-227>.
Authors' Addresses
Patrick Longa
Microsoft
Email: plonga@microsoft.com
Joppe W. Bos
NXP Semiconductors
Email: joppe.bos@nxp.com
Stephan Ehlen
Federal Office for Information Security (BSI)
Email: stephan.ehlen@bsi.bund.de
Douglas Stebila
University of Waterloo
Email: dstebila@uwaterloo.ca
Longa, et al. Expires 24 December 2026 [Page 15]