9. Security Considerations

Questa sezione conserva il testo RFC per ML-KEM in PKIX, inclusi algorithm identifiers, SubjectPublicKeyInfo, private key formats, ASN.1 objects, security considerations ed examples.

9.  Security Considerations

   The Security Considerations section of [RFC5280] applies to this
   specification as well.

   Protection of the private key information, i.e., the seed, is vital
   to public key cryptography.  Disclosure of the private key material
   to another entity can lead to masquerades.

   The generation of private keys relies on random numbers.  The use of
   inadequate pseudorandom number generators (PRNGs) to generate these
   values can result in little or no security.  An attacker may find it
   much easier to reproduce the PRNG environment that produced the keys,
   searching the resulting small set of possibilities, rather than brute
   force searching the whole key space.  The generation of quality
   random numbers is difficult.  ML-KEM key generation has specific
   requirements around randomness generation as described in Section 3.3
   of [FIPS203].

   Many protocols only rely on the IND-CCA security of a KEM.  Some
   (implicitly) require further binding properties, formalized in
   [CDM23].  The private key format influences these binding properties.
   Per [KEMMY24], ML-KEM is LEAK-BIND-K-PK-secure and LEAK-BIND-K-CT-
   secure when using the expanded private key format, but not MAL-BIND-
   K-CT nor MAL-BIND-K-PK secure.  Using the 64-byte seed format
   provides a step up in binding security, and additionally provides
   MAL-BIND-K-CT security (but still does not provide security for MAL-
   BIND-K-PK).

   For more detailed ML-KEM specific security considerations regarding
   this, randomness, misbinding properties, decapsulation failures, key
   reuse, and key checks, refer to [ML-KEM-SEC-CONS].