Authenticated Modes for HPKE

Authenticated Pre-Shared Key Mode Extension to This section specifies the additions to 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 .

Mode Identifiers The reserved entry for value 0x03 in Table 1 of is replaced with the following mode identifier, as originally specified in Table 1 of : The value 0x02 remains reserved.

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.

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 . 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; see for integration of a pre-shared key.

VerifyPSKInputs The VerifyPSKInputs() function defined in and is extended to handle the reintroduced mode_auth_psk. The updated function replaces the original: The only change from the original is that mode_psk is replaced by [mode_psk, mode_auth_psk] in the final guard.

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.

DHAKEM with PSK This section illustrates how the authenticated mode 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 . 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 . As in , 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.

PQ/T Hybrid Construction 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 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) . 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 and subsequently, . 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 . A quantum adversary with access to the PSK can also forge authenticated messages. PSK freshness. The PSK psk MUST satisfy the entropy requirement in (32 bytes of uniform randomness).

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 . The result is a KEM combiner-style construction 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 . In addition to the keypair specified in , 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 or an algorithm from .
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.

Classical (implicit) sender authentication: This construction provides only classical sender authentication is provided. In contrast to , this "psk" value provides no sender authentication, as it is constructed rather than pre-shared. This limitation is assessed in . 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 . 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 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.

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 . Developers looking to offer hybrid PQ/T encryption in their own applications, for reasons described for example in , can look to early-stage implementations of , or may refer to the now-expired , 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 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 , indicate that this strategy has real-world uses until quantum-resistant authentication methods become more available. 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 and , which also discuss the introduction of quantum-resistent PSK as a transitional measure.