]>

rlb@ipv.sx

Inria

karthikeyan.bhargavan@inria.fr

Rosenpass

ietf@benjaminlipp.de

caw@heapingbits.net

HPKE Internet-Draft This document specifies a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes a variant that authenticates possession of a pre-shared key. HPKE works for any combination of an asymmetric Key Encapsulation Mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. This document provides instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA-2. This document obsoletes RFC 9180. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction Encryption schemes that combine asymmetric and symmetric algorithms have been specified and practiced since the early days of public key cryptography, e.g., . Combining the two yields the key management advantages of asymmetric cryptography and the performance benefits of symmetric cryptography. The traditional combination has been "encrypt the symmetric key with the public key." "Hybrid" public key encryption (HPKE) schemes, specified here, take a different approach: "generate the symmetric key and its encapsulation with the public key." Specifically, encrypted messages convey a shared secret encapsulated with a public key scheme, along with one or more arbitrary-sized ciphertexts encrypted using that key. This type of public key encryption has many applications in practice, including Messaging Layer Security , TLS Encrypted ClientHello , and Oblivious HTTP . Currently, there are numerous competing and non-interoperable standards and variants for hybrid encryption, mostly variants on the Elliptic Curve Integrated Encryption Scheme (ECIES), including ANSI X9.63 (ECIES) , IEEE 1363a , ISO/IEC 18033-2 , and SECG SEC 1 . See for a thorough comparison. All these existing schemes have problems, e.g., because they rely on outdated primitives, lack proofs of indistinguishability under adaptive chosen-ciphertext attack (IND-CCA2) security, or fail to provide test vectors. This document defines an HPKE scheme that provides a subset of the functions provided by the collection of schemes above but specified with sufficient clarity that they can be interoperably implemented. The HPKE construction defined herein is secure against (adaptive) chosen ciphertext attacks (IND-CCA2-secure) under classical assumptions about the underlying primitives , and post-quantum secure when used with a post-quantum secure KEM . These analyses cover HPKE instantiated with a two-stage KDF. The security of HPKE with a one-stage KDF relies on the KDF meeting the requirements in , and has not yet been analyzed in the same detail. A summary of these analyses is in .

Requirements Notation 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.

Notation The following terms are used throughout this document to describe the operations, roles, and behaviors of HPKE:

• (skX, pkX): A key encapsulation mechanism (KEM) key pair used in role X, where X is one of R or E as recipient and ephemeral, respectively; skX is the private key and pkX is the public key.
• pk(skX): The KEM public key corresponding to the KEM private key skX.
• Sender (S): Role of entity that sends an encrypted message.
• Recipient (R): Role of entity that receives an encrypted message.
• Ephemeral (E): Role of a fresh random value meant for one-time use.
• I2OSP(n, w): Convert non-negative integer n to a w-length, big-endian byte string, as described in .
• OS2IP(x): Convert byte string x to a non-negative integer, as described in , assuming big-endian byte order.
• concat(x0, ..., xN): Concatenation of byte strings. concat(0x01, 0x0203, 0x040506) = 0x010203040506.
• lengthPrefixed(x): The two-byte, big-endian length of the byte string x, concatenated with x itself. (lengthPrefixed(x) = concat(I2OSP(len(x), 2), x)) It is an error to call this function with an x value that is more than 65535 bytes long.
• random(n): A pseudorandom byte string of length n bytes
• xor(a,b): XOR of byte strings; xor(0xF0F0, 0x1234) = 0xE2C4. It is an error to call this function with two arguments of unequal length.

Values that are indicated in double quotes (e.g., "key") represent sequences of bytes, not text strings. The value of bytes is the ASCII encoding of the quoted string. An empty string ("") indicates a zero-length byte sequence. These byte sequences values do not include any zero byte marker at the end, such as can be used in some methods of representing strings. Algorithms in this document are specified using Python-like pseudocode. In this pseudocode, raise indicates that the function fails with the named error, which is propagated to the caller and causes the calling function to fail as well (see ). Names in angle brackets, such as <ROLE> or <MODE>, are template parameters that are replaced with a concrete value, as described where they are used. Within the methods of an encryption context (e.g., Context.Export), self refers to the context on which the method is invoked.

Cryptographic Dependencies HPKE variants rely on the following primitives:

• A Key Encapsulation Mechanism (KEM); see
• A Key Derivation Function (KDF); see
• An Authenticated Encryption with Associated Data (AEAD) algorithm; see

A ciphersuite is a triple (KEM, KDF, AEAD) containing a choice of algorithm for each primitive. A set of algorithm identifiers for concrete instantiations of these primitives is provided in . Algorithm identifier values are two bytes long.

Key Encapsulation Mechanisms Each KEM is parameterized by the following constants (all measured in bytes):

Nsecret:

The length of a KEM shared secret produced by this KEM.

Nenc:

The length of an encapsulated secret produced by this KEM.

Npk:

The length of an encoded public key for this KEM.

Nsk:

The length of an encoded private key for this KEM.

A key encapsulation mechanism (KEM) provides the following functions:

GenerateKeyPair():

Randomized algorithm to generate a key pair (skX, pkX).

DeriveKeyPair(ikm):

Deterministic algorithm to derive a key pair (skX, pkX) from the byte string ikm, where ikm is an arbitrary-length byte string (within the bounds in ). The ikm input SHOULD have at least Nsk bytes of entropy.

SerializePublicKey(pkX):

Produce a byte string of length Npk encoding the public key pkX.

DeserializePublicKey(pkXm):

Parse a byte string of length Npk to recover a public key. This function can raise a DeserializeError error upon pkXm deserialization failure.

Encap(pkR):

Randomized algorithm to generate an ephemeral, fixed-length shared secret and a fixed-length encapsulation of that secret (also known as the KEM ciphertext) that can be decapsulated by the holder of the private key corresponding to pkR. This function can raise an EncapError on encapsulation failure.

Decap(enc, skR):

Deterministic algorithm using the private key skR to recover the shared secret from the encapsulated secret enc. This function can raise a DecapError on decapsulation failure.

The notation pk(skX), depending on its use and the KEM and its implementation, is either the computation of the public key using the private key, or just syntax expressing the retrieval of the public key, assuming it is stored along with the private key object. Beyond the above, a KEM MAY also expose the following functions, whose behavior is detailed in :

SerializePrivateKey(skX):

Produce a byte string of length Nsk encoding the private key skX.

DeserializePrivateKey(skXm):

Parse a byte string of length Nsk to recover a private key. This function can raise a DeserializeError error upon skXm deserialization failure.

Senders and recipients MUST validate KEM inputs and outputs as described in .

Key Derivation Functions A key derivation function (KDF) is either a one-stage KDF, with a single Derive function, or a two-stage KDF, with Extract and Expand functions. A one-stage KDF provides the function:

Derive(ikm, L):

Derive an L-byte value from the input keying material ikm.

A two-stage KDF provides the functions:

Extract(salt, ikm):

Extract a pseudorandom key of fixed length Nh bytes from input keying material ikm and an optional byte string salt.

Expand(prk, info, L):

Expand a pseudorandom key prk using optional string info into L bytes of output keying material.

The Nh parameter indicates security strength of KDF, in bytes. For a two-stage KDF, Nh is the output size of the Extract() function. For a one-stage KDF, Nh is specified as part of the definition of the KDF. Certain functions have a different structure depending on whether a one-stage or two-stage KDF is being used. For clarity, such functions will be described twice in this document, once with the suffix _OneStage and once with the suffix _TwoStage, representing the versions of the function to be used with a one-stage or two-stage KDF, respectively. A reference to or call of the function without a suffix denotes the variant that matches the KDF in use. For example, a call to Foo invokes Foo_OneStage when using a one-stage KDF, and Foo_TwoStage when using a two-stage KDF. This convention applies to the following functions:

• ExtractAndExpand ()
• CombineSecrets ()
• Context.Export ()
• DeriveCandidate and DeriveKeyPair ()

AEAD Encryption Algorithm An AEAD encryption algorithm provides the functions:

Seal(key, nonce, aad, pt):

Encrypt and authenticate plaintext pt with associated data aad using symmetric key key and nonce nonce, yielding ciphertext and tag ct. This function can raise a MessageLimitReachedError upon failure.

Open(key, nonce, aad, ct):

Decrypt ciphertext and tag ct using associated data aad with symmetric key key and nonce nonce, returning plaintext message pt. This function can raise an OpenError or MessageLimitReachedError upon failure.

AEAD functions have the following parameters (all measured in bytes):

Nk:

The length of a key for this algorithm.

Nn:

The length of a nonce for this algorithm.

Nt:

The length of the authentication tag for this algorithm.

Labeled Derivation Functions The following functions are defined to facilitate domain separation of KDF calls as well as context binding: The value of suite_id depends on where the KDF is used; it is assumed implicit from the implementation and not passed as a parameter. If used inside a KEM algorithm, suite_id MUST start with "KEM" and identify this KEM algorithm; if used in the remainder of HPKE, it MUST start with "HPKE" and identify the entire ciphersuite in use. See and for details.

DH-Based KEM (DHKEM) Suppose we are given a KDF, and a Diffie-Hellman (DH) group providing the following operations:

DH(skX, pkY):

Perform a non-interactive Diffie-Hellman exchange using the private key skX and public key pkY to produce a Diffie-Hellman shared secret of length Ndh. This function can raise a ValidationError as described in .

A DH-based KEM is parameterized by the constants (in bytes):

Ndh:

The length of the shared secret produced by DH().

Nsk:

The length of a Diffie-Hellman private key.

Npk:

The length of a serialized public key for the DH group.

Nenc:

Equal to Npk. Encapsulated shared secrets are serialized DH public keys in this KEM algorithm.

Then we can construct a KEM that implements the interface defined in called DHKEM(Group, KDF) in the following way, where Group denotes the Diffie-Hellman group and KDF denotes the KDF. The function parameter pkR is a deserialized public key, and enc is a serialized public key. Since encapsulated shared secrets are Diffie-Hellman public keys in this KEM algorithm, we use SerializePublicKey() and DeserializePublicKey() to encode and decode them, respectively. GenerateKeyPair() produces a key pair for the Diffie-Hellman group in use. contains the DeriveKeyPair() function specification for DHKEMs defined in this document. The implicit suite_id value used within LabeledExtract, LabeledExpand, and LabeledDerive is defined as follows, where kem_id is defined in : The KDF used in DHKEM can be equal to or different from the KDF used in the remainder of HPKE, depending on the chosen variant. Implementations MUST make sure to use the constants (Nh) and function calls (LabeledExtract, LabeledExpand, and LabeledDerive) of the appropriate KDF when implementing DHKEM. See for a comment on the choice of a KDF for the remainder of HPKE, and for the rationale of the labels. For the variants of DHKEM defined in this document, the size Nsecret of the KEM shared secret is equal to the output length of the hash function underlying the KDF. For P-256, P-384, and P-521, the size Ndh of the Diffie-Hellman shared secret is equal to 32, 48, and 66, respectively, corresponding to the x-coordinate of the resulting elliptic curve point . For X25519 and X448, the size Ndh is equal to 32 and 56, respectively (see ).

Hybrid Public Key Encryption In this section, we define a few HPKE variants. All variants take a recipient public key pkR and a sequence of plaintexts pt and produce an encapsulated secret enc and a sequence of ciphertexts ct. These outputs are constructed so that only the holder of skR can decapsulate the key from enc and decrypt the ciphertexts. All the algorithms also take an info parameter that can be used to influence the generation of keys (e.g., to fold in identity information) and an aad parameter that provides additional authenticated data to the AEAD algorithm in use. In addition to the base case of encrypting to a public key, we include a variant that authenticates possession of a pre-shared key. The authenticated variant contributes additional keying material to the encryption operation. The following one-byte values will be used to distinguish between modes: HPKE Modes

Mode	Value
mode_base	0x00
mode_psk	0x01
RESERVED	0x02
RESERVED	0x03

The values 0x02 and 0x03 are reserved for the mode_auth and mode_auth_psk modes defined in , which are not specified in this document, and are not to be used with any other meaning. This document does not deprecate those modes: existing deployments can continue to use them as specified in , and future specifications may specify them in terms of the interfaces defined in this document. Both variants follow the same basic two-step pattern:

1. Set up an encryption context that is shared between the sender and the recipient.
2. Use that context to encrypt or decrypt content.

A context is an implementation-specific structure that encodes the AEAD algorithm and key in use, and manages the nonces used so that the same nonce is not used with multiple plaintexts. It also has an interface for exporting secret values, as described in . See for a description of this structure and its interfaces. HPKE decryption fails when the underlying AEAD decryption fails. The constructions described here presume that the relevant non-private parameters (enc, psk_id, etc.) are transported between the sender and the recipient by some application making use of HPKE. Moreover, a recipient with more than one public key needs some way of determining which of its public keys was used for the encapsulation operation. As an example, applications may send this information alongside a ciphertext from the sender to the recipient. Specification of such a mechanism is left to the application. See for more details. The procedures described in this section are laid out in a Python-like pseudocode. The algorithms in use are left implicit.

Creating the Encryption Context The variants of HPKE defined in this document share a common key schedule that translates the protocol inputs into an encryption context. The key schedule inputs are as follows:

• mode - A one-byte value indicating the HPKE mode, defined in .
• shared_secret - A KEM shared secret generated for this transaction.
• info - Application-supplied information (optional; default value "").
• psk - A pre-shared key (PSK) held by both the sender and the recipient (optional; default value "").
• psk_id - An identifier for the PSK (optional; default value "").

Senders and recipients MUST validate KEM inputs and outputs as described in . The info parameter used by HPKE is not related to the optional string info used by the LabeledExpand() or Expand() functions detailed in . The psk and psk_id parameters MUST appear together or not at all. That is, if a non-default value is provided for one of them, then the other MUST be set to a non-default value. This requirement is encoded in VerifyPSKInputs() below. The psk, psk_id, and info parameters have maximum lengths that depend on the KDF itself, on the definition of LabeledExtract(), and on the constant labels used together with them. See for precise limits on these lengths. The key, base_nonce, and exporter_secret computed by the key schedule have the property that they are only known to the holder of the recipient private key, and the entity that used the KEM to generate shared_secret and enc. The HPKE algorithm identifiers, i.e., the KEM kem_id, KDF kdf_id, and AEAD aead_id 2-byte code points, as defined in , , and , respectively, are assumed implicit from the implementation and not passed as parameters. The implicit suite_id value used within LabeledExtract, LabeledExpand, and LabeledDerive is defined based on them as follows: (mode, shared_secret, info, psk, psk_id): VerifyPSKInputs(mode, psk, psk_id) key, base_nonce, exporter_secret = CombineSecrets(mode, shared_secret, info, psk, psk_id) return Context(key, base_nonce, 0, exporter_secret) ]]> The ROLE template parameter is either S or R, depending on the role of sender or recipient, respectively. The third parameter in the Context<ROLE> refers to the sequence number, which is initialized with a 0 value. See for a discussion of the key schedule output, including the role-specific Context structure and its Application Programming Interface (API), and the usage of the sequence number. Note that when a two-stage KDF is used, the key_schedule_context construction in CombineSecrets_TwoStage() is equivalent to serializing a structure of the following form in the TLS presentation syntax:

Encryption to a Public Key The most basic function of an HPKE scheme is to enable encryption to the holder of a given KEM private key. The SetupBaseS() and SetupBaseR() procedures establish contexts that can be used to encrypt and decrypt, respectively, for a given private key. The KEM shared secret is combined via the KDF with information describing the key exchange, as well as the explicit info parameter provided by the caller. The parameter pkR is a public key, and enc is an encapsulated KEM shared secret.

Authentication Using a Pre-Shared Key This variant extends the base mechanism by allowing the recipient to authenticate that the sender possessed a given PSK. The PSK also improves confidentiality guarantees in certain adversary models, as described in more detail in . We assume that both parties have been provisioned with both the PSK value psk and another byte string psk_id that is used to identify which PSK should be used. The primary difference from the base case is that the psk and psk_id values are used as ikm inputs to the KDF (instead of using the empty string). The PSK MUST have at least 32 bytes of entropy and SHOULD be of length Nh bytes or longer. See for a more detailed discussion.

Encryption and Decryption HPKE allows multiple encryption operations to be done based on a given setup transaction. Since the public key operations involved in setup are typically more expensive than symmetric encryption or decryption, this allows applications to amortize the cost of the public key operations, reducing the overall overhead. In order to avoid nonce reuse, however, this encryption must be stateful. Each of the setup procedures above produces a role-specific context object that stores the AEAD and secret export parameters. The AEAD parameters consist of:

• The AEAD algorithm in use
• A secret key
• A base nonce base_nonce
• A sequence number (initially 0)

The secret export parameters consist of:

• The HPKE ciphersuite in use and
• An exporter_secret used for the secret export interface (see )

All these parameters except the AEAD sequence number are constant. The sequence number provides nonce uniqueness: The nonce used for each encryption or decryption operation is the result of XORing base_nonce with the current sequence number, encoded as a big-endian integer of the same length as base_nonce. Implementations MAY use a sequence number that is shorter than the nonce length (padding on the left with zero), but MUST raise an error if the sequence number overflows. The AEAD algorithm produces ciphertext that is Nt bytes longer than the plaintext. Nt = 16 for AEAD algorithms defined in this document. Additionally, each AEAD algorithm has a maximum plaintext length (P_MAX) as specified in . For AES-128-GCM and AES-256-GCM, P_MAX is 2^36 - 31 bytes. For ChaCha20Poly1305, P_MAX is 2^38 - 64 bytes. Implementations MUST NOT encrypt plaintexts larger than P_MAX. Exceeding either the sequence number limit or P_MAX for the AEAD in use results in loss of confidentiality and integrity guarantees. Encryption is unidirectional from sender to recipient. The sender's context can encrypt a plaintext pt with associated data aad as follows: The recipient's context can decrypt a ciphertext ct with associated data aad as follows: Each encryption or decryption operation increments the sequence number for the context in use. The per-message nonce and sequence number increment details are as follows: .ComputeNonce(seq): seq_bytes = I2OSP(seq, Nn) return xor(self.base_nonce, seq_bytes) def Context.IncrementSeq(): if self.seq >= (1 << (8*Nn)) - 1: raise MessageLimitReachedError self.seq += 1 ]]> The sender's context MUST NOT be used for decryption. Similarly, the recipient's context MUST NOT be used for encryption. Higher-level protocols reusing the HPKE key exchange for more general purposes can derive separate keying material as needed using the secret export interface; see and for more details. It is up to the application to ensure that encryptions and decryptions are done in the proper sequence, so that encryption and decryption nonces align. If ContextS.Seal() or ContextR.Open() would cause the seq parameter to overflow, then the implementation MUST fail with an error. (In the pseudocode above, Context<ROLE>.IncrementSeq() fails with an error when seq overflows, which causes ContextS.Seal() and ContextR.Open() to fail accordingly.) Note that the internal Seal() and Open() calls inside correspond to the context's AEAD algorithm. In parallel or concurrent environments, the ComputeNonce(), Seal(), and IncrementSeq() operations MUST be done as an atomic unit, e.g., by holding a lock on ContextS for the duration of ContextS.Seal(). If other calls to Seal() are interleaved before IncrementSeq() completes, this will result in multiple encryptions with the same sequence number, and thus the same nonce.

Secret Export HPKE provides an interface for exporting secrets from the encryption context using a variable-length pseudorandom function (PRF). This interface takes as input a context string exporter_context and a desired length L in bytes, and produces a secret derived from the internal exporter secret using LabeledExpand() (for a two-stage KDF) or LabeledDerive() (for a one-stage KDF). For the KDFs defined in this specification, L has a maximum value of 255*Nh. Future specifications that define new KDFs MUST specify a bound for L. For one-stage KDFs, LabeledDerive() encodes L in two bytes, so L cannot exceed 65,535 regardless of any bound given by the KDF's own specification. A specification for a one-stage KDF MUST NOT specify a bound for L larger than 65,535. The exporter_context parameter has a maximum length that depends on the KDF itself, on the definition of LabeledExpand() or LabeledDerive(), and on the constant labels used together with them. See for precise limits on this length. Applications that do not use the encryption API in can use the export-only AEAD ID 0xFFFF when computing the key schedule. Such applications can avoid computing the key and base_nonce values in the key schedule, as they are not used by the Export interface described above. Unlike the similar TLS 1.3 exporter interface (see ), the HPKE export interface does not provide replay protection. While the resulting secret will only be known to the sender and recipient, a replayed encapsulated secret enc will produce an identical context, and thus the same exported secrets. In particular, applications MUST NOT use exported secrets unless it is safe for the same exported values to be used multiple times. For example, applications MUST NOT derive a (key, nonce) pair for AEAD encryption from an exported secret unless the derivation also incorporates a value that is fresh for each derivation, such as a recipient-provided nonce (see and ), since reuse of a (key, nonce) pair harms security in most AEAD algorithms. In particular, the example in , which derives an AEAD key and nonce from an exported secret with no fresh input, does not meet this requirement.

Single-Shot APIs

Encryption and Decryption In many cases, applications encrypt only a single message to a recipient's public key. This section provides templates for HPKE APIs that implement stateless "single-shot" encryption and decryption using APIs specified in and : (pkR, info, aad, pt, ...): enc, ctx = SetupS(pkR, info, ...) ct = ctx.Seal(aad, pt) return enc, ct def Open(enc, skR, info, aad, ct, ...): ctx = SetupR(enc, skR, info, ...) return ctx.Open(aad, ct) ]]> The MODE template parameter is either Base or PSK. The optional parameters indicated by "..." depend on MODE and may be empty. For example, SetupBase() has no additional parameters. SealPSK() and OpenPSK() would be implemented as follows:

Secret Export Applications may also want to derive a secret known only to a given recipient. This section provides templates for HPKE APIs that implement stateless "single-shot" secret export using APIs specified in : (pkR, info, exporter_context, L, ...): enc, ctx = SetupS(pkR, info, ...) exported = ctx.Export(exporter_context, L) return enc, exported def ReceiveExport(enc, skR, info, exporter_context, L, ...): ctx = SetupR(enc, skR, info, ...) return ctx.Export(exporter_context, L) ]]> As in , the MODE template parameter is either Base or PSK. The optional parameters indicated by "..." depend on MODE and may be empty. Secrets exported using this single-shot API face the same replay risks discussed in . Usage of exported secrets needs to be limited as described in that section.

Algorithm Identifiers This section lists algorithm identifiers suitable for different HPKE configurations. Future specifications may introduce new KEM, KDF, and AEAD algorithm identifiers and retain the security guarantees presented in this document provided they adhere to the security requirements in , , and , respectively.

Key Encapsulation Mechanisms (KEMs) KEM IDs

Value	KEM	Nsecret	Nenc	Npk	Nsk	Auth	Reference
0x0000	Reserved	N/A	N/A	N/A	N/A	N/A	RFC XXXX
0x0010	DHKEM(P-256, HKDF-SHA256)	32	65	65	32	yes	,
0x0011	DHKEM(P-384, HKDF-SHA384)	48	97	97	48	yes	,
0x0012	DHKEM(P-521, HKDF-SHA512)	64	133	133	66	yes	,
0x0020	DHKEM(X25519, HKDF-SHA256)	32	32	32	32	yes	,
0x0021	DHKEM(X448, HKDF-SHA512)	64	56	56	56	yes	,

The Auth column indicates whether the KEM algorithm provides the AuthEncap()/AuthDecap() interface defined in . This document does not use that interface, since it does not specify the modes that rely on it. The column is retained for compatibility with and with future specifications that reintroduce authenticated modes. The DHKEMs listed above provide that interface as specified in , and so have "yes" in this column.

SerializePublicKey and DeserializePublicKey For P-256, P-384, and P-521, the SerializePublicKey() function of the KEM performs the uncompressed Elliptic-Curve-Point-to-Octet-String conversion according to . DeserializePublicKey() performs the uncompressed Octet-String-to-Elliptic-Curve-Point conversion. For X25519 and X448, the SerializePublicKey() and DeserializePublicKey() functions are the identity function, since these curves already use fixed-length byte strings for public keys. Some deserialized public keys MUST be validated before they can be used. See for specifics.

SerializePrivateKey and DeserializePrivateKey As per , P-256, P-384, and P-521 private keys are field elements in the scalar field of the curve being used. For this section, and for , it is assumed that implementors of ECDH over these curves use an integer representation of private keys that is compatible with the OS2IP() function. For P-256, P-384, and P-521, the SerializePrivateKey() function of the KEM performs the Field-Element-to-Octet-String conversion according to . If the private key is an integer outside the range [0, order-1], where order is the order of the curve being used, the private key MUST be reduced to its representative in [0, order-1] before being serialized. DeserializePrivateKey() performs the Octet-String-to-Field-Element conversion according to . For X25519 and X448, private keys are identical to their byte string representation. To catch invalid keys early on, implementors of DHKEMs SHOULD check that deserialized private keys are not equivalent to 0 (mod order), where order is the order of the DH group. Note that this property is trivially true for X25519 and X448 groups, since clamped values (see ) can never be 0 (mod order).

DeriveKeyPair The keys that DeriveKeyPair() produces have only as much entropy as the provided input keying material. For a given KEM, the ikm parameter given to DeriveKeyPair() SHOULD have length at least Nsk, and SHOULD have at least Nsk bytes of entropy. All invocations of KDF functions (such as LabeledExtract or LabeledExpand) in any DHKEM's DeriveKeyPair() function use the DHKEM's associated KDF (as opposed to the ciphersuite's KDF). For P-256, P-384, and P-521, the DeriveKeyPair() function of the KEM performs rejection sampling over field elements: = order: if counter > 255: raise DeriveKeyPairError bytes = DeriveCandidate(ikm, counter) bytes[0] = bytes[0] & bitmask sk = OS2IP(bytes) counter = counter + 1 return (sk, pk(sk)) ]]> order is the order of the curve being used (see Section 3.2.1 of ), and is listed below for completeness. bitmask is defined to be 0xFF for P-256 and P-384, and 0x01 for P-521. The precise likelihood of DeriveKeyPair() failing with DeriveKeyPairError depends on the group being used, but it is negligibly small in all cases. See for information about dealing with such failures. For X25519 and X448, the DeriveKeyPair() function applies a KDF to the input: The suite_id used implicitly in LabeledExtract(), LabeledExpand(), and LabeledDerive() for DeriveKeyPair(ikm) is derived from the KEM identifier of the DHKEM in use (see ), that is, based on the type of key pair generated for that DHKEM type. For all of the above instances of DHKEM, the GenerateKeyPair can be implemented as DeriveKeyPair(random(Nsk)).

Validation of Inputs and Outputs The following public keys are subject to validation if the group requires public key validation: the sender MUST validate the recipient's public key pkR; the recipient MUST validate the ephemeral public key pkE. Validation failure yields a ValidationError. For P-256, P-384, and P-521, senders and recipients MUST perform partial public key validation on all public key inputs, as defined in Section 5.6.2.3.4 of . This includes checking that the coordinates are in the correct range, that the point is on the curve, and that the point is not the point at infinity. Additionally, senders and recipients MUST ensure the Diffie-Hellman shared secret is not the point at infinity. For X25519 and X448, public keys and Diffie-Hellman outputs MUST be validated as described in . In particular, recipients MUST check whether the Diffie-Hellman shared secret is the all-zero value and abort if so.

Future KEMs lists security requirements on a KEM used within HPKE. A KEM algorithm may support different encoding algorithms, with different output lengths, for KEM public keys. Such KEM algorithms MUST specify only one encoding algorithm whose output length is Npk.

Key Derivation Functions (KDFs) KDF IDs

Value	KDF	Nh	Two-Stage	Reference
0x0000	Reserved	N/A	N/A	RFC XXXX
0x0001	HKDF-SHA256	32	Y
0x0002	HKDF-SHA384	48	Y
0x0003	HKDF-SHA512	64	Y

This document defines no one-stage KDFs; every KDF listed in is a two-stage KDF. An initial set of one-stage KDFs is defined in .

Input Length Restrictions For one-stage KDFs, there is a length limit of 65,535 bytes for the psk, psk_id, info fields. This limitation arises because these fields are all prefixed with a two-byte length when being used as KDF inputs. There is no inherent length limitation on exporter_context. If a one-stage KDF has an input length limit, then implementations MUST limit the length of exporter_context accordingly, so that the LabeledDerive call in Context.Export does not overflow the input length limit. For two-stage KDFs, this document defines LabeledExtract() and LabeledExpand() based on the KDFs listed above. These functions add prefixes to their respective inputs ikm and info before calling the KDF's Extract() and Expand() functions. This leads to a reduction of the maximum input length that is available for the inputs psk, psk_id, info, exporter_context, ikm, i.e., the variable-length parameters provided by HPKE applications. The following table lists the maximum allowed lengths of these parameters for the KDFs defined in this document, as inclusive bounds in bytes: Application Input Limits

Input	HKDF-SHA256	HKDF-SHA384	HKDF-SHA512
psk	2^{61} - 88	2^{125} - 152	2^{125} - 152
psk_id	2^{61} - 93	2^{125} - 157	2^{125} - 157
info	2^{61} - 91	2^{125} - 155	2^{125} - 155
exporter_context	2^{61} - 120	2^{125} - 200	2^{125} - 216
ikm (DeriveKeyPair)	2^{61} - 84	2^{125} - 148	2^{125} - 148

This shows that the limits are only marginally smaller than the maximum input length of the underlying hash function; these limits are large and unlikely to be reached in practical applications. Future specifications that define new KDFs MUST specify bounds for these variable-length parameters. Since the above bounds are larger than any values used in practice, it may be useful for implementations to impose a smaller maximum on the values they will accept (for example, to avoid dynamic allocations). Implementations MUST support info values of at least 64 bytes. Implementations SHOULD support info values of at least 16384 bytes to accommodate protocols such as Encrypted Client Hello . Applications seeking maximum interoperability with resource-constrained HPKE implementations SHOULD NOT provide info values exceeding 64 bytes without confirmation that an implementation supports larger info values. The values for psk, psk_id, info, and ikm, which are inputs to LabeledExtract(), were computed with the following expression: The value for exporter_context, which is an input to LabeledExpand(), was computed with the following expression: In these equations, max_size_hash_input is the maximum input length of the underlying hash function in bytes, Nb is the block size of the underlying hash function in bytes, size_version_label is the size of "HPKE-v1" in bytes and equals 7, size_suite_id is the size of the suite_id in bytes and equals 5 for DHKEM (relevant for ikm) and 10 for the remainder of HPKE (relevant for psk, psk_id, info, and exporter_context), and size_input_label is the size in bytes of the label used as parameter to LabeledExtract() or LabeledExpand(), the maximum of which is 13 across all labels in this document.

Authenticated Encryption with Associated Data (AEAD) Functions AEAD IDs

Value	AEAD	Nk	Nn	Nt	Reference
0x0000	Reserved	N/A	N/A	N/A	RFC XXXX
0x0001	AES-128-GCM	16	12	16
0x0002	AES-256-GCM	32	12	16
0x0003	ChaCha20Poly1305	32	12	16
0xFFFF	Export-only	0	0	N/A	RFC XXXX

The 0xFFFF AEAD ID is reserved for applications that only use the Export interface; see for more details.

API Considerations This section documents considerations for interfaces to implementations of HPKE. This includes error handling considerations and recommendations that improve interoperability when HPKE is used in applications.

Auxiliary Authenticated Application Information HPKE has two places at which applications can specify auxiliary authenticated information: (1) during context construction via the Setup info parameter, and (2) during Context operations, i.e., with the aad parameter for Open() and Seal(), and the exporter_context parameter for Export(). Application information applicable to multiple operations on a single Context should use the Setup info parameter. This avoids redundantly processing this information for each Context operation. In contrast, application information that varies on a per-message basis should be specified via the Context APIs (Seal(), Open(), or Export()). Applications that only use the single-shot APIs described in can specify auxiliary authenticated information using both the Setup info parameter and the Context aad and exporter_context parameters. Such applications SHOULD prefer the info parameter, because info is the parameter intended for information that applies to the whole context, and using it keeps their behavior consistent with applications that also use the underlying multi-shot APIs.

Errors The high-level, public HPKE APIs specified in this document are all fallible. These include the Setup functions and all encryption context functions. For example, Decap() can fail if the encapsulated secret enc is invalid, and Open() may fail if ciphertext decryption fails. The explicit errors generated throughout this specification, along with the conditions that lead to each error, are as follows:

• ValidationError: KEM input or output validation failure; .
• DeserializeError: Public or private key deserialization failure; .
• EncapError: Encap() failure; .
• DecapError: Decap() failure; .
• OpenError: Context AEAD Open() failure; and .
• MessageLimitReachedError: Context AEAD sequence number overflow; and .
• DeriveKeyPairError: Key pair derivation failure; .

Implicit errors may also occur. As an example, certain classes of failures, e.g., malformed recipient public keys, may not yield explicit errors. For example, for the DHKEM variant described in this specification, the Encap() algorithm fails when given an invalid recipient public key. However, other KEM algorithms may not have an efficient algorithm for verifying the validity of public keys. As a result, an equivalent error may not manifest until AEAD decryption at the recipient. The errors in this document are meant as a guide for implementors. They are not an exhaustive list of all the errors an implementation might emit. For example, future KEMs might have internal failure cases, or an implementation might run out of memory. How these errors are expressed in an API or handled by applications is an implementation-specific detail. For example, some implementations may abort or panic upon a DeriveKeyPairError failure given that it only occurs with negligible probability, whereas other implementations may retry the failed DeriveKeyPair operation. See for more information. As another example, some implementations of the DHKEM specified in this document may choose to transform ValidationError from DH() into an EncapError or DecapError from Encap() or Decap(), respectively, whereas others may choose to raise ValidationError unmodified. Applications using HPKE APIs should not assume that the errors here are complete, nor should they assume certain classes of errors will always manifest the same way for all ciphersuites. For example, the DHKEM specified in this document will emit a DeserializeError or ValidationError if a KEM public key is invalid. However, a new KEM might not have an efficient algorithm for determining whether or not a public key is valid. In this case, an invalid public key might instead yield an OpenError when trying to decrypt a ciphertext.

Security Considerations

Security Properties HPKE has several security goals, depending on the mode of operation, against active and adaptive attackers that can compromise partial secrets of senders and recipients. The desired security goals are detailed below:

• Message secrecy: Confidentiality of the sender's messages against chosen ciphertext attacks
• Export key secrecy: Indistinguishability of each export secret from a uniformly random bitstring of equal length, i.e., Context.Export is a variable-length PRF
• Sender authentication: Proof of sender origin for the PSK mode

These security goals are expected to hold for any honest recipient key pair. A pre-shared key provides authentication; additionally, it strengthens the secrecy properties in certain adversary models, including against a quantum-capable adversary, see . HPKE mitigates malleability problems (called benign malleability ) in prior public key encryption standards based on ECIES by including all public keys in the context of the key schedule. HPKE does not provide forward secrecy with respect to recipient compromise. In the Base mode, the secrecy properties are only expected to hold if the recipient private key skR is not compromised at any point in time. In the PSK mode, the secrecy properties are expected to hold if the recipient private key skR and the pre-shared key are not both compromised at any point in time. See for more details. Besides forward secrecy, HPKE has other non-goals that are described in : no tolerance of message reordering or loss, no downgrade or replay prevention, no hiding of the plaintext length, and no protection against bad ephemeral randomness. suggests application-level mitigations for some of them.

Computational Analysis It is shown in that a hybrid public key encryption scheme of essentially the same form as the Base mode described here is IND-CCA2-secure as long as the underlying KEM and AEAD schemes are IND-CCA2-secure. Moreover, it is shown in that IND-CCA2 security of the KEM and the data encapsulation mechanism are necessary conditions to achieve IND-CCA2 security for hybrid public key encryption. The main difference between the scheme proposed in and the Base mode in this document (both named HPKE) is that we interpose some KDF calls between the KEM and the AEAD. Analyzing the HPKE Base mode instantiation in this document therefore requires verifying that the additional KDF calls do not cause the IND-CCA2 property to fail, as well as verifying the additional export key secrecy property. A preliminary computational analysis of all HPKE modes has been done in , indicating asymptotic security for the case where the KEM is DHKEM, the AEAD is any scheme that provides both indistinguishability under chosen-plaintext attack (IND-CPA) and integrity of ciphertexts (INT-CTXT) , and the DH group and KDF satisfy the following conditions:

• DH group: The gap Diffie-Hellman (GDH) problem is hard in the appropriate subgroup .
• Extract() and Expand(): Extract() can be modeled as a random oracle. Expand() can be modeled as a pseudorandom function, wherein the first argument is the key.

In particular, the KDFs and DH groups defined in this document (see and ) satisfy these properties when used as specified. The analysis in demonstrates that under these constraints, HPKE continues to provide IND-CCA2 security, and provides the additional properties noted above. Also, the analysis confirms the expected properties hold under the different key compromise cases mentioned above. The analysis considers a sender that sends one message using the encryption context, and additionally exports two independent secrets using the secret export interface. The analysis in considers only two-stage KDFs. With a one-stage KDF, each key schedule computation that a two-stage KDF performs with Extract() and Expand() is instead performed by a single call to LabeledDerive() over the encoded inputs (see ), and the DHKEM and export computations are likewise single LabeledDerive() calls. The analysis is expected to carry over to a one-stage KDF whose Derive() function can be modeled as a random oracle, since such a function provides the properties that the conditions above require of Extract() and Expand(). However, this has not been formally verified; see the discussion of future work below. The table below summarizes the main results from . N/A means that a property does not apply for the given mode, whereas Y means the given mode satisfies the property. Summary of Analysis Results

Mode	Message Sec.	Export Sec.	Sender Auth.
Base	Y	Y	N/A
PSK	Y	Y	Y

If non-DH-based KEMs are to be used with HPKE, further analysis will be necessary to prove their security. The results from provide some indication that any IND-CCA2-secure KEM will suffice here, but are not conclusive given the differences in the schemes. A detailed computational analysis of the PSK mode has been done in . In future work, the analyses from and can be extended to cover a detailed computational analysis of HPKE's base mode, the usage of a one-stage KDF, the multi-shot and secret export interfaces, as well as the examples for bidirectional encryption () and metadata protection ().

Post-Quantum Security The computational analyses in and provide composition theorems based on PRF assumptions, proving post-quantum security for HPKE when used with a post-quantum secure KEM. The analyses in and are premised on classical security models and assumptions, and do not consider adversaries capable of quantum computation. The PSK mode can provide a hybrid quantum-resistance property: if the PSK is not known to a quantum-capable adversary, then that adversary cannot recover the plaintext even if it can break the (classical) KEM. This property is proven in . The analysis in is not sufficient, because it requires the random oracle model and would need adaption to, for example, the quantum random oracle model.

Security Requirements on a KEM Used within HPKE A KEM used within HPKE MUST allow HPKE to satisfy its desired security properties described in . For the security proofs from and to apply, the KEM MUST be CCA-secure. lists requirements concerning domain separation. In particular, the KEM shared secret MUST be a uniformly random byte string of length Nsecret. This means, for instance, that it would not be sufficient if the KEM shared secret is only uniformly random as an element of some structured set (such as an elliptic curve group or a finite field) prior to its encoding as a byte string, because such an encoding is generally not uniformly distributed over byte strings of length Nsecret.

KEM Key Reuse An ikm input to DeriveKeyPair() () MUST NOT be reused elsewhere, in particular not with DeriveKeyPair() of a different KEM. Since a KEM key pair belonging to a recipient works with all modes, it can be used with multiple modes in parallel. HPKE is constructed to be secure in such settings due to domain separation using the suite_id variable. However, there is no formal proof of security at the time of writing for using multiple modes in parallel; , , and only analyze isolated modes.

Security Requirements on a KDF The choice of the KDF for HPKE SHOULD be made based on the security level provided by the KEM and, if applicable, by the PSK. The KDF SHOULD at least have the security level of the KEM and SHOULD at least have the security level provided by the PSK. For the security proofs from and to apply, the KDF MUST allow proving PRF security for the key schedule both with shared_secret or psk as PRF key. For a one-stage KDF, the corresponding requirements apply to Derive(ikm, L) as invoked by LabeledDerive(). The output of the key schedule MUST be pseudorandom whenever either shared_secret or psk is unknown to the adversary, even if the adversary knows or chooses the other inputs. Similarly, the output of Context.Export() MUST be pseudorandom when exporter_secret is unknown to the adversary, and the DHKEM shared secret MUST be pseudorandom when the Diffie-Hellman output is unknown to the adversary. A KDF whose Derive() function can be modeled as a random oracle, such as an extendable-output function (XOF) like SHAKE, satisfies these requirements. The proofs in and have not been extended to one-stage KDFs (see ).

Security Requirements on an AEAD All AEADs MUST provide confidentiality (IND-CPA) and ciphertext integrity (INT-CTXT). In practice, all widely deployed IND-CCA2 symmetric authenticated encryption schemes meet these definitions. As discussed in , IND-CPA and INT-CTXT together imply IND-CCA2. We list them separately because they are the AEAD security properties relied upon by the analyses summarized in .

Pre-Shared Key Recommendations In PSK mode, the PSK MUST have at least 32 bytes of entropy and SHOULD be of length Nh bytes or longer. Using a PSK longer than 32 bytes but shorter than Nh bytes is permitted. The KDFs used with HPKE are not designed to slow down dictionary attacks; this is true of HKDF (see ) as well as of one-stage KDFs. Thus, HPKE's PSK mechanism is not suitable for use with a low-entropy password as the PSK: In scenarios in which the adversary knows the KEM shared secret shared_secret and has access to an oracle that distinguishes between a good and a wrong PSK, it can perform PSK-recovering attacks. This oracle can be the decryption operation on a captured HPKE ciphertext or any other recipient behavior that is observably different when using a wrong PSK. The adversary knows the KEM shared secret shared_secret if it knows all KEM private keys of one participant. In the PSK mode, this is trivially the case if the adversary acts as the sender. To recover a lower entropy PSK, an attacker in this scenario can trivially perform a dictionary attack. Given a set S of possible PSK values, the attacker generates an HPKE ciphertext for each value in S, and submits the resulting ciphertexts to the oracle to learn which PSK is being used by the recipient. Further, because HPKE uses AEAD schemes that are not key-committing, an attacker can mount a partitioning oracle attack that can recover the PSK from a set of S possible PSK values, with |S| = m*k, in roughly m + log k queries to the oracle using ciphertexts of length proportional to k, the maximum message length in blocks. (Applying the multi-collision algorithm from requires a small adaptation to the algorithm wherein the appropriate nonce is computed for each candidate key. This modification adds one call to HKDF per key. The number of partitioning oracle queries remains unchanged.) As a result, the PSK must therefore be chosen with sufficient entropy so that m + log k is prohibitive for attackers (e.g., 2^128). Future specifications can define new AEAD algorithms that are key-committing. Pre-processing a low-entropy password with a memory-hard password-based key derivation function such as scrypt or Argon2 before using it as a PSK raises the per-guess cost of the attacks described above, but it does not add entropy and therefore does not by itself make a low-entropy password safe to use as a PSK. Applications that need to derive keys from passwords, and that must tolerate low-entropy passwords, should use a mechanism designed for that purpose (for example, a password-authenticated key exchange) rather than relying on HPKE's PSK mode.

Domain Separation HPKE allows combining a DHKEM variant DHKEM(Group, KDF') and a KDF such that both KDFs are instantiated by the same KDF. By design, the calls to Extract() and Expand() inside DHKEM and the remainder of HPKE use separate input domains. This justifies modeling them as independent functions even if instantiated by the same KDF. This domain separation between DHKEM and the remainder of HPKE is achieved by using prefix-free sets of suite_id values in LabeledExtract(), LabeledExpand(), and LabeledDerive() (KEM... in DHKEM and HPKE... in the remainder of HPKE). Recall that a set is prefix-free if no element is a prefix of another within the set. Separation between uses of the one-stage and two-stage KDFs is ensured by the inclusion of the suite_id in LabeledExtract(), LabeledExpand(), and LabeledDerive(). Future KEM instantiations MUST ensure, should Extract(), Expand(), and/or Derive() be used internally, that they can be modeled as functions independent of the invocations of these functions in the remainder of HPKE. One way to ensure this is by using LabeledExtract() / LabeledExpand() / LabeledDerive() functions with a suite_id as defined in , which will ensure input domain separation, as outlined above. Particular attention needs to be paid if the KEM directly invokes functions that are used internally in HPKE's Extract(), Expand(), or Derive(), such as Hash() and HMAC() in the case of HKDF. It MUST be ensured that inputs to these invocations cannot collide with inputs to the internal invocations of these functions inside Extract(), Expand(), or Derive(). With a two-stage KDF, HPKE's KeySchedule() avoids this by using Extract() instead of Hash() on the arbitrary-length inputs info and psk_id. With a one-stage KDF, KeySchedule() passes these inputs, length-prefixed, only to LabeledDerive(), so they are processed only by the KDF's Derive() function together with the HPKE-specific label and suite_id. The string literal "HPKE-v1" used in LabeledExtract() / LabeledExpand() / LabeledDerive() ensures that any secrets derived in HPKE are bound to the scheme's name and version, even when possibly derived from the same Diffie-Hellman or KEM shared secret as in another scheme or version.

Application Embedding and Non-Goals HPKE is designed to be a low-level mechanism. As a result, it assumes that certain properties are provided by the application in which HPKE is embedded and leaves certain security properties to be provided by other mechanisms. Otherwise said, certain properties are out-of-scope for HPKE.

Message Order and Message Loss The primary requirement that HPKE imposes on applications is the requirement that ciphertexts MUST be presented to ContextR.Open() in the same order in which they were generated by ContextS.Seal(). When the single-shot API is used (see ), this is trivially true (since there is only ever one ciphertext). Applications that allow for multiple invocations of Open() / Seal() on the same context MUST enforce the ordering property described above. Ordering requirements of this character are usually fulfilled by providing a sequence number in the framing of encrypted messages. Whatever information is used to determine the ordering of HPKE-encrypted messages SHOULD be included in the AAD passed to ContextS.Seal() and ContextR.Open(). The specifics of this scheme are up to the application. HPKE is not tolerant of lost messages. Applications MUST be able to detect when a message has been lost. When an unrecoverable loss is detected, the application MUST discard any associated HPKE context.

Downgrade Prevention HPKE assumes that the sender and recipient agree on what algorithms to use. Depending on how these algorithms are negotiated, it may be possible for an intermediary to force the two parties to use suboptimal algorithms.

Replay Protection The requirement that ciphertexts be presented to the ContextR.Open() function in the same order they were generated by ContextS.Seal() provides a degree of replay protection within a stream of ciphertexts resulting from a given context. HPKE provides no other replay protection. While a sender can guarantee the uniqueness of HPKE ciphertexts, a recipient might receive the same ciphertext multiple times. Unless the recipient takes particular care to guarantee that replay is impossible, such as tracking all enc values that are received, this can result in multiple contexts that have the same shared secret. This is particularly relevant for exported secrets. If an attacker can cause a recipient to re-use an enc value, any exported secrets will be the same as in the initial transaction. While the exported values are still known only to the sender and recipient (not the replay attacker), such replay can allow the attacker to cause the recipient to re-use the exported values. Consider the following scenario, in which B is using the recipient-to-sender encryption described as an example in , which derives an AEAD key and nonce deterministically from an exported secret, with no fresh per-response input:

Attacker-triggered nonce reuse via replay A: pk A: enc1, ctx = SetupBaseS(pk, info) ct1 = ctx.seal(aad, pt) A->B: enc1, ct1 B: ctx = SetupBaseR(enc1, sk, info) key, nonce = ctx.export(...) ct2 = AEAD.seal(key, nonce, aad2, pt2) B->A: ct2 X->B: enc1, ct1 [replay of previously sent values] B: ctx = SetupBaseR(enc1, sk, info) key, nonce = ctx.export(...) ct3 = AEAD.seal(key, nonce, aad3, pt3) B->X: ct3 ]]>

In this scenario, if aad2 is different from aad3 or pt2 is different from pt3 (for example, due to the use of a timestamp in either field), then the ciphertexts ct2 and ct3 will represent encryptions of different values with the same (key, nonce) pair -- a nonce reuse condition that can completely break the authenticated encryption guarantees for several AEAD algorithms, including those defined in . In order to avoid such risks, applications SHOULD incorporate a fresh recipient-provided nonce when deriving values from an export context, as discussed in and .

Forward Secrecy HPKE ciphertexts are not forward secret with respect to recipient compromise in any mode. This means that compromise of long-term recipient secrets allows an attacker to decrypt past ciphertexts encrypted under said secrets. This is because only long-term secrets are used on the side of the recipient. HPKE ciphertexts are forward secret with respect to sender compromise in all modes. This is because ephemeral randomness is used on the sender's side, which is supposed to be erased directly after computation of the KEM shared secret and ciphertext.

Bad Ephemeral Randomness If the randomness used for KEM encapsulation is bad -- i.e., of low entropy or compromised because of a broken or subverted random number generator -- the confidentiality guarantees of HPKE degrade significantly. In Base mode, confidentiality guarantees can be lost completely; in PSK mode, at least forward secrecy with respect to sender compromise can be lost completely. Such a situation could also lead to the reuse of the same KEM shared secret and thus to the reuse of same key-nonce pairs for the AEAD. The AEADs specified in this document are not secure in case of nonce reuse. One way for applications to mitigate the impacts of bad ephemeral randomness is to combine ephemeral randomness with a local long-term secret that has been generated securely, as described in .

Hiding Plaintext Length AEAD ciphertexts produced by HPKE do not hide the plaintext length. Applications requiring this level of privacy should use a suitable padding mechanism. See and for examples of protocol-specific padding policies.

Bidirectional Encryption As discussed in , HPKE encryption is unidirectional from sender to recipient. Applications that require bidirectional encryption can derive necessary keying material with the secret export interface (). The type and length of such keying material depends on the application use case. As an example, if an application needs AEAD encryption from the recipient to the sender, it can derive a key and nonce from the corresponding HPKE context as follows: In the one-stage variant, secret, enc, and response_nonce each have a fixed length for a given ciphersuite, so their concatenation is unambiguous. This example mechanism differs from the example mechanism in by incorporating a per-transaction random value response_nonce. Because HPKE does not provide replay protection, the mechanism in enabled an attacker to trigger reuse of a (key, nonce) pair by replaying an HPKE message under certain application circumstances. Incorporating per-transaction entropy ensures that the key and nonce used in AEAD encryption will be distinct for every invocation of the mechanism. In this context, HPKE's limitations with regard to sender authentication become limits on recipient authentication. In particular, in the Base mode, there is no authentication of the remote party at all.

Metadata Protection The PSK mode of HPKE requires that the recipient know what key material to use for the sender. This can be signaled in applications by sending the PSK ID (psk_id above). However, this value itself might be considered sensitive, since, in a given application context, it might identify the sender. An application that wishes to protect these metadata values without requiring further provisioning of keys can use an additional instance of HPKE, using the unauthenticated Base mode. Where the application might have sent (psk_id, enc, ciphertext) before, it would now send (enc2, ciphertext2, enc, ciphertext), where (enc2, ciphertext2) represent the encryption of the psk_id value. The cost of this approach is an additional KEM operation each for the sender and the recipient. A potential lower-cost approach (involving only symmetric operations) would be available if the nonce-protection schemes in could be extended to cover other metadata. However, this construction would require further analysis.

Message Encoding This document does not specify a wire format encoding for HPKE messages. Applications that adopt HPKE must therefore specify an unambiguous encoding mechanism that includes, minimally: the encapsulated secret enc, ciphertext value(s) (and order if there are multiple), and any info values that are not implicit. One example of a non-implicit value is the recipient public key used for encapsulation, which may be needed if a recipient has more than one public key. The AEAD interface used in this document is based on , which produces and consumes a single ciphertext value. As discussed in , this ciphertext value contains the encrypted plaintext as well as any authentication data, encoded in a manner described by the individual AEAD scheme. Some implementations are not structured in this way, instead providing a separate ciphertext and authentication tag. When such AEAD implementations are used in HPKE implementations, the HPKE implementation must combine these inputs into a single ciphertext value within Seal() and parse them out within Open(), where the parsing details are defined by the AEAD scheme. For example, with the AES-GCM schemes specified in this document, the GCM authentication tag is placed in the last Nt bytes of the ciphertext output.

IANA Considerations IANA created three registries as requested in :

• HPKE KEM Identifiers
• HPKE KDF Identifiers
• HPKE AEAD Identifiers

All these registries are in the "Hybrid Public Key Encryption (HPKE)" registry group, and administered under a Specification Required policy . This document replaces RFC 9180 as the specification for these registries and provides instructions to the designated experts for these registries. IANA is requested to make the following changes, which apply only to the three registries listed above:

• For each of the three registries, replace with this document as the reference for the registry itself.
• For each registry entry, the Reference field identifies the document that defines the entry. The entries whose Reference is are the reserved entries with value 0x0000 in all three registries and the Export-only entry 0xFFFF in the "HPKE AEAD Identifiers" registry. These entries are now defined by this document, so their Reference is updated to this document. Entries that reference other specifications are unchanged.
• Make the additional per-registry changes described in , , and .

Registrations made under RFC 9180 remain otherwise unchanged; implementations that rely on those codepoints do not need to change. RFC Editor: Please replace all instances of "RFC XXXX" in this document with the RFC number assigned to this document, and remove this note.

Designated Expert Instructions The following instructions apply to all three HPKE registries. The DE should verify the following things with regard to a request for allocation:

• The requested entry is not duplicative with any existing registration.
• The specification defines the algorithm with enough precision that two independent, interoperable implementations can be produced from it.
• For a KEM registration, the algorithm meets the security requirements in , including that the KEM is CCA-secure, the KEM shared secret is a uniformly random byte string of length Nsecret (), and that the algorithm provides appropriate domain separation ().
• For a KDF registration, the specification meets the requirements in and specifies the input-length bounds required by .
• For an AEAD registration, the algorithm meets the requirements in .
• The values in the registration (lengths, references, and so on) are internally consistent and match the cited specification.

KEM Identifiers The "HPKE KEM Identifiers" registry lists identifiers for key encapsulation algorithms defined for use with HPKE. These identifiers are two-byte values, so the maximum possible value is 0xFFFF = 65535. Template:

• Value: The two-byte identifier for the algorithm
• KEM: The name of the algorithm
• Nsecret: The length in bytes of a KEM shared secret produced by the algorithm
• Nenc: The length in bytes of an encoded encapsulated secret produced by the algorithm
• Npk: The length in bytes of an encoded public key for the algorithm
• Nsk: The length in bytes of an encoded private key for the algorithm
• Auth: A boolean indicating if this algorithm provides the AuthEncap()/AuthDecap() interface defined in . This field is retained for compatibility with RFC 9180 and with future specifications that reintroduce authenticated modes; it is not used by this document. For new registrations, the value is yes only if the specification for the KEM defines AuthEncap() and AuthDecap() for that KEM, and no otherwise.
• Reference: Where this algorithm is defined

This document adds no entries to this registry. lists the entries defined by . Their values are unchanged, except that for the reserved entry 0x0000, the Auth value is changed from "yes" to "N/A" and the Reference is updated to this document. IANA is also requested to add the following note to the registry:

• The Auth column indicates whether the KEM provides the AuthEncap()/AuthDecap() interface defined in RFC 9180. This interface is not used by RFC XXXX. New registrations use "yes" only if the specification for the KEM defines AuthEncap() and AuthDecap() for that KEM, and "no" otherwise.

KDF Identifiers The "HPKE KDF Identifiers" registry lists identifiers for key derivation functions defined for use with HPKE. These identifiers are two-byte values, so the maximum possible value is 0xFFFF = 65535. Template:

• Value: The two-byte identifier for the algorithm
• KDF: The name of the algorithm
• Nh: For two-stage KDFs, the output size of the Extract function in bytes. For one-stage KDFs, the security strength in bytes, as defined for the KDF identifier.
• Two-Stage: Whether the KDF provides Extract and Expand functions (Y) or only a single-stage Derive function (N). N/A for reserved entries.
• Reference: Where this algorithm is defined

This document adds no entries to this registry. It adds a Two-Stage column to the registry. lists the entries defined by , with the Two-Stage value assigned to each of them. Their other values are unchanged, except that the Reference of the reserved entry 0x0000 is updated to this document. The following existing entries, registered by , are one-stage KDFs and are assigned the Two-Stage value N:

• 0x0010 (SHAKE128)
• 0x0011 (SHAKE256)
• 0x0012 (TurboSHAKE128)
• 0x0013 (TurboSHAKE256)

AEAD Identifiers The "HPKE AEAD Identifiers" registry lists identifiers for authenticated encryption with associated data (AEAD) algorithms defined for use with HPKE. These identifiers are two-byte values, so the maximum possible value is 0xFFFF = 65535. Template:

• Value: The two-byte identifier for the algorithm
• AEAD: The name of the algorithm
• Nk: The length in bytes of a key for this algorithm
• Nn: The length in bytes of a nonce for this algorithm
• Nt: The length in bytes of an authentication tag for this algorithm
• Reference: Where this algorithm is defined

This document adds no entries to this registry. lists the entries defined by . Their values are unchanged, except for the following:

• For the Export-only entry 0xFFFF, the Nk and Nn values are changed from "N/A" to 0. This makes the length Nk + Nn + Nh of the key schedule output well defined when a one-stage KDF is used ().
• The Reference of the reserved entry 0x0000 and of the Export-only entry 0xFFFF is updated to this document.

References Normative References National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm. RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References American National Standards Institute Institute of Electrical and Electronics Engineers International Organization for Standardization / International Electrotechnical Commission University of California San Diego University of California San Diego Inria Paris Wickr Inria Paris Ruhr-Universität Bochum Ruhr-Universität Bochum Inria Paris Ruhr-Universität Bochum Applied Physics Institute, CSIC, Madrid, Spain Applied Physics Institute, CSIC, Madrid, Spain Applied Physics Institute, CSIC, Madrid, Spain Polytechnic University, Madrid, Spain University of California, San Diego University of California, San Diego IBM Research Cornell Tech Cornell Tech Cornell Tech AWS-Wickr Ruhr-Universität Bochum Ruhr-Universität Bochum Max Planck Institute for Security and Privacy This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. [STANDARDS-TRACK] Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. This document describes a mechanism in Transport Layer Security (TLS) for encrypting a message under a server public key. This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Cisco Selkie Cryptography 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 attacks by a quantum computer. This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema. This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer-oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable "cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. RFC 7830 specifies the "Padding" option for Extension Mechanisms for DNS (EDNS(0)) but does not specify the actual padding length for specific applications. This memo lists the possible options ("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option.

Differences from RFC 9180 This specification is intended to be backwards-compatible with RFC 9180, in the sense that any behavior specified in both this document and RFC 9180 should specify identical behavior for any functionality that they both specify. Within that constraint, the following list summarizes the major changes from RFC 9180:

• Incorporated fixes for all valid errata on RFC 9180.
• Updated the IANA Considerations section to refer to existing registries.
• Added a framework for single-stage KDFs.
• Removed the Auth and AuthPSK modes.
• Extended the discussion of replay to cover considerations related to exported secrets.
• Added a requirement that applications not derive AEAD (key, nonce) pairs from exported secrets without fresh per-derivation input (), and updated the bidirectional encryption example () to incorporate a fresh recipient-provided nonce. Applications built on the example in do not meet this requirement.
• Changed the guidance on info lengths (). RFC 9180 RECOMMENDED a limit of 64 bytes for all application-provided inputs; this document requires implementations to support info values of at least 64 bytes and recommends support for at least 16384 bytes. Implementations that followed the RFC 9180 recommendation may not meet the new recommendation.

Acknowledgements The authors would like to thank Joël Alwen, Jean-Philippe Aumasson, David Benjamin, Benjamin Beurdouche, Bruno Blanchet, Brian Campbell, Deirdre Connolly, Deb Cooley, Frank Denis, Stephen Farrell, Scott Fluhrer, Eduard Hauck, Scott Hollenbeck, Kevin Jacobs, Jonas Janneck, Michael B. Jones, Burt Kaliski, Eike Kiltz, Samuel Lee, Julia Len, Ilari Liusvaara, Rohan Mahy, John Mattsson, Cory Francis Myers, Christopher Patton, Tommy Pauly, Eric Rescorla, Doreen Riepel, Raphael Robert, Michael Rosenberg, Yaroslav Rosomakho, Rich Salz, Martin Schanzenbach, David Schinazi, Michael Scott, Filip Skokan, Nick Sullivan, Martin Thomson, Steven Valdez, Filippo Valsorda, Riad Wahby, Weijun Wang, Bas Westerbaan, and other contributors in the CFRG and HPKE WG for helpful feedback that greatly improved this document.

Test Vectors Each section below contains test vectors for a single HPKE ciphersuite and contains the following values:

1. Configuration information and private key material: This includes the mode, info string, HPKE ciphersuite identifiers (kem_id, kdf_id, aead_id), and the recipient's key material. Recipient key pairs are generated as (skR, pkR) = DeriveKeyPair(ikmR). Key pairs are written in their serialized form (as produced by SerializePublicKey and SerializePrivateKey). For the PSK mode, the shared PSK and PSK identifier are also included.
2. Context creation intermediate values and outputs: This includes the randomness ikmE used for deterministic encapsulation, KEM outputs enc and shared_secret used to create the context, along with intermediate values key_schedule_context and secret computed in the KeySchedule function in . The outputs include the context values key, base_nonce, and exporter_secret. For DHKEM test vectors, the ephemeral key pair (skEm, pkEm) is also provided.
3. Encryption test vectors: A fixed plaintext message is encrypted using different sequence numbers and AAD values using the context computed in (2). Each test vector lists the sequence number and corresponding nonce computed with base_nonce, the plaintext message pt, AAD aad, and output ciphertext ct.
4. Export test vectors: Several exported values of the same length with differing context parameters are computed using the context computed in (2). Each test vector lists the exporter_context, output length L, and resulting export value.

These test vectors are also available in JSON format at .

Deterministic Encapsulation The test vectors can support testing of encapsulation as well as decapsulation if the KEM being tested provides a derandomized encapsulation function:

EncapDerand(pkR, randomness)

Deterministic algorithm to generate an ephemeral, fixed-length shared secret and a fixed-length encapsulation of that secret (also known as the KEM ciphertext) that can be decapsulated by the holder of the private key corresponding to pkR. This function can raise an EncapError on encapsulation failure.

For DHKEM, this function simply replaces GenerateKeyPair() with DeriveKeyPair() in the generation of the ephemeral key pair: The input ikmE in the context creation inputs is the randomness input to EncapDerand().

DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-128-GCM

Base Setup Information

Encryptions

Exported Values

PSK Setup Information

Encryptions

Exported Values

DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, ChaCha20Poly1305

Base Setup Information

Encryptions

Exported Values

PSK Setup Information

Encryptions

Exported Values

DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, AES-128-GCM

Base Setup Information

Encryptions

Exported Values

PSK Setup Information

Encryptions

Exported Values

DHKEM(P-256, HKDF-SHA256), HKDF-SHA512, AES-128-GCM

Base Setup Information

Encryptions

Exported Values

PSK Setup Information

Encryptions

Exported Values

DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, ChaCha20Poly1305

Base Setup Information

Encryptions

Exported Values

PSK Setup Information

Encryptions

Exported Values

DHKEM(P-521, HKDF-SHA512), HKDF-SHA512, AES-256-GCM

Base Setup Information

Encryptions

Exported Values

PSK Setup Information

Encryptions

Exported Values

DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, Export-Only AEAD

Base Setup Information

Exported Values

PSK Setup Information

Exported Values

Edge-Case Test Vectors This appendix contains test vectors that exercise behavior defined by HPKE itself -- DeriveKeyPair rejection sampling, the labeled key schedule, and the handling of empty and zero-byte inputs -- rather than the underlying KEM, KDF, and AEAD primitives. Except for the rejection-sampling vector in the first section, all vectors use the suite DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-128-GCM, because the behavior exercised is independent of the choice of KEM, KDF, and AEAD.

KEM Key Derivation with Rejection Sampling In this vector the recipient ikm is chosen so that the candidate private key derived with counter = 0 (rejected_candidate below) is greater than or equal to the order of the P-256 group and is therefore rejected; the key pair is produced from the candidate at counter = 1. This exercises the rejection sampling loop in DeriveKeyPair.

Base Setup Information

Encryptions

Exported Values

Empty and Zero-Byte AEAD Inputs This vector uses a normal context and exercises empty and zero-byte values for the per-message aad and pt inputs and the exporter_context input.

Base Setup Information

Encryptions

Exported Values

Empty info This vector uses an empty info value in the key schedule.

Base Setup Information

Encryptions

Exported Values

info with Embedded Zero Bytes This vector uses an info value that contains embedded zero bytes in the key schedule.

Base Setup Information

Encryptions

Exported Values

psk and psk_id with Embedded Zero Bytes This vector uses PSK mode with a psk and psk_id that contain embedded zero bytes.

PSK Setup Information

Encryptions

Exported Values