Use of ML-KEM in the Cryptographic Message Syntax (CMS)
Extracted elements (25)
For ML-KEM-768's 192-bit security level, AES-256-Wrap is specified rather than AES-192-Wrap because AES-192 is not as commonly deployed, making the 256-bit key a more interoperable choice.
NIST defines PQC security levels by reference scheme rather than abstract bits of security: a KEM achieving Level 1 must require computational resources comparable to AES-128 key search; Levels 3 and 5 correspond to AES-192 and AES-256 key search respectively. Levels 2 and 4 use SHA-256 and SHA-384 collision search.
The KDF used for the CMS RecipientInfo process MAY be different from the KDF used internally within the ML-KEM algorithm itself. This separation is explicit in the KEMRecipientInfo design, allowing independent KDF agility at the CMS layer.
ML-KEM is the name of the final NIST-standardized version and is incompatible with pre-standards versions often called 'Kyber'. Implementations must not conflate the two.
A CMS originator MUST implement the Encapsulate() function and a CMS recipient MUST implement the Decapsulate() function to support ML-KEM.
Implementations MUST confirm that the HKDF L parameter is consistent with the key size of the key-encryption algorithm.
Implementations MUST protect the ML-KEM private key, key-encryption key, content-encryption key, message-authentication key, and content-authenticated-encryption key. All keys except the private key are ephemeral and MUST be wiped after use.
Implementations MUST support HKDF with SHA-256 using the id-alg-hkdf-with-sha256 OID. When this OID appears within AlgorithmIdentifier, the parameter field MUST be absent.
Implementations SHOULD NOT reveal information about intermediate values or calculations, whether by timing or other side channels, as an opponent may be able to determine keying data or the recipient's private key.
Implementations supporting ML-KEM-512 MUST support AES-Wrap-128 (id-aes128-wrap). Implementations supporting ML-KEM-768 or ML-KEM-1024 MUST support AES-Wrap-256 (id-aes256-wrap).
ML-KEM encapsulation and decapsulation only outputs a shared secret and ciphertext. Implementations MUST NOT use intermediate values directly for any purpose.
The kem field of KEMRecipientInfo MUST contain one of id-alg-ml-kem-512, id-alg-ml-kem-768, or id-alg-ml-kem-1024.
The SMIMECapability SEQUENCE for ML-KEM MUST include the ML-KEM OID in capabilityID. When one of the ML-KEM OIDs appears in capabilityID, parameters MUST NOT be present.
The underlying components used with ML-KEM in KEMRecipientInfo SHOULD be consistent with a minimum desired security level, matching KDF preimage strength and symmetric key-encryption strength to the chosen parameter set.
The version field of KEMRecipientInfo MUST be 0.
When ML-KEM is employed for a recipient, the RecipientInfo alternative for that recipient MUST be OtherRecipientInfo using the KEMRecipientInfo structure as defined in RFC 9629.
KEMRecipientInfo fields: version (0), rid (recipient certificate/key identifier), kem (ML-KEM algorithm OID), kemct (ciphertext for recipient), kdf (key derivation algorithm), kekLength (key-encryption key size in octets), ukm (optional KDF input), wrap (key-encryption algorithm).
ML-KEM defines three functions: KeyGen() producing a public encapsulation key (ek) and private decapsulation key (dk); Encapsulate(ek) producing ciphertext (c) and shared secret (ss); Decapsulate(dk, c) producing the shared secret (ss). All security levels use SHA3-256, SHA3-512, SHAKE128, and SHAKE256 internally.
ML-KEM parameter sets with NIST security levels and sizes in bytes: ML-KEM-512 (Level 1, encap key 800, decap key 1632, ciphertext 768, shared secret 32); ML-KEM-768 (Level 3, encap key 1184, decap key 2400, ciphertext 1088, shared secret 32); ML-KEM-1024 (Level 5, encap key 1568, decap key 3168, ciphertext 1568, shared secret 32).
When used with KEMRecipientInfo, HKDF salt is unused (zero-length string). The IKM, info, and L parameters correspond to RFC 9629 Section 5 KDF inputs. The info parameter is independently generated by originator and recipient.
IANA has assigned OID 84 with description 'id-mod-cms-ml-kem-2024' in the 'SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)' registry for the ASN.1 module defined in this document.
Disclosure of the ML-KEM private key could compromise all messages protected with that key. Disclosure of ephemeral keys (key-encryption key, content-encryption key, content-authenticated-encryption key) compromises associated encrypted or authenticated content.
Good cryptographic practice employs a given ML-KEM key pair in only one scheme. This avoids the risk that a vulnerability in one scheme compromises the security of another and may be essential to maintain provable security.
Inadequate pseudorandom number generators (PRNGs) used for key generation or encapsulation can result in little or no security. Key generation uses a random 32-byte seed; encapsulation deterministically encrypts a random 32-byte message. Weak randomness allows an attacker to search a small set of possibilities rather than mount an algorithmic attack.
ML-KEM OID assignments: id-alg-ml-kem-512 ::= { kems 1 }, id-alg-ml-kem-768 ::= { kems 2 }, id-alg-ml-kem-1024 ::= { kems 3 }, where kems ::= { nistAlgorithms 4 }. HKDF: id-alg-hkdf-with-sha256 at { iso member-body us rsadsi pkcs pkcs-9 smime alg 28 }.