HPKE Publication, Kept Efficient R. Barnes Internet-Draft Your Organization Here Intended status: Standards Track 13 April 2025 Expires: 15 October 2025 Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE draft-barnes-hpke-pq-00 Abstract Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post- quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attack by a 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://hpkewg.github.io/hpke-pq/draft-barnes-hpke-pq.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-barnes-hpke-pq/. Discussion of this document takes place on the HPKE Publication, Kept Efficient mailing list (mailto:hpke@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/hpke. Subscribe at https://www.ietf.org/mailman/listinfo/hpke/. Source for this draft and an issue tracker can be found at https://github.com/hpkewg/hpke-pq. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Barnes Expires 15 October 2025 [Page 1] Internet-Draft PQ HPKE April 2025 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." This Internet-Draft will expire on 15 October 2025. Copyright Notice Copyright (c) 2025 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. ML-KEM . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Hybrids of ML-KEM with DH . . . . . . . . . . . . . . . . . . 6 5. SHA-3 as an HPKE KDF . . . . . . . . . . . . . . . . . . . . 6 6. Selection of AEAD algorithms . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8.1. Updated ML-KEM KEM Entries . . . . . . . . . . . . . . . 7 8.2. PQ/T Hybrid KEM Entries . . . . . . . . . . . . . . . . . 7 8.3. SHA-3 KDF Entries . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Barnes Expires 15 October 2025 [Page 2] Internet-Draft PQ HPKE April 2025 1. Introduction A cryptographically relevant quantum computer may or may not exist as of this writing. The conventional wisdom, however, is that if one does not already, then it likely will within the lifetime of information that is cryptographically protected today. Such a computer would have the ability to infer decapsulation keys from encapsulation keys used for traditional KEMs, e.g., KEMs based on Diffie-Hellman over finite fields or elliptic curves. And it would be able to do this not just for data encrypted after the creation of the computer, but also for any information observed by the attacker previously, and stored for later decryption. This is the so-called "harvest now, decrypt later" attack. It is thus a high priority for many organizations right not to migrate key exchange technologies to use "post-quantum" (PQ) algorithms, which are resistant to attack by a quantum computer [I-D.ietf-pquip-pqc-engineers]. Since these PQ algorithms are relatively new, there is also interest in hybrid constructions combining PQ algorithms with traditional KEMs, so that if the PQ algorithm fails, then the traditional algorithm will still provide security, at least against classical attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme [I-D.barnes-hpke-hpke]. It is the foundation of the Messaging Layer Security (MLS) protocol, the Oblivious HTTP protocol, and the TLS Encrypted ClientHello extension [RFC9420] [RFC9458] [I-D.ietf-tls-esni]. This document defines a collection of PQ and PQ/T KEM algorithms for HPKE, which allows HPKE to provide post-quantum security, as discussed in Section 7: * ML-KEM-768 * ML-KEM-1024 * X25519 + ML-KEM-768 * P-256 + ML-KEM-768 * P-384 + ML-KEM-1024 ML-KEM, X25519, and P-256/P-384 are defined in [FIPS203], [RFC7748], and [FIPS186], respectively. Barnes Expires 15 October 2025 [Page 3] Internet-Draft PQ HPKE April 2025 This selection of KEM algorithms was chosen to provide a reasonably consolidated set of algorithms (in the interest of broad interoperability), while still allowing HPKE users flexibility along a few axes: * Pure PQ vs. PQ/T hybrid * CFRG-defined vs. NIST-defined elliptic curves * Different security levels (NIST category 3 vs. category 5) We also define HPKE KDF algorithms based on the SHA-3 family of hash functions. SHA-3 is used internally to ML-KEM, and so it could be convenient for HPKE users using the KEM algorithms in this document to rely solely on SHA-3. 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. We generally use the terminology defined in the HPKE specification [I-D.barnes-hpke-hpke]. There are two meanings of "hybrid" in this document. In the context of "hybrid public key encryption", it refers to the combination of an asymmetric KEM operaiton and a symmetric AEAD operation. In the context of "PQ/T hybrid", refers to the combination of PQ and traditional KEMs. For clarity, we always use "HPKE" for the former, and "PQ/T hybrid" for the latter. 3. ML-KEM The NIST Module-Lattice-Based Key-Encapsulation Mechanism is defined in [FIPS203]. In this section, we define how to implement the HPKE KEM interface using ML-KEM. The HPKE DeriveKeyPair() function corresponds to the function ML- KEM.KeyGen_internal() in [FIPS203]. The input ikm MUST be exactly Nsk = 64 bytes long. The d and z inputs to ML-KEM.KeyGen_internal() are the first and last 32-byte segments of ikm, respectively. The output skX is the generated decapsulation key and the output pkX is the generated encapsulation key. Barnes Expires 15 October 2025 [Page 4] Internet-Draft PQ HPKE April 2025 def DeriveKeyPair(ikm): if len(ikm) != 64: raise DeriveKeyPairError d = ikm[:32] z = ikm[32:] dk = ikm (ek, _) = ML-KEM.KeyGen_internal(d, z) return (dk, ek) The GenerateKeyPair() function is simply DeriveKeyPair() with a pseudorandom ikm value. As long as the bytes supplied by random() meet the randomness requirements of [FIPS203], this corresponds to the ML-KEM.KeyGen() function, with the distinction that the decapsulation key is returned in seed format rather than the expanded form returned by ML-KEM.KeyGen(). def GenerateKeyPair(): dz = random(64) return DeriveKeyPair(dz) The SerializePublicKey() and DeserializePublicKey() functions are both the identity function, since the ML-KEM already uses fixed- length byte strings for public encapsulation keys. The length of the byte string is determined by the ML-KEM parameter set in use. The Encap() function corresponds to the function ML-KEM.Encaps() in [FIPS203], where an ML-KEM encapsulation key check failure causes an HPKE EncapError. The Decap() function corresponds to the function ML-KEM.Decaps() in [FIPS203], an ML-KEM ciphertext check failure, decapsulation key check failure, or hash check failure cause an HPKE DecapError. To be explicit, we derive the expanded decapsulation key from the 64-byte seed format and invoke ML-KEM.Decaps() with it: def Decap(enc, skR): d = skR[:32] z = skR[32:] (_, dk) = ML-KEM.KeyGen_internal(d, z) return ML-KEM.Decaps(dk, enc) The AuthEncap() and AuthDecap() functions are not implemented. The constants Nsecret and Nsk are always 32 and 64, respectively. The constants Nenc and Npk depend on the ML-KEM parameter set in use; they are specified in Table 1. Barnes Expires 15 October 2025 [Page 5] Internet-Draft PQ HPKE April 2025 4. Hybrids of ML-KEM with DH [[ TODO: DH + ML-KEM, in appropriate combinations ]] [[ TODO: Decide whether to use DHKEM, or use DH directly ]] [[ TODO: Define HPKE API methods for the combination ]] 5. SHA-3 as an HPKE KDF [[ TODO: Defer until draft-ietf-hpke-hpke has a suitable definition ]] 6. Selection of AEAD algorithms As discussed in Section 2.1 of [I-D.ietf-pquip-pqc-engineers], the advent of quantum computers does not necessarily require changes in the AEAD algorithms used in HPKE. However, some compliance regimes call for the use of AEAD algorithms with longer key lengths, for example, the AES-256-GCM or ChaCha20Poly1305 algorithms registered for HPKE instead of AES-128-GCM. 7. Security Considerations As discussed in the HPKE Security Considerations, HPKE is an IND-CCA2 secure public-key encryption scheme if the KEM it uses is IND-CCA2 secure. It follows that HPKE is IND-CCA2 secure against a quantum attacker if it uses a KEM that provides IND-CCA2 security against a quantum attacker, i.e., a PQ KEM. The KEM algorithms defined in this document provide this level of security. ML-KEM itself is IND-CCA2 secure, and the IND-CCA2 security of the hybrid constructions used in this document is established in [I-D.irtf-cfrg-hybrid-kems]. [[ TODO: Binding properties ]] 8. IANA Considerations This section requests that IANA perform three actions: 1. Update the entries in HPKE KEM Identifiers registry corresponding to ML-KEM algorithms. 2. Add entries to the HPKE KEM Identifiers registry for the PQ/T hybrid KEMs defined in this document. 3. Add entries to the HPKE KDF Identifiers registry for the SHA-3 KDFs defined in this document. Barnes Expires 15 October 2025 [Page 6] Internet-Draft PQ HPKE April 2025 8.1. Updated ML-KEM KEM Entries IANA should replace the entries in the HPKE KEM Identifiers registry for values 0x0040, 0x0041, and 0x0042 with the following values: +========+=============+=========+====+====+===+======+===========+ | Value | KEM | Nsecret |Nenc|Npk |Nsk| Auth | Reference | +========+=============+=========+====+====+===+======+===========+ | 0x0040 | ML-KEM-512 | 32 |768 |800 |64 | no | RFCXXXX | +--------+-------------+---------+----+----+---+------+-----------+ | 0x0041 | ML-KEM-768 | 32 |1088|1184|64 | no | RFCXXXX | +--------+-------------+---------+----+----+---+------+-----------+ | 0x0042 | ML-KEM-1024 | 32 |1568|1568|64 | no | RFCXXXX | +--------+-------------+---------+----+----+---+------+-----------+ Table 1: Updated ML-KEM entries for the HPKE KEM Identifiers table The only change being made is to update the "Reference" column to refer to this document. 8.2. PQ/T Hybrid KEM Entries [[ TODO: Register KEM values ]] 8.3. SHA-3 KDF Entries [[ TODO: Register KDF values ]] 9. References 9.1. Normative References [FIPS186] "Digital Signature Standard (DSS)", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.186-5, February 2023, . [FIPS203] "Module-lattice-based key-encapsulation mechanism standard", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.203, August 2024, . [I-D.barnes-hpke-hpke] Barnes, R., Bhargavan, K., Lipp, B., and C. A. Wood, "Hybrid Public Key Encryption", Work in Progress, Internet-Draft, draft-barnes-hpke-hpke-00, 20 March 2025, . Barnes Expires 15 October 2025 [Page 7] Internet-Draft PQ HPKE April 2025 [I-D.irtf-cfrg-hybrid-kems] Connolly, D., "Hybrid PQ/T Key Encapsulation Mechanisms", Work in Progress, Internet-Draft, draft-irtf-cfrg-hybrid- kems-03, 25 February 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [I-D.ietf-pquip-pqc-engineers] Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek, T., and M. Ounsworth, "Post-Quantum Cryptography for Engineers", Work in Progress, Internet-Draft, draft-ietf- pquip-pqc-engineers-09, 13 February 2025, . [I-D.ietf-tls-esni] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-24, 20 March 2025, . [RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, July 2023, . [RFC9458] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458, DOI 10.17487/RFC9458, January 2024, . Barnes Expires 15 October 2025 [Page 8] Internet-Draft PQ HPKE April 2025 Acknowledgments TODO acknowledge. Author's Address Richard Barnes Your Organization Here Email: rlb@ipv.sx Barnes Expires 15 October 2025 [Page 9]