]> CryptoNext Security

16, Boulevard Saint-Germain Paris 75005 France julien.prat@cryptonext-security.com

Entrust Limited

2500 Solandt Road -- Suite 100 OttawaOntario K2K 3G5 Canada mike.ounsworth@entrust.com

CryptoNext Security

16, Boulevard Saint-Germain Paris 75005 France daniel.vangeest@cryptonext-security.com

SEC lamps Key Encapsulation Mechanism (KEM) KEMRecipientInfo ML-KEM Kyber Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant Key Encapsulation Mechanism (KEM). Three parameter sets for the ML-KEM algorithm are specified by the US National Institute of Standards and Technology (NIST) in FIPS 203. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This document specifies the conventions for using ML-KEM with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure defined in "Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)" (RFC 9629).

Introduction The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is an IND-CCA2-secure Key Encapsulation Mechanism (KEM) standardized in by the NIST PQC Project . ML-KEM is the name given to the final standardized version and is incompatible with pre-standards versions, often called "Kyber". defines the KEMRecipientInfo structure for the use of KEM algorithms for the CMS enveloped-data content type, the CMS authenticated-data content type, and the CMS authenticated-enveloped-data content type. This document specifies the direct use of ML-KEM in the KEMRecipientInfo structure using each of the three parameter sets from , namely ML-KEM-512, ML-KEM-768, and ML-KEM-1024. It does not address or preclude the use of ML-KEM as part of any hybrid scheme.

Conventions and Terminology 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 when, and only when, they appear in all capitals, as shown here.

ML-KEM ML-KEM is a lattice-based KEM using Module Learning with Errors as its underlying primitive, which is a structured lattices variant that offers good performance and relatively small and balanced key and ciphertext sizes. ML-KEM was standardized with three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. The parameters for each of the security levels were chosen to be at least as secure as a generic block cipher of 128, 192, or 256 bits, respectively. provides more information on ML-KEM security levels and sizes. All KEM algorithms provide three functions: KeyGen(), Encapsulate(), and Decapsulate(). The following summarizes these three functions for the ML-KEM algorithm, referencing corresponding functions in :

KeyGen() -> (ek, dk):

Generate the public encapsulation key (ek) and a private decapsulation key (dk). specifies two formats for an ML-KEM private key: a 64-octet seed (d,z) and an (expanded) private decapsulation key (dk). Algorithm 19 (ML-KEM.KeyGen()) from generates the public encapsulation key (ek) and the private decapsulation key (dk). As an alternative, when a seed (d,z) is generated first and then the seed is expanded to get the keys, algorithm 16 (ML-KEM.KeyGen_internal(d,z)) from expands the seed to ek and dk. See for private key encoding considerations.

Encapsulate(ek) -> (c, ss):

Given the recipient's public key (ek), produce both a ciphertext (c) to be passed to the recipient and a shared secret (ss) for use by the originator. Algorithm 20 (ML-KEM.Encaps(ek)) from is the encapsulation function for ML-KEM.

Decapsulate(dk, c) -> ss:

Given the private key (dk) and the ciphertext (c), produce the shared secret (ss) for the recipient. Algorithm 21 (ML-KEM.Decaps(dk,c)) from is the decapsulation function for ML-KEM. If the private key is stored in seed form, ML-KEM.KeyGen_internal(d,z) may be needed as a first step to compute dk. See for consistency considerations if the private key was stored in both seed and expanded formats.

All security levels of ML-KEM use SHA3-256, SHA3-512, SHAKE128, and SHAKE256 internally.

Use of the ML-KEM Algorithm in the CMS The ML-KEM algorithm MAY be employed for one or more recipients in the CMS enveloped-data content type , the CMS authenticated-data content type , or the CMS authenticated-enveloped-data content type . In each case, the KEMRecipientInfo is used with the ML-KEM algorithm to securely transfer the content-encryption key from the originator to the recipient. Processing ML-KEM with KEMRecipientInfo follows the same steps as . To support the ML-KEM algorithm, a CMS originator MUST implement the Encapsulate() function and a CMS recipient MUST implement the Decapsulate() function.

RecipientInfo Conventions When the ML-KEM algorithm is employed for a recipient, the RecipientInfo alternative for that recipient MUST be OtherRecipientInfo using the KEMRecipientInfo structure as defined in . The fields of the KEMRecipientInfo have the following meanings:

version

The syntax version number; it MUST be 0.

rid

Identifies the recipient's certificate or public key.

kem

Identifies the KEM algorithm; it MUST contain one of id-alg-ml-kem-512, id-alg-ml-kem-768, or id-alg-ml-kem-1024. These identifiers are reproduced in .

kemct

The ciphertext produced for this recipient.

kdf

Identifies the key derivation algorithm. Note that the Key Derivation Function (KDF) used for CMS RecipientInfo process MAY be different than the KDF used within the ML-KEM algorithm. Implementations MUST support the HMAC-based Key Derivation Function (HKDF) with SHA-256 using the id-alg-hkdf-with-sha256 KDF object identifier (OID) . As specified in , the parameter field MUST be absent when this OID appears within the ASN.1 type AlgorithmIdentifier. Implementations MAY support other KDFs as well.

kekLength

The size of the key-encryption key in octets.

ukm

Optional input to the KDF. The secure use of ML-KEM in CMS does not depend on the use of a ukm value, so this document does not place any requirements on this value. See for more information about the ukm parameter.

wrap

Identifies a key-encryption algorithm used to encrypt the content-encryption key. Implementations supporting ML-KEM-512 MUST support the AES-Wrap-128 key-encryption algorithm using the id-aes128-wrap key-encryption algorithm OID . Implementations supporting ML-KEM-768 or ML-KEM-1024 MUST support the AES-Wrap-256 key-encryption algorithm using the id-aes256-wrap key-encryption algorithm OID . Implementations MAY support other key-encryption algorithms as well.

contains an example of establishing a content-encryption key using ML-KEM in the KEMRecipientInfo type.

Underlying Components When ML-KEM is employed in the CMS, the underlying components used within the KEMRecipientInfo structure SHOULD be consistent with a minimum desired security level. Several security levels have been identified in . If underlying components other than those specified in are used, then the following table gives the minimum requirements on the components used with ML-KEM in the KEMRecipientInfo type in order to satisfy the KDF and key wrapping algorithm requirements from : ML-KEM KEMRecipientInfo Component Security Levels

Security Strength	Algorithm	KDF Preimage Strength	Symmetric Key-Encryption Strength
128-bit	ML-KEM-512	128-bit	128-bit
192-bit	ML-KEM-768	192-bit	192-bit (*)
256-bit	ML-KEM-1024	256-bit	256-bit

(*) In the case of AES Key Wrap, a 256-bit key is typically used because AES-192 is not as commonly deployed.

Use of the HKDF-Based Key Derivation Function The HKDF function is a composition of the HKDF-Extract and HKDF-Expand functions. When used with KEMRecipientInfo, the salt parameter is unused; that is, it is the zero-length string "". The IKM, info, and L parameters correspond to the same KDF inputs from . The info parameter is independently generated by the originator and recipient. Implementations MUST confirm that L is consistent with the key size of the key-encryption algorithm.

Certificate Conventions specifies the profile for using X.509 certificates in Internet applications. A recipient static public key is needed for ML-KEM and the originator obtains that public key from the recipient's certificate. The conventions for carrying ML-KEM public keys are specified in .

SMIME Capabilities Attribute Conventions defines the SMIMECapabilities attribute to announce a partial list of algorithms that an S/MIME implementation can support. When constructing a CMS signed-data content type , a compliant implementation MAY include the SMIMECapabilities attribute that announces support for one or more of the ML-KEM algorithm identifiers. The SMIMECapability SEQUENCE representing the ML-KEM algorithm MUST include one of the ML-KEM OIDs in the capabilityID field. When one of the ML-KEM OIDs appears in the capabilityID field, the parameters MUST NOT be present.

Identifiers All identifiers used to indicate ML-KEM within the CMS are defined in and ; they are reproduced here for convenience:

Security Considerations The Security Considerations sections of and apply to this specification as well. For ongoing discussions of ML-KEM-specific security considerations, refer to . Implementations MUST protect the ML-KEM private key, the key-encryption key, the content-encryption key, message-authentication key, and the content-authenticated-encryption key. Of these keys, all but the private key are ephemeral and MUST be wiped after use. Disclosure of the ML-KEM private key could result in the compromise of all messages protected with that key. Disclosure of the key-encryption key, the content-encryption key, or the content-authenticated-encryption key could result in the compromise of the associated encrypted content. Disclosure of the key-encryption key, the message-authentication key, or the content-authenticated-encryption key could allow modification of the associated authenticated content. Additional considerations related to key management may be found in . The generation of private keys relies on random numbers, as does the encapsulation function of ML-KEM. The use of inadequate pseudorandom number generators (PRNGs) to generate these values can result in little or no security. In the case of key generation, a random 32-byte seed is used to deterministically derive the key (with an additional 32 bytes reserved as a rejection value). In the case of encapsulation, a KEM is derived from the underlying ML-KEM public key encryption algorithm by deterministically encrypting a random 32-byte message for the public key. If the random value is weakly chosen, then an attacker may find it much easier to reproduce the PRNG environment that produced the keys or ciphertext, searching the resulting small set of possibilities for a matching public key or ciphertext value, rather than performing a more complex algorithmic attack against ML-KEM. The generation of quality random numbers is difficult; see Section 3.3 of for some additional information. ML-KEM encapsulation and decapsulation only outputs a shared secret and ciphertext. Implementations MUST NOT use intermediate values directly for any purpose. Implementations SHOULD NOT reveal information about intermediate values or calculations, whether by timing or other "side channels"; otherwise, an opponent may be able to determine information about the keying data and/or the recipient's private key. Although not all intermediate information may be useful to an opponent, it is preferable to conceal as much information as is practical, unless analysis specifically indicates that the information would not be useful to an opponent. Generally, good cryptographic practice employs a given ML-KEM key pair in only one scheme. This practice avoids the risk that vulnerability in one scheme may compromise the security of the other and may be essential to maintain provable security. Parties can gain assurance that implementations are correct through formal implementation validation, such as the NIST Cryptographic Module Validation Program (CMVP) .

IANA Considerations For the ASN.1 Module in , IANA has assigned an OID for the module identifier (84) with a description of "id-mod-cms-ml-kem-2024" in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry.

References Normative References National Institute of Standards and Technology ITU-T National Institute of Standards and Technology sn3rd AWS AWS Cloudflare Informative References NIST NIST Information Technology Laboratory

ASN.1 Module This appendix includes the ASN.1 module for ML-KEM. This module imports objects from , , , and .

Parameter Set Security and Sizes Instead of defining the strength of a quantum algorithm using the imprecise notion of bits of security, NIST has defined security levels by picking a reference scheme, which is expected to offer notable levels of resistance to both quantum and classical attacks. To wit, a KEM algorithm that achieves NIST Post-Quantum Cryptography (PQC) security must require computational resources to break IND-CCA2 security comparable or greater than that required for key search on AES-128, AES-192, and AES-256 for Levels 1, 3, and 5, respectively. Levels 2 and 4 use collision search for SHA-256 and SHA-384 as reference. ML-KEM parameter Sets, NIST Security Level, and Sizes in Bytes

Parameter Set	Level	Encap. Key Size	Decap. Key Size	Ciphertext Size	Shared Secret Size
ML-KEM-512	1	800	1632	768	32
ML-KEM-768	3	1184	2400	1088	32
ML-KEM-1024	5	1568	3168	1568	32

ML-KEM CMS Authenticated-Enveloped-Data Example This example shows the establishment of an AES-128 content-encryption key using:

• ML-KEM-512;
• KEMRecipientInfo key derivation using HKDF with SHA-256; and
• KEMRecipientInfo key wrap using AES-128-KEYWRAP.

In real-world use, the originator would encrypt the content- encryption key in a manner that would allow decryption with their own private key as well as the recipient's private key. This is omitted in an attempt to simplify the example.

Originator CMS Processing Alice obtains Bob's ML-KEM-512 public key: Bob's ML-KEM-512 public key has the following key identifier: Alice generates a shared secret and ciphertext using Bob's ML-KEM-512 public key: Shared secret: Ciphertext: Alice encodes the CMSORIforKEMOtherInfo: Alice derives the key-encryption key from the shared secret and CMSORIforKEMOtherInfo using HKDF with SHA-256: Alice randomly generates a 128-bit content-encryption key: Alice uses AES-128-KEYWRAP to encrypt the content-encryption key with the key-encryption key: Alice encrypts the padded content using AES-128-GCM with the content-encryption key and encodes the AuthEnvelopedData (using KEMRecipientInfo) and ContentInfo, and then sends the result to Bob. The Base64-encoded result is: This result decodes to:

Recipient CMS Processing Bob's ML-KEM-512 private key: Bob decapsulates the ciphertext in the KEMRecipientInfo to get the ML-KEM-512 shared secret, encodes the CMSORIforKEMOtherInfo, derives the key-encryption key from the shared secret and the DER-encoded CMSORIforKEMOtherInfo using HKDF with SHA-256, uses AES-128-KEYWRAP to decrypt the content-encryption key with the key-encryption key, and decrypts the encrypted contents with the content-encryption key, revealing the plaintext content:

Acknowledgements This document borrows heavily from , , , and . Thanks go to the authors of those documents. "Copying always makes things easier and less error prone." - . Thanks to , , and for the detailed review and and for interoperability testing for the examples.