Zum Hauptinhalt springen

1. Introduction

Dieser Abschnitt bewahrt den RFC-Text zur Verwendung von ML-KEM mit CMS, einschliesslich KEMRecipientInfo, HKDF, AES Key Wrap, ASN.1 identifiers, IANA registration und authenticated-enveloped-data example.

1.  Introduction

   The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is an
   IND-CCA2-secure Key Encapsulation Mechanism (KEM) standardized in
   [FIPS203] by the NIST PQC Project [NIST-PQ].  ML-KEM is the name
   given to the final standardized version and is incompatible with pre-
   standards versions, often called "Kyber".

   [RFC9629] 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 [FIPS203], 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.

1.1.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  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.  Appendix B
   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 [FIPS203]:

   KeyGen() -> (ek, dk):  Generate the public encapsulation key (ek) and
      a private decapsulation key (dk).  [FIPS203] 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 [FIPS203] 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 [FIPS203]
      expands the seed to ek and dk.  See Section 6 of [RFC9935] 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 [FIPS203] 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 [FIPS203] 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 Section 8 of [RFC9935] 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.
Letztes Update am