]> Cisco Systems

sfluhrer@cisco.com

National Institute of Standards and Technology

Quynh.Dang@nist.gov

Ericsson

john.mattsson@ericsson.com

Quantinuum

kamilner@kamilner.ca

Arqit Quantum Inc

daniel.shiu@arqit.uk

IRTF Crypto Forum ML-KEM NIST standardized ML-KEM as FIPS 203 in August 2024. This document discusses how to use ML-KEM and how to use it within protocols - that is, what problem it solves, and what you need to do to use it securely. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Crypto Forum Research Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction A Cryptographically Relevant Quantum Computer (CRQC) is a large and reliable Quantum Computer that can break protocols which rely on the traditional RSA, DH, or ECDH methods of securely exchanging keys. Even though it is not believed that, at the time of this writing, there exists a CRQC, there still remains the possibility that an adversary may record the protocol exchange, and then later (when they have access to a CRQC) go ahead and read the traffic. Because of this threat, NIST has published FIPS 203 , which standardizes a method for allowing two systems to securely exchange keying material and which is not vulnerable to a CRQC. This method is based on module lattices, and is called ML-KEM. ML-KEM is a Key Encapsulation Mechanism (KEM), which can be used to generate a shared secret key between two parties. A KEM is a public key mechanism where one side (Alice) can generate a public/private key pair, and send the public key to the other side (Bob). Bob then can use it to generate both a ciphertext and a shared secret key. Bob then sends the ciphertext to Alice, who uses her private key to generate the shared secret key. The idea is that someone in the middle, listening into the exchanged public keys and ciphertexts will not be able to recover the shared secret key that Alice and Bob learns. Hence, Alice and Bob can use their shared secret key to establish secure symmetric communication. One common misunderstanding of the term KEM is the expectation that Bob freely chooses the shared secret, and encrypts that when sending to Alice. While there do exist KEMs where this is true, this is not true for ML-KEM. In ML-KEM is that randomness from both sides are used to contribute to the shared secret. That is, ML-KEM internally generates the shared secret in a way that Bob cannot select the value. Now, Bob can generate a number of ciphertext/shared secret pairs, and select the shared secret that he prefers, but he cannot freely choose it or make the secrets across two different ML-KEM exchanges be equal. A KEM (such as ML-KEM) sounds like it may be a drop-in replacement for Diffie-Hellman (and in some scenarios, it can be). However this is not always the case. In Diffie-Hellman, the parties exchange two public keys, whereas in a KEM, the ciphertext is necessarily a function of Alice's public key, and thus can only be useful only with that specific public key. Additionally, a KEM differs from Diffie-Hellman which is asynchronous and non-interactive. In particular, for an 'ephemeral-ephemeral' key establishment, an encapsulator cannot pre-emptively initiate a key establishment, but requires an encapsulation key. Nor can participants compute parts of the key establishment in parallel as is the case with Diffie-Hellman. As long as the application can handle larger public keys and ciphertexts, a KEM is a drop-in replacement for 'ephemeral-ephemeral' key exchange in protocols like TLS , SSH , Wireguard , and EDHOC as well as 'static-ephemeral' key exchange in protocols like ECIES/HPKE , that is, in cases where Alice has a long term public key, and Bob can use that long term public key to establish communication. A KEM is not a drop-in replacement in applications such as the Diffie-Hellman ratchet in Signal , implicit 'ephemeral-static' DH authentication in Noise , WireGuard , and EDHOC , and 'static-static' configurations in CMS and Group OSCORE , where both sides have long-term public keys. ML-KEM can also be used to perform public key encryption, that is, where a sender encrypts a message with a public key, and only the holder of the private key can decrypt the message. To use ML-KEM for this task, it is recommended that you use it within the Hybrid Public Key Encryption framework to perform the operations. You can use , which is three ML-KEM parameter sets that has been proposed for HPKE.

Using ML-KEM To use ML-KEM, there are three steps involved:

ML-KEM Key Generation The first step for Alice is to generate a public and private keypair. In FIPS 203, the key generation function is ML-KEM.KeyGen() (see section 7.1 of ). It internally calls the random number generator for a seed and produces both a public key (known as an encapsulation key in FIPS 203) and a private key (known as a decapsulation key). The seed can be securely stored, but must be treated with the same safeguards as the private key. The seed format allows fast reconstruction of the expanded key pair format, and elides the need for format checks of the expanded key formats. Other intermediate data besides the matrix A_hat must be securely deleted. A_hat may be saved for repeated Decapsulation operation(s) with the same decapsulation key. The public key can be freely published (and Bob will need it for his part of the process); this step may be performed simply by transmitting the key to Bob. However, the private key (in either format) must be kept secret. It is essential that the public key is generated correctly when the initial key generation is performed. Lattice public keys consist of a lattice and a secret hidden by an error term; if additional error can be introduced into the public key generation stage, then the success of decapsulation can reveal enough of the secret that successive queries determine the private key. Notably, this means a public key can be 'poisoned' such that a future adversary can recover the private key even though it will appear correct in normal usage.

ML-KEM Encapsulation The second step is for Bob to generate a ciphertext and a shared secret key. To perform this step, Bob would first run the Encapsulation Key Check on Alice's public key as outlined at the beginning of section 7.2 of . If that test passes, then Bob would perform what FIPS 203 terms as ML-KEM.Encaps() (see section 7.2 of ). This step takes the validated public key, internally calls the random number generator for a seed, and produces both a ciphertext and a 32-byte shared secret key. Intermediate data other than the ciphertext, shared secret key and the matrix A_hat (and the "matrix data" internal to ML-KEM, which can be deduced from the public key) must be securely deleted. The matrix A_hat may be saved and reused for later encapsulation operations with the same encapsulation key. The ciphertext can be transmitted back to Alice; if the exchange is successful, the 32-byte shared secret key will be the key shared with Alice. It may be that some libraries combine the validation and the encapsulation step; implementations should determine whether the library they are using does. For static public keys, the Encapsulation Key Check only needs to be performed once.

ML-KEM Decapsulation The third and final step is for Alice to take the ciphertext and generate the shared secret key. To perform this step, Alice would first run the Decapsulation Key Check on Bob's ciphertext as outlined at the beginning of section 7.3 of . If that test passes, then Alice would perform what FIPS 203 terms as ML-KEM.Decaps() (see section 7.3 of ). This step takes the ciphertext from Bob and the private key that was previously generated by Alice, and produces a 32-byte shared secret key. It also repeats some or all of the encapsulation process to ensure that the ciphertext was created strictly according to the specification, with invalid ciphertexts generating an unrelated 32 byte value that gives no information. Although not necessary for the correctness of the key establishment, this step should not be skipped as a maliciously generated ciphertext could induce decapsulation failures that can allow an attacker to deduce the private key with a sufficient number of exchanges. Intermediate data other than the shared secret key and the matrix A_hat must be securely deleted. The matrix A_hat may be saved for later Decapsulation operations with the same decapsulation key. If the exchange is successful, the 32-byte key generated on both sides will be the same. The shared secret key is always 32 bytes for all parameter sets. It may be that some libraries combine the validation and the encapsulation step; implementations should determine whether the library they are using does. For static public keys, the Decapsulation Key Check only needs to be performed once.

ML-KEM Parameter Sets FIPS 203 specifies three parameter sets; ML-KEM-512, ML-KEM-768 and ML-KEM-1024. It is assumed that Alice and Bob both know which parameter set they use (either by negotiation or by having one selection fixed in the protocol). shows the sizes of the cryptographic material of ML-KEM for each parameter set, as well as their relative cryptographic strength: pk = public key, sk = private key, expanded form, ct = ciphertext, ss = shared key, all lengths in bytes

	pk size	sk size	ct size	ss size	as strong as
ML-KEM-512	800	1632	768	32	AES-128
ML-KEM-768	1184	2400	1088	32	AES-192
ML-KEM-1024	1568	3168	1568	32	AES-256

shows an example of ML-KEM performance of each parameter set on one specific platform: Single-core performance in operations per second (higher is better) on AMD Ryzen 7 7700

	key generation	encapsulation	decapsulation
ML-KEM-512	244000	153000	202000
ML-KEM-768	142000	103000	134000
ML-KEM-1024	109000	77000	99000

Data sourced from As can be seen from and , ML-KEM has significantly larger public keys and ciphertexts than ECDH but very good performance.

KEM Security Considerations This section pertains to KEM (Key Encapsulation Mechanisms) in general, including ML-KEM. A KEM requires high-quality source of entropy during both the keypair generation and ciphertext generation steps. If an adversary can recover the random bits used in either of these processes, they can recover the shared secret. If an adversary can recover the random bits used during key generation, they can also recover the secret key. Standard cryptographical analysis assumes that the adversary has access only to the exchanged messages. Depending on the deployment scenario, the adversary may have access to various side channels, such as the amount of time taken during the cryptographical computations, or possibly the power used or the electrical noise generated. The implementor will need to assess this possibility, and possibly use an implementation that is resistant to such leakage. Alice needs to keep her private key secret. It is recommended that they zeroize the private key when they will have no further need of it, that is, when they know they never need to decapsulate any further ciphertexts with it. A KEM (including ML-KEM) provides no authentication of either communicating party. If an adversary could replace either the public key or the ciphertext with its own, it would generate a shared key with Alice or Bob. Hence, it is important that the protocol that uses a KEM lets Bob be able to verify that the public key he obtains came from Alice and lets Alice verify that the ciphertext came from Bob (that is, an entity that Alice is willing to communicate with). Such verification can be performed by cryptographic methods such as a digital signature or a MAC to verify integrity of the protocol exchange.

ML-KEM Security Considerations This section pertains specifically to ML-KEM, and may not be true of KEMs in general. The fundamental security property of ML-KEM is that someone listening to the exchanges (and thus obtains both the public key and the ciphertext) cannot reconstruct the shared secret key, and this is true even if the adversary has access to a CRQC. ML-KEM is IND-CCA2 secure; that is, it remains secure even if an adversary is able to submit arbitrary ciphertexts used a fixed public key and observe the resulting shared key. Submitting invalid ciphertexts to ML-KEM.Decaps() does not help the attacker obtain information about the decryption key of the PKE-Decrypt function inside the ML-KEM.Decaps(). Substituting the public key Alice sends Bob by another public key chosen by the attacker will not help the attacker get any information about Alice's private key, it would just make Alice and Bob not have a same shared secret key. However, if it is possible to substitute the copy of the public key for both Alice and Bob, an attacker can introduce a malicious public key where the same private key can be used for decapsulation, but the probability of decryption failure is marginally higher. As decryption failures can leak information about the secret decapulation key, it is important that Alice keeps a secure copy of the public key as part of her secret key. For practical purposes, IND-CCA2 means that ML-KEM is secure to use with static public keys. ML-KEM requires that a source of random bits with security strength greater than or equal to the security strength of the ML-KEM parameter set be used when generating the keypair and ciphertext during ML-KEM.KeyGen() and ML-KEM.Encaps() respectively. The cryptographic library that implements ML-KEM may access this source of randomness internally. A fresh string of bytes must be used for every sampling of random bytes in key generation and encapsulation. The random bytes should be generated securely [RFC 4086]. Alice must keep her private key secret (both private and secure from modification). A copy of the public key and its hash are included in the private key and must be protected from modification. If the ciphertext that Alice receives from Bob is tampered with (either by small modification or by replacing it with an entirely different ciphertext), the shared secret key that Alice derives will be uncorrelated with the shared secret key that Bob obtains. An attacker will not be able to determine any information about the correct shared secret key or Alice's private key, even if the attacker obtains Alice's modified shared secret key which is the output of the ML-KEM.Decaps() function taking the modified ciphertext as input. It is secure to reuse a public key multiple times. That is, instead of Alice generating a fresh public and private keypair for each exchange, Alice may generate a public key once, and then publish that public key, and use it for multiple incoming ciphertexts, generating multiple shared secret keys. While this is safe, it is recommended that if the protocol already has Alice send Bob her unauthenticated public key, they should generate a fresh keypair each time (and zeroize the private key immediately after ML-KEM.Decaps()) to obtain Perfect Forward Secrecy. Generally key generation of ML-KEM is very fast (see ). Hence, if Alice generates a fresh ML-KEM key each time, then even if Alice's system is subverted (either by a hacker or a legal warrant), the previous communications remain secure (because Alice no longer has the information needed to recover the shared secret keys). Alice and Bob must perform the Key Check steps (the Encapsulation Key Check on the public key for Bob, the Decapsulation Key Check on the ciphertext for Alice). The cryptographic libraries that Alice and Bob use may automatically perform such checks; they should each verify that is the case. The shared secret key for all three parameter sets, ML-KEM-512, ML-KEM-768 and ML-KEM-1024 is 32 bytes which are indistinguishable from 32-byte pseudorandom byte-strings of 128, 192 and 256 bits of strengths respectively. As such, the 32-byte string is suitable for both directly as a symmetric key (for use by a symmetric cipher such as AES or a MAC), and also as input into a Key Derivation Function. This is in contrast to a Diffie-Hellman (or ECDH) operation, where the output is distinguishable from random. If the adversary has control over the ML-KEM private key, it has been shown that adversary can cause a ‘misbinding’ between the shared key and either the ciphertext or the public key. That is, by generating an impossible private key (a key that cannot occur with the standard ML-KEM key generation process), the adversary could be able to create public keys for which different ciphertexts or public keys may result in the same shared secret (these security notions are called MAL-BIND-K-CT and MAL-BIND-K-PK in the cryptographical literature ). This is not a threat to normal uses of ML-KEM as a key exchange or a public key encryption method. If ML-KEM is used as an authentication method where the shared key is used for authentication (and adversary control of the private key is possible), it may be advisable if the protocol also authenticates the public key and ciphertext as well.

Issues that are likely not a concern This section contains issues that you may have heard of, but are quite unlikely to be a concern in your use case. This is here to discuss them, and show why they are not practical issues. If you have not heard of them, you may ignore this

Decapsulation failure With ML-KEM, there is a tiny probability of decapsulation failure. That is, even if Alice and Bob perform their roles honestly and the public key and ciphertext are transmitted correctly, there is a tiny probability that Alice and Bob will not derive the same shared key. However, even though that is a theoretical possibility, practically speaking this will never happen. For all three parameter sets, the probability is so low that most likely an actual decapsulation failure because of this will never be seen for any ML-KEM exchange anywhere (not only for your protocol, but over all protocols that use ML-KEM). Hence, the advice we give is to ignore the possibility.

ML-KEM operations not being constant time During the ML-KEM key generation and the encapsulation process, the public seed is expanded, and this involves rejection sampling of XOF (extendable-output function) output to achieve coefficient values that are uniformly distributed. This means that a straight-forward implementation will perform a variable number of XOF calls to generate this output to find values that are in range. Converting this into a constant time operation is expensive enough that it is rarely done. One consequence of this is that public key expansion is not constant time and this timing sidechannel can be used to provide information about the seed (and the expanded key, which is a function of the seed) in cases where they are not publicly known. On the other hand, this public seed is in the public key, which is almost always publicly known, and so this timing variation does not leak any information about any secret data. One exception is in some methods that implement Password Authenticated Key Exchange with ML-KEM, where the public key may be encrypted with the password. In this rather narrow use case, this variable timing needs to be taken into account.

IANA Considerations This document has no IANA actions.

References Normative References Informative References The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK] Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes how to use the 'static-static Elliptic Curve Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie- Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax. In this form of key agreement, the Diffie-Hellman values of both the sender and receiver are long-term values contained in certificates. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. SandboxAQ This document defines Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) KEM options for Hybrid Public-Key Encryption (HPKE). ML-KEM is believed to be secure even against adversaries who possess a cryptographically-relevant quantum computer. CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security n.d. n.d. n.d.

Acknowledgments The authors would like to thank Rebecca Guthrie and Thom Wiggers for their valuable comments and feedback.