Authenticated Modes for HPKE

Introduction is the standards-track successor to the informational and omits the authenticated modes mode_auth and mode_auth_psk to simplify the standard. However, some protocols require an authenticated key-encapsulation mechanism (AKEM)---a KEM whose shared secret is implicitly bound to the sender's static private key---without requiring a full authenticated encryption context. The DHKEM construction in already contains all the primitives needed: 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. The normative portion of this document is small. It restores mode_auth and mode_auth_psk as a strict extension to , requiring only AuthEncap()/AuthDecap() on the DHKEM, four setup functions, and a modified VerifyPSKInputs(). The externally observable behavior of existing HPKE modes is unchanged. and describe, informatively, how the restored modes can be used, including a construction that layers a post-quantum KEM shared secret as the PSK to achieve hybrid PQ/T confidentiality as defined in . That material is provided to motivate the extension and may be developed as separate work.

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 when, and only when, they appear in all capitals, as shown here. Terms from are used without redefinition. 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.

Authenticated Mode Extensions to This section specifies the additions to required to restore mode_auth and 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 .

Mode Identifiers The reserved entries for values 0x02 and 0x03 in Table 1 of are replaced with the following mode identifiers, as originally specified in Table 1 of :

DHKEM Extension: AuthEncap() and AuthDecap() The following two functions are added to the DHKEM, extending it to an AKEM. They are reproduced verbatim from . All helper functions (GenerateKeyPair, DH, SerializePublicKey, DeserializePublicKey, ExtractAndExpand) are as defined in . 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 for further discussion.

VerifyPSKInputs The VerifyPSKInputs() function defined in and is extended to handle the two new modes. The updated function replaces the original: The only change from the original is that mode_base is replaced by [mode_base, mode_auth] and mode_psk is replaced by [mode_psk, mode_auth_psk] in the final two guards.

Setup Functions The following four setup functions are reproduced verbatim from Sections and of . KeyScheduleS()/KeyScheduleR() and AuthEncap()/AuthDecap() are as defined in and respectively.

Input Validation and Error Handling In addition to the validation requirements in , 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.

Example Applications (Informative) This section is informative. It illustrates how the authenticated modes defined in can be used. Any AEAD identifier from may be used; the resulting context supports Seal(), Open(), and Export(). Key generation follows GenerateKeyPair() from . The modes may be used directly via their setup functions. For mode_auth, the sender calls SetupAuthS(pkR, info, skS) and the receiver calls SetupAuthR(enc, skR, info, pkS). For mode_auth_psk, the sender calls SetupAuthPSKS() and the receiver calls SetupAuthPSKR(), with a shared PSK and PSK identifier, as defined in .

Hybrid PQ/T Profile (mode_auth_psk with PQ-KEM PSK) The following terms are used in this section:

PQ-KEM: a post-quantum KEM, e.g., ML-KEM or an algorithm from .
PQKEM.Encap(pkR_pq): PQ-KEM encapsulation; returns (ss_pq, enc_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.

The sender encapsulates a PQ-KEM to the receiver's PQ public key pkR_pq, using the resulting shared secret ss_pq as the HPKE PSK and the PQ ciphertext enc_pq as the PSK identifier. The receiver's PQ public key pkR_pq is included in info to bind it to the key schedule. The combined encapsulation is concat(enc_dh, enc_pq); Nenc bytes are parsed as enc_dh and the remaining Nenc_pq bytes as enc_pq. 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 classical ciphersuite (KEM_ID, KDF_ID, AEAD_ID); the PQ-KEM algorithm identity should be conveyed via application-layer framing or the info parameter when multiple PQ-KEM algorithms are supported. Hybrid confidentiality. KeyScheduleS()/KeyScheduleR() delegate to CombineSecrets, for which 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 = ss_pq) . 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 ss_pq 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. 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 remains entirely classical; a quantum adversary that breaks the DH assumption can also forge sender authentication, so post-quantum sender authentication would require an additional PQ signature. Note that describes a related hybrid construction in which a PQ AKEM (rather than a plain 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. PSK freshness. The ML-KEM shared secret ss_pq satisfies the entropy requirement in (32 bytes of uniform randomness). The prohibition on enc_pq reuse above ensures a fresh PSK per session.

HPKE-Auth Profiles (Informative) This section is informative. The profiles below are suggested KEM and KDF parameter sets for the example applications in ; they are not registered by this document. Because AEAD_ID is selected by the application, these are parameter sets, not fully determined ciphersuites. KEM_ID and KDF_ID are drawn from the registries in .

Profile	KEM_ID	KDF_ID	PQKEM	Nenc	Nenc_pq
`HPKE-Auth-X25519-SHA256`	`0x0020`	`0x0001`	---	32	---
`HPKE-Auth-P256-SHA256`	`0x0010`	`0x0001`	---	65	---
`HPKE-Auth-X448-SHA512`	`0x0021`	`0x0003`	---	56	---
`HPKE-Auth-Hybrid-X25519-SHA256-MLKEM768`	`0x0020`	`0x0001`	ML-KEM-768	32	1088
`HPKE-Auth-Hybrid-X25519-SHA256-MLKEM1024`	`0x0020`	`0x0001`	ML-KEM-1024	32	1568
`HPKE-Auth-Hybrid-P256-SHA256-MLKEM768`	`0x0010`	`0x0001`	ML-KEM-768	65	1088

ML-KEM parameters are from . HPKE-Auth-Hybrid-X25519-SHA256-MLKEM768 is the suggested default hybrid profile, yielding a combined encapsulation of 1120 bytes.

Security Considerations The sender-authentication and key-compromise impersonation (KCI) properties of mode_auth and mode_auth_psk are as described in Sections and of , which apply without change to the functions defined in . Security properties specific to the hybrid PQ/T construction are discussed informatively in . The formal security of the DHKEM authenticated modes under the Gap-DH assumption is established in . The security of mode_auth_psk---termed AuthPSK in ---is analyzed there as the pskAPKE scheme.

IANA Considerations This document requests no IANA actions; all identifiers are drawn from registries defined in .