4. Security Considerations

Questa sezione conserva il testo RFC sull'uso di ML-KEM con CMS, inclusi KEMRecipientInfo, HKDF, AES Key Wrap, ASN.1 identifiers, IANA registration e authenticated-enveloped-data example.

4.  Security Considerations

   The Security Considerations sections of [RFC9935] and [RFC9629] apply
   to this specification as well.

   For ongoing discussions of ML-KEM-specific security considerations,
   refer to [MLKEM-SEC-CONS].

   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
   [NIST.SP.800-57pt1r5].

   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 [FIPS203] 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) [CMVP].