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, . [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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [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, . [AGP_20] Albrecht, M. R., Gheorghiu, V., Postlethwaite, E. W., and J. M. Schanck, "Estimating quantum speedups for lattice sieves", 2020, . [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, . [ANSSI23] (ANSSI), N. C. A. of F., "ANSSI views on the Post-Quantum Cryptography transition (2023 follow up)", 2023, . [Botan] "Botan: Cryptography Toolkit", . [BSI24] (BSI), F. O. for I. S., "Cryptographic Mechanisms: Recommendations and Key Lengths, BSI TR-02102-1, Version: 2024-1", January 2024, . [DDG_20] Dachman-Soled, D., Ducas, L., Gong, H., and M. Rossi, "LWE with side information: Attacks and concrete security estimation", 2020, . [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, . 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", . [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, . [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, . [GHS25] Glabush, L., Hövelmanns, K., and D. Stebila, "Tight multi- target security for key encapsulation mechanisms", 2025, . [Gla24] Glabush, L., "Tight multi-target security for key encapsulation mechanisms", 2024, . [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, . [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, . 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, . 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]