Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE
draft-barnes-hpke-pq-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Richard Barnes | ||
| Last updated | 2025-04-13 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-barnes-hpke-pq-00
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,
<https://doi.org/10.6028/nist.fips.186-5>.
[FIPS203] "Module-lattice-based key-encapsulation mechanism
standard", National Institute of Standards and Technology
(U.S.), DOI 10.6028/nist.fips.203, August 2024,
<https://doi.org/10.6028/nist.fips.203>.
[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,
<https://datatracker.ietf.org/doc/html/draft-barnes-hpke-
hpke-00>.
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,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
hybrid-kems-03>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/rfc/rfc7748>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
pqc-engineers-09>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-24>.
[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, <https://www.rfc-editor.org/rfc/rfc9420>.
[RFC9458] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458,
DOI 10.17487/RFC9458, January 2024,
<https://www.rfc-editor.org/rfc/rfc9458>.
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]