Crypto Forum D. Connolly Internet-Draft SandboxAQ Intended status: Informational 14 October 2024 Expires: 17 April 2025 ML-KEM for HPKE draft-connolly-cfrg-hpke-mlkem-03 Abstract This document defines Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) KEM options for Hybrid Public-Key Encryption (HPKE). ML-KEM is believed to be secure even against adversaries who possess a cryptographically-relevant quantum computer. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://dconnolly.github.io/draft-connolly-cfrg-hpke-mlkem/draft- connolly-cfrg-hpke-mlkem.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-connolly-cfrg- hpke-mlkem/. Discussion of this document takes place on the Crypto Forum Research Group mailing list (mailto:cfrg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=cfrg. Subscribe at https://www.ietf.org/mailman/listinfo/cfrg/. Source for this draft and an issue tracker can be found at https://github.com/dconnolly/draft-connolly-cfrg-hpke-mlkem. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Connolly Expires 17 April 2025 [Page 1] Internet-Draft hpke-mlkem October 2024 This Internet-Draft will expire on 17 April 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Not an authenticated KEM . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. AuthEncap and AuthDecap . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 6 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 6 B.1. Since draft-connolly-cfrg-hpke-mlkem-00 . . . . . . . . . 7 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 7 C.1. ML-KEM-512 . . . . . . . . . . . . . . . . . . . . . . . 7 C.2. ML-KEM-768 . . . . . . . . . . . . . . . . . . . . . . . 7 C.3. ML-KEM-1024 . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 1.1. Motivation ML-KEM [FIPS203] is a Key-Encapsulation Mechanism (KEM) which is believed to be secure against both classical and quantum cryptographic attacks. For parties that must move to exclusively post-quantum algorithms, this document defines pure post-quantum algorithms for the Hybrid Public-Key Encryption (HPKE) protocol [RFC9180]. ML-KEM as a post-quantum IND-CCA2-secure KEM fits nicely into HPKE's design. Supporting multiple security levels for ML-KEM allows a spectrum of use cases including settings where the (United States) National Institute of Standards (NIST) security category 5 is Connolly Expires 17 April 2025 [Page 2] Internet-Draft hpke-mlkem October 2024 required. 1.2. Not an authenticated KEM ML-KEM is a plain KEM that does not support the static-static key exchange that allows HPKE based on Diffie-Hellman (DH) based KEMs and their (optional) authenticated modes. 2. Conventions and Definitions 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. GenerateKeyPair, DeriveKeyPair, SerializePublicKey, DeserializePublicKey, Encap, Decap, AuthEncap, AuthDecap, Nsecret, Nenc, Npk, and Nsk are defined in Section 4 of [RFC9180]. When used in the Security Consideration section, PK refers to public key and CT refers to ciphertext as modeled in [CDM23]. *TODO*: explain or reference IND-CCA, IND-CCA2, MAL-BIND-K-PK, MAL- BIND-K-CT, and LEAK-BIND-K-PK. 3. Usage [FIPS203] supports two different key formats. This document only supports the 64-byte seed (d, z). This format supports stronger binding properties for ML-KEM than the expanded format. The 64-byte seed format protects against re-encapsulation attacks. This format provides properties closer to the generic DHKEM binding properties defined in Section 4.1 of [RFC9180]. The encapsulation and decapsulation keys are computed, serialized, and deserialized as described in [FIPS203] where the decapsulation keys MUST be in the 64-byte (d, z) format. The 'expanded' format where the decapsulation key is expanded into a variable size based on the parameter set but includes the hash of the encapsulation key is not used. *TODO*: Describe the mapping between GenerateKeyPair, DeriveKeyPair, SerializePublicKey, DeserializePublicKey, Encap, and Decap in HPKE and the functions defined in [FIPS203]. Connolly Expires 17 April 2025 [Page 3] Internet-Draft hpke-mlkem October 2024 3.1. AuthEncap and AuthDecap HPKE-ML-KEM is not an authenticated KEM and does not support AuthEncap() or AuthDecap(), see Section 1.2. 4. Security Considerations HPKE's IND-CCA2 security relies upon the IND-CCA and IND-CCA2 security of the underlying KEM and AEAD schemes, respectively. ML- KEM is believed to be IND-CCA secure via multiple analyses. The HPKE key schedule is independent of the encapsulated KEM shared secret ciphertext and public key of the ciphersuite KEM, and dependent on the shared secret produced by the KEM. If HPKE had committed to the encapsulated shared secret ciphertext and public key, we wouldn't have to worry about the binding properties of the ciphersuite KEM's X-BIND-K-CT and X-BIND-K-PK properties. These computational binding properties for KEMs were formalized in [CDM23]. [CDM23] describes DHKEM as MAL-BIND-K-PK and MAL-BIND-K-CT secure as a result of the inclusion of the serialized DH public keys (the KEM's PK and CT) in the DHKEM Key Derivation Function (KDF). MAL-BIND-K-PK and MAL-BIND-K-CT security ensures that the shared secret K 'binds' (is uniquely determined by) the encapsulation key and/or the ciphertext, even when the adversary is able to create or modify the key pairs or has access to honestly-generated leaked key material. ML-KEM as specified in [FIPS203] with the seed key format provides MAL-BIND-K-CT security and LEAK-BIND-K-PK security [KEMMY24]. LEAK- BIND-K-PK security is resiliant where the involved key pairs are output by the honest key generation algorithm of the KEM and then leaked to the adversary. MAL-BIND-K-CT security strongly binds the shared secret and the ciphertext even when an adversary can manipulate key material like the decapsulation key. ML-KEM using the seed key format (providing MAL-BIND-K-CT and LEAK- BIND-K-PK) nearly matches the binding properties of DHKEM (the default HPKE KEM construction). The ML-KEM ciphertext is strongly bound by the shared secret. The encapsulation key is more weakly bound, and protocols integrating HPKE using ML-KEM even with the seed key format should evaluate whether they need to strongly bind to the PK elsewhere (outside of ML-KEM or HPKE) to be resilient against a MAL adversary, or to achieve other tight binding to the encapsulation key PK to achieve properties like implicit authentication or session independence. Connolly Expires 17 April 2025 [Page 4] Internet-Draft hpke-mlkem October 2024 5. IANA Considerations This document requests/registers two new entries to the "HPKE KEM Identifiers" registry. Value: 0x0040 (please) KEM: ML-KEM-512 Nsecret: 32 Nenc: 768 Npk: 800 Nsk: 1632 Auth: no Reference: This document Value: 0x0041 (please) KEM: ML-KEM-768 Nsecret: 32 Nenc: 1088 Npk: 1184 Nsk: 2400 Auth: no Reference: This document Value: 0x0042 (please) KEM: ML-KEM-1024 Nsecret: 32 Nenc: 1568 Npk: 1568 Nsk: 3168 Connolly Expires 17 April 2025 [Page 5] Internet-Draft hpke-mlkem October 2024 Auth: no Reference: This document 6. References 6.1. Normative References [FIPS203] "Module-Lattice-Based Key-Encapsulation Mechanism Standard", National Institute of Standards and Technology, DOI 10.6028/nist.fips.203, August 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022, . 6.2. Informative References [CDM23] Cremers, C., Dax, A., and N. Medinger, "Keeping Up with the KEMs: Stronger Security Notions for KEMs and automated analysis of KEM-based protocols", 2023, . [KEMMY24] Schmieg, S., "Unbindable Kemmy Schmidt: ML-KEM is neither MAL-BIND-K-CT nor MAL-BIND-K-PK", 2024, . Appendix A. Acknowledgments The authors would like to thank Cas Cremers for their input. Appendix B. Change log *RFC Editor's Note:* Please remove this section prior to publication of a final version of this document. TODO Connolly Expires 17 April 2025 [Page 6] Internet-Draft hpke-mlkem October 2024 B.1. Since draft-connolly-cfrg-hpke-mlkem-00 TODO Appendix C. Test Vectors This section contains test vectors formatted similary to that which are found in [RFC9180], with two changes. First, we only provide vectors for the non-authenticated modes of operation. Secondly, as ML-KEM encapsulation does not involve an ephemeral keypair, we omit the ikmE, skEm, pkEm entries and provide an ier entry instead. The value of ier is the randomness used to encapsulate, so ier[0:32] is the seed that is fed to H in the first step of ML-KEM encapsulation in [FIPS203]. C.1. ML-KEM-512 TODO C.2. ML-KEM-768 TODO C.3. ML-KEM-1024 TODO Author's Address Deirdre Connolly SandboxAQ Email: durumcrustulum@gmail.com Connolly Expires 17 April 2025 [Page 7]