8. Private Key Consistency Testing

Cette section conserve le texte RFC pour ML-KEM dans PKIX, y compris algorithm identifiers, SubjectPublicKeyInfo, private key formats, ASN.1 objects, security considerations et examples.

8.  Private Key Consistency Testing

   When receiving a private key that contains both the seed and the
   expandedKey, the recipient SHOULD perform a seed consistency check to
   ensure that the sender properly generated the private key.
   Recipients that do not perform this seed consistency check avoid
   keygen and compare operations, but they are unable to ensure that the
   seed and expandedKey match.

   If the check is done and the seed and the expandedKey are not
   consistent, the recipient MUST reject the private key as malformed.

   When receiving a private key that contains an expandedKey, [FIPS203]
   stipulates in Section 7.3 that before use, a "hash check" MUST be
   performed.  That section stipulates two other checks on the type and
   length of the expandedKey, which are ensured by this standard.

   The seed consistency check consists of regenerating the expanded form
   from the seed via ML-KEM.KeyGen_internal(d,z) (algorithm 16) using
   the first 32 octets as _d_ and the remaining 32 octets as _z_ and
   ensuring it is bytewise equal to the value presented in the private
   key.

   Appendix C.4 includes some examples of inconsistent seeds and
   expanded private keys.