Authenticated Modes for HPKE
draft-ms-hpke-auth-modes-01
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) | |
|---|---|---|---|
| Authors | Giulio Berra , Cory Myers , Rowen S. | ||
| Last updated | 2026-05-15 | ||
| 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-ms-hpke-auth-modes-01
Network Working Group G. Berra, Ed.
Internet-Draft C. F. Myers, Ed.
Intended status: Standards Track R. Shane, Ed.
Expires: 16 November 2026 Freedom of the Press Foundation
15 May 2026
Authenticated Modes for HPKE
draft-ms-hpke-auth-modes-01
Abstract
The standards-track [I-D.ietf-hpke-hpke] supersedes the informational
[RFC9180], omitting its authenticated modes mode_auth and
mode_auth_psk. This document restores mode_auth_psk mode as a strict
extension and illustrates how the restored mode can be used with a
post-quantum "shared secret" as the PSK in order to achieve hybrid
PQ/T confidentiality while transitioning to quantum-resistant
encryption, without deprecating the classical implicit authentication
on which many applications still rely.
This extension requires only the addition of AuthEncap()/AuthDecap()
to the DHKEM, the definition of four setup functions, and a change in
VerifyPSKInputs(). The extension does not alter the externally
observable behavior of the existing HPKE modes standardized in
[I-D.ietf-hpke-hpke]. Although AuthEncap()/AuthDecap() reintroduce
the functionality of mode_auth, the mode itself is not restored,
since it cannot provide quantum resistance.
This document discusses the transitional nature of the AuthPSK
construction and its security properties as a transitional step
towards quantum resistance. In particular, this document illustrates
how the restored mode_auth_psk can be used to provide ready-made KEM
combiner-like functionality ([I-D.ounsworth-cfrg-kem-combiners])
without requiring downstream API users to manage their own encryption
context.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ms-hpke-auth-modes/.
Source for this draft and an issue tracker can be found at
https://github.com/cfm/draft-ms-hpke-auth-modes.
Berra, et al. Expires 16 November 2026 [Page 1]
Internet-Draft HPKE Authenticated Modes May 2026
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."
This Internet-Draft will expire on 16 November 2026.
Copyright Notice
Copyright (c) 2026 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. Authenticated Pre-Shared Key Mode Extension to
I-D.ietf-hpke-hpke . . . . . . . . . . . . . . . . . . . 4
3.1. Mode Identifiers . . . . . . . . . . . . . . . . . . . . 4
3.2. Exclusion of 0x02 mode_auth from Mode Identifiers . . . . 4
3.3. DHKEM Extension: AuthEncap() and AuthDecap() . . . . . . 4
3.4. VerifyPSKInputs . . . . . . . . . . . . . . . . . . . . . 5
3.5. Setup Functions . . . . . . . . . . . . . . . . . . . . . 6
3.6. Input Validation and Error Handling . . . . . . . . . . . 6
3.7. DHAKEM with PSK . . . . . . . . . . . . . . . . . . . . . 6
3.7.1. PQ/T Hybrid Construction . . . . . . . . . . . . . . 6
3.7.2. AKEM/PQ KEM "Combiner" (Informative) . . . . . . . . 7
3.8. Motivation (Informative) . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
Berra, et al. Expires 16 November 2026 [Page 2]
Internet-Draft HPKE Authenticated Modes May 2026
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
[I-D.ietf-hpke-hpke] is the standards-track successor to the
informational [RFC9180] and omits the authenticated modes mode_auth
and mode_auth_psk to simplify the standard. However, some
applications make use of the type of implicit sender authentication
provided by these modes.
The normative portion of this document is small. It restores
mode_auth_psk as a strict extension to [I-D.ietf-hpke-hpke]. This
requires AuthEncap()/AuthDecap() from the DHKEM construction in
[RFC9180], and a modified VerifyPSKInputs(). The externally
observable behavior of existing HPKE modes is unchanged. AuthEncap()
computes a static-static DH value DH(skS, pkR) alongside the
ephemeral-static value and mixes both into the key derivation,
binding the output to the sender's key pair.
Although the functionality of mode_auth is re-introduced, the mode
identifer itself, which relies solely on DHKEM, is not restored,
since it cannot provide quantum-resistant encryption. mode_auth is
instead treated as a building block to mode_auth_psk, as seen in
Section 3.7.
Section 3.3 describes how the restored mode_auth_psk can be used to
achieve hybrid PQ/T confidentiality as defined in Section 5 of
[RFC9794] during the transition to quantum-resistant encryption.
Section 3.8 discusses the transitional nature of this construction
and reviews the guidance available to application developers looking
to begin the transition to quantum-resistant encryption with existing
libraries and APIs.
To motivate the extension, Section 3.7.2 discusses how the extension
can be used as a type of black-box KEM combiner
([I-D.ounsworth-cfrg-kem-combiners]), similar to the construction
proposed in [Alwen2023], to allow application developers to begin the
transition to quantum-resistant encryption via usable libraries and
APIs.
Berra, et al. Expires 16 November 2026 [Page 3]
Internet-Draft HPKE Authenticated Modes May 2026
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.
Terms from [I-D.ietf-hpke-hpke] are used without redefinition;
particular reference is made to the *DHKEM* construction Section 4.1
of [RFC9180]. The following additional term is used herein:
* *AKEM:* a KEM whose encapsulation additionally takes the sender's
static private key and implicitly binds the shared secret to it.
3. Authenticated Pre-Shared Key Mode Extension to [I-D.ietf-hpke-hpke]
This section specifies the additions to [I-D.ietf-hpke-hpke] required
to restore mode_auth_psk. These extensions are defined so that the
externally observable behavior of the existing HPKE modes is
unchanged, although this document modifies the VerifyPSKInputs()
procedure in [I-D.ietf-hpke-hpke].
3.1. Mode Identifiers
The reserved entry for value 0x03 in Table 1 of [I-D.ietf-hpke-hpke]
is replaced with the following mode identifier, as originally
specified in Table 1 of [RFC9180]:
mode_auth_psk = 0x03
The value 0x02 remains reserved.
3.2. Exclusion of 0x02 mode_auth from Mode Identifiers
Although restoring the AuthEncap() and AuthDecap() functions would
also allow for restoring mode_auth, this mode cannot offer quantum-
resistant encryption, and its identifier is therefore not
reintroduced.
3.3. DHKEM Extension: AuthEncap() and AuthDecap()
The following two functions are added to the DHKEM, extending it to
an AKEM (DHAKEM). They are reproduced verbatim from Section 4.1 of
[RFC9180]. All helper functions (GenerateKeyPair, DH,
SerializePublicKey, DeserializePublicKey, ExtractAndExpand) are as
defined in [I-D.ietf-hpke-hpke].
Berra, et al. Expires 16 November 2026 [Page 4]
Internet-Draft HPKE Authenticated Modes May 2026
def AuthEncap(pkR, skS):
skE, pkE = GenerateKeyPair()
dh = concat(DH(skE, pkR), DH(skS, pkR))
enc = SerializePublicKey(pkE)
pkRm = SerializePublicKey(pkR)
pkSm = SerializePublicKey(pk(skS))
kem_context = concat(enc, pkRm, pkSm)
shared_secret = ExtractAndExpand(dh, kem_context)
return shared_secret, enc
def AuthDecap(enc, skR, pkS):
pkE = DeserializePublicKey(enc)
dh = concat(DH(skR, pkE), DH(skR, pkS))
pkRm = SerializePublicKey(pk(skR))
pkSm = SerializePublicKey(pkS)
kem_context = concat(enc, pkRm, pkSm)
shared_secret = ExtractAndExpand(dh, kem_context)
return shared_secret
Note that the AuthEncap() and AuthDecap() functions are vulnerable to
key-compromise impersonation (KCI): the assurance that the shared
secret was generated by the holder of the private key skS does not
hold if the recipient private key skR is compromised. See Section 4
for further discussion; see Section 3.5 for integration of a pre-
shared key.
3.4. VerifyPSKInputs
The VerifyPSKInputs() function defined in Section 5.1 of [RFC9180]
and [I-D.ietf-hpke-hpke] is extended to handle the reintroduced
mode_auth_psk. The updated function replaces the original:
def VerifyPSKInputs(mode, psk, psk_id):
got_psk = (psk != default_psk)
got_psk_id = (psk_id != default_psk_id)
if got_psk != got_psk_id:
raise Exception("Inconsistent PSK inputs")
if got_psk and mode in [mode_base]:
raise Exception("PSK input provided when not needed")
if (not got_psk) and mode in [mode_psk, mode_auth_psk]:
raise Exception("Missing required PSK input")
Berra, et al. Expires 16 November 2026 [Page 5]
Internet-Draft HPKE Authenticated Modes May 2026
The only change from the original is that mode_psk is replaced by
[mode_psk, mode_auth_psk] in the final guard.
3.5. Setup Functions
The following four setup functions are reproduced verbatim from
Sections 5.1.3 and 5.1.4 of [RFC9180]. KeyScheduleS()/KeyScheduleR()
and AuthEncap()/AuthDecap() are as defined in [I-D.ietf-hpke-hpke]
and Section 3.3 respectively.
def SetupAuthPSKS(pkR, info, psk, psk_id, skS):
shared_secret, enc = AuthEncap(pkR, skS)
return enc, KeyScheduleS(mode_auth_psk, shared_secret, info,
psk, psk_id)
def SetupAuthPSKR(enc, skR, info, psk, psk_id, pkS):
shared_secret = AuthDecap(enc, skR, pkS)
return KeyScheduleR(mode_auth_psk, shared_secret, info,
psk, psk_id)
3.6. Input Validation and Error Handling
In addition to the validation requirements in Section 7.1.4 of
[I-D.ietf-hpke-hpke], the recipient MUST validate the sender's static
public key pkS before use in AuthDecap(), applying the same
validation rules as for other public key inputs. Validation failure
MUST yield a ValidationError.
3.7. DHAKEM with PSK
This section illustrates how the authenticated mode defined in
Section 3 can be used. Any AEAD identifier from [I-D.ietf-hpke-hpke]
may be used; the resulting context supports Seal(), Open(), and
Export(). Key generation follows GenerateKeyPair() from
[I-D.ietf-hpke-hpke].
mode_auth_psk may be used via its setup function: the sender calls
SetupAuthPSKS() and the receiver calls SetupAuthPSKR(), with a pre-
shared key psk and a PSK identifier psk_id, as defined in
Section 3.5. As in [RFC9180], both parties are assumped to have been
provisioned with the PSK value psk and another byte string psk_id.
This mode SHOULD be used with a quantum-resistant PSK value as
described below in order to offer hybrid PQ/T confidentiality
properties.
3.7.1. PQ/T Hybrid Construction
Berra, et al. Expires 16 November 2026 [Page 6]
Internet-Draft HPKE Authenticated Modes May 2026
def HybridSetupS(pkR, skS, info, psk, psk_id):
enc_dh, ctx = SetupAuthPSKS(pkR, info, psk, psk_id, skS)
return enc_dh, ctx
def HybridSetupR(enc, skR, pkS, info, psk, psk):
return SetupAuthPSKR(enc_dh, skR, info, psk, psk_id, pkS)
The suite_id in the HPKE key schedule reflects only the ciphersuite
(KEM_ID, KDF_ID, AEAD_ID), where KEM_ID is a DHAKEM. Generation and
distribution of a quantum-safe PSK value is left to the application.
*Hybrid confidentiality.* KeyScheduleS()/KeyScheduleR() delegate to
CombineSecrets, for which [I-D.ietf-hpke-hpke] defines two variants.
In CombineSecrets_TwoStage(), the combination is secret =
LabeledExtract(dhkem_shared_secret, "secret", psk), equivalent to
HKDF-Extract(salt = dhkem_shared_secret, IKM = psk) [RFC5869]. In
CombineSecrets_OneStage(), dhkem_shared_secret and psk are length-
prefixed and concatenated before a single LabeledDerive() call. In
both cases, dhkem_shared_secret and psk enter the combination as
independent inputs. The intended design property is that secret
remains pseudorandom as long as at least one of the two inputs is---
meaning an adversary would need to attack both the classical DH-based
component and the PQ-KEM to recover secret, as seen in
[I-D.ounsworth-cfrg-kem-combiners] and subsequently,
[I-D.draft-connolly-cfrg-xwing-kem-10].
Whether this property holds formally for a specific CombineSecrets
variant depends on that variant's security analysis, which is outside
the scope of this document.
*Authentication.* This mode retains the implicit sender
authentication properties of DHAKEM described in [RFC9180]. A
quantum adversary with access to the PSK can also forge authenticated
messages.
*PSK freshness.* The PSK psk MUST satisfy the entropy requirement in
Section 9.5 of [I-D.ietf-hpke-hpke] (32 bytes of uniform randomness).
3.7.2. AKEM/PQ KEM "Combiner" (Informative)
Using mode_auth_psk with the shared secret from a PQ-KEM as the
provided "psk" value allows application developers to provide hybrid
PQ/T security properties using ready-made libraries and APIs.
Although this psk value is not a true pre-shared key, this document
adopts the pskAPKE terminology from [Alwen2023].
Berra, et al. Expires 16 November 2026 [Page 7]
Internet-Draft HPKE Authenticated Modes May 2026
The result is a KEM combiner-style construction
[I-D.ounsworth-cfrg-kem-combiners] that provides hybrid PQ/T
confidentiality and classical authentication, without requiring
developers to manage their own encryption context---a frequent source
of developer error and a motivating factor for the API design choices
of [RFC9180].
In addition to the keypair specified in Section 3.5, the receiver
holds an additional post-quantum keypair, (skR_pq, pkR_pq). Prior to
setting up an HPKE encryption context (either via Setup or via a
single-shot API), the sender uses receiver's PQ public key pkR_pq to
generate a shared secret and its encapsulation (ss_pq, enc_pq), and
uses ss_pq as the psk and a static identifier as the PSK identifier.
The ciphertext encapsulation of ss_pq, enc_pq, is included in info to
bind it to the key schedule.
An example construction is provided below, with reference to the
following terms:
* PQKEM: a post-quantum KEM, e.g., ML-KEM [FIPS203] or an algorithm
from [I-D.ietf-hpke-pq].
* PQKEM.Encap(pkR_pq): PQ-KEM encapsulation; returns (enc_pq,
ss_pq).
* PQKEM.Decap(enc_pq, skR_pq): PQ-KEM decapsulation; returns ss_pq.
* Nenc_pq: the fixed ciphertext length of the chosen PQ-KEM, in
bytes.
def HybridSetupS(pkR, pkR_pq, skS, info):
enc_pq, ss_pq = PQKEM.Encap(pkR_pq)
enc_dh, ctx = SetupAuthPSKS(pkR, concat(info, enc_pq), ss_pq, enc_pq, skS)
return concat(enc_dh, enc_pq), ctx
def HybridSetupR(enc, skR, skR_pq, pkR_pq, pkS, info):
enc_dh, enc_pq = enc[:Nenc], enc[Nenc:]
ss_pq = PQKEM.Decap(enc_pq, skR_pq)
return SetupAuthPSKR(enc_dh, skR, concat(info, enc_pq), ss_pq, enc_pq, pkS)
*Classical (implicit) sender authentication:* This construction
provides only classical sender authentication is provided. In
contrast to Section 3.7.1, this "psk" value provides no sender
authentication, as it is constructed rather than pre-shared. This
limitation is assessed in Section 3.8.
Berra, et al. Expires 16 November 2026 [Page 8]
Internet-Draft HPKE Authenticated Modes May 2026
The info parameter will exceed 64 bytes. Implementors must ensure
their choice of algorithms and underlying implementation can support
parameters of this length.
The shared secret ss_pq must satisfy the entropy requirement in
Section 9.5 of [I-D.ietf-hpke-hpke].
Implementations should verify len(enc) == Nenc + Nenc_pq and reject
encapsulations of any other length. A fresh (ss_pq, enc_pq) pair
should be generated for each encapsulation; reuse of a prior enc_pq
is prohibited. The suite_id in the HPKE key schedule reflects only
the ciphersuite (AKEM_ID, KDF_ID, AEAD_ID); the PQ-KEM algorithm
identity should be conveyed via application-layer framing when
multiple PQ-KEM algorithms are supported.
Note that [Alwen2023] describes a related hybrid construction in
which a PQ _AKEM_ (rather than an unauthenticated KEM) is used to
generate the PSK, which would additionally provide post-quantum
sender authentication; that stronger construction is outside the
scope of this document.
3.8. Motivation (Informative)
Application developers are in a bind: though they may be aware of
advice to implement quantum-resistant encryption on an accelerated
timeline, they may encounter rapidly-evolving guidance on best
practices, a lack of direct parity with classical constructions, and
a relative paucity of stable libraries and APIs [PQCodePkgs].
Developers looking to offer hybrid PQ/T encryption in their own
applications, for reasons described for example in Section 2.1 of
[RFC9370], can look to early-stage implementations of
[I-D.draft-connolly-cfrg-xwing-kem-10], or may refer to the now-
expired [I-D.ounsworth-cfrg-kem-combiners], but will need to manage
their own combiner implementation.
On the other hand, production-ready quantum-resistant authentication
is still maturing. Standardized schemes offer non-repudiable,
signature-based authentication, which is not a direct replacement for
the type of DH-based implicit authentication described in the
authenticated modes of [RFC9180] or this document.
Although the strategy of hybrid encryption with classical
authentication is not as straightforward to communicate as
unauthenticated hybrid encryption that forgoes implict authentication
entirely, protocols such as Noise IK, as used in [Wireguard2020],
indicate that this strategy has real-world uses until quantum-
resistant authentication methods become more available.
Berra, et al. Expires 16 November 2026 [Page 9]
Internet-Draft HPKE Authenticated Modes May 2026
Allowing application developers to deploy quantum-resistant
encryption as a transitional measure without deprecating the
classical authentication properties of their application provides a
path towards quantum readiness, similar in concept to Section 3 of
[RFC8773] and Section 5.1 of [RFC9257], which also discuss the
introduction of quantum-resistent PSK as a transitional measure.
4. Security Considerations
The sender-authentication and key-compromise impersonation (KCI)
properties of mode_auth_psk are as described in Sections 9.1 and
9.1.1 of [RFC9180], which apply without change to the functions
defined in Section 3. Security properties specific to the hybrid PQ/
T construction are discussed informatively in Section 3.7.1.
The formal security of the DHKEM authenticated modes under the Gap-DH
assumption is established in [Alwen2021]. The security of
mode_auth_psk---termed AuthPSK in [Alwen2023]---is analyzed there as
the pskAPKE scheme.
5. IANA Considerations
This document requests no IANA actions; all identifiers are drawn
from registries defined in [I-D.ietf-hpke-hpke].
6. References
6.1. Normative References
[I-D.ietf-hpke-hpke]
Barnes, R., Bhargavan, K., Lipp, B., and C. A. Wood,
"Hybrid Public Key Encryption", Work in Progress,
Internet-Draft, draft-ietf-hpke-hpke-03, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-hpke-
hpke-03>.
[I-D.ounsworth-cfrg-kem-combiners]
Ounsworth, M., Wussler, A., and S. Kousidis, "Combiner
function for hybrid key encapsulation mechanisms (Hybrid
KEMs)", Work in Progress, Internet-Draft, draft-ounsworth-
cfrg-kem-combiners-05, 31 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ounsworth-
cfrg-kem-combiners-05>.
[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>.
Berra, et al. Expires 16 November 2026 [Page 10]
Internet-Draft HPKE Authenticated Modes May 2026
[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>.
6.2. Informative References
[Alwen2021]
Alwen, J., Blanchet, B., Hauck, E., Kiltz, E., Lipp, B.,
and D. Riepel, "HPKE: Hybrid Public Key Encryption",
Advances in Cryptology -- EUROCRYPT 2021, LNCS 12696, pp.
396-427, DOI 10.1007/978-3-030-77886-6_14, 2021,
<https://doi.org/10.1007/978-3-030-77886-6_14>.
[Alwen2023]
Alwen, J., Janneck, J., Kiltz, E., and B. Lipp, "The Pre-
Shared Key Modes of HPKE", Advances in Cryptology --
ASIACRYPT 2023, 2023, <https://eprint.iacr.org/2023/1480>.
[FIPS203] National Institute of Standards and Technology, "Module-
Lattice-Based Key-Encapsulation Mechanism Standard",
FIPS 203, August 2024,
<https://doi.org/10.6028/NIST.FIPS.203>.
[I-D.draft-connolly-cfrg-xwing-kem-10]
Connolly, D., Schwabe, P., and B. Westerbaan, "X-Wing:
general-purpose hybrid post-quantum KEM", Work in
Progress, Internet-Draft, draft-connolly-cfrg-xwing-kem-
10, 2 March 2026, <https://datatracker.ietf.org/doc/html/
draft-connolly-cfrg-xwing-kem-10>.
[I-D.draft-ietf-tls-hybrid-design-16]
Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key
exchange in TLS 1.3", Work in Progress, Internet-Draft,
draft-ietf-tls-hybrid-design-16, 7 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
hybrid-design-16>.
[I-D.ietf-hpke-pq]
Barnes, R. and D. Connolly, "Post-Quantum and Post-
Quantum/Traditional Hybrid Algorithms for HPKE", Work in
Progress, Internet-Draft, draft-ietf-hpke-pq-04, 2 March
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
hpke-pq-04>.
[PQCodePkgs]
Post Quantum Cryptography Alliance, "PQ Code Package
Repositories (accessed 2026-04-30)", 2026,
<https://github.com/orgs/pq-code-package/repositories>.
Berra, et al. Expires 16 November 2026 [Page 11]
Internet-Draft HPKE Authenticated Modes May 2026
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>.
[RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based
Authentication with an External Pre-Shared Key", RFC 8773,
DOI 10.17487/RFC8773, March 2020,
<https://www.rfc-editor.org/rfc/rfc8773>.
[RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.
[RFC9257] Housley, R., Hoyland, J., Sethi, M., and C. A. Wood,
"Guidance for External Pre-Shared Key (PSK) Usage in TLS",
RFC 9257, DOI 10.17487/RFC9257, July 2022,
<https://www.rfc-editor.org/rfc/rfc9257>.
[RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
Key Exchanges in the Internet Key Exchange Protocol
Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May
2023, <https://www.rfc-editor.org/rfc/rfc9370>.
[RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for
Post-Quantum Traditional Hybrid Schemes", RFC 9794,
DOI 10.17487/RFC9794, June 2025,
<https://www.rfc-editor.org/rfc/rfc9794>.
[Wireguard2020]
Donenfeld, J. A., "WireGuard: Next Generation Kernel
Network Tunnel", 2020,
<https://www.wireguard.com/papers/wireguard.pdf>.
Acknowledgments
_TK_
Authors' Addresses
Giulio Berra (editor)
Freedom of the Press Foundation
Email: giulio@freedom.press
Cory Francis Myers (editor)
Freedom of the Press Foundation
Berra, et al. Expires 16 November 2026 [Page 12]
Internet-Draft HPKE Authenticated Modes May 2026
Email: cfm@acm.org
Rowen Shane (editor)
Freedom of the Press Foundation
Email: ro@freedom.press
Berra, et al. Expires 16 November 2026 [Page 13]