]> Cisco

rlb@ipv.sx

Inria

karthikeyan.bhargavan@inria.fr

Inria

ietf@benjaminlipp.de

caw@heapingbits.net

HPKE Internet-Draft 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 a variant that authenticates possession of a pre-shared key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. 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. 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 indistinguishable (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 . 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 S, R, or E as sender, 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 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.

Cryptographic Dependencies HPKE variants rely on the following primitives:

• A key encapsulation mechanism (KEM):
  • 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.
  • Nsecret: The length in bytes of a KEM shared secret produced by this KEM.
  • Nenc: The length in bytes of an encapsulated secret produced by this KEM.
  • Npk: The length in bytes of an encoded public key for this KEM.
  • Nsk: The length in bytes of an encoded private key for this KEM.
• A key derivation function (KDF) of one of the two following forms:
  • A one-stage KDF:
    • Derive(ikm, L): Derive an L-byte value from the input keying material ikm.
    • Nh The security strength of the KDF, in bytes.
  • A two-stage KDF:
    • 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.
    • Nh: The output size of the Extract() function in bytes.
• An AEAD encryption algorithm :
  • 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.
  • 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 the authentication tag for this algorithm.

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.

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. 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. 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 sections and for details. 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. For example, the Foo function would be invoked by calling Foo_OneStage when using a one-stage KDF, and by calling Foo_TwoStage when using a two-stage KDF.

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 .
• Ndh: The length in bytes of a Diffie-Hellman shared secret produced by DH().
• Nsk: The length in bytes of a Diffie-Hellman private key.

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 parameters pkR and pkS are deserialized public keys, 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. Npk equals Nenc. 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 , Section 5). Senders and recipients MUST validate KEM inputs and outputs as described in .

Hybrid Public Key Encryption In this section, we define a few HPKE variants. All variants take a recipient public key 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 were used in to reflect additional variants which have been removed from this specification.) 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, that is initialised with a 0 value. See for a discussion of the key schedule output, including the role-specific Context structure and its API, and the usage of the sequence number. Note that the key_schedule_context construction in KeySchedule() 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. 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 use 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.

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 the corresponding KDF Expand function. 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. The exporter_context parameter has a maximum length that depends on the KDF itself, on the definition of LabeledExpand(), 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 use an exported secret to derive a (key, nonce) pair for AEAD encryption (as suggested in ), since reuse of a (key, nonce) pair harms security in most AEAD algorithms. In such cases, applications SHOULD incorporate a fresh recipient-provided nonce when deriving values from an export context, as discussed in and .

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	yes	RFC 9180
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 if the KEM algorithm provides the AuthEncap()/AuthDecap() interface defined in .

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, so little processing has to be done. The SerializePrivateKey() function MUST clamp its output and the DeserializePrivateKey() function MUST clamp its input, where clamping refers to the bitwise operations performed on k in the decodeScalar25519() and decodeScalar448() functions defined in Section 5 of . 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 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 D.1.2 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() and LabeledExpand() for DeriveKeyPair(ikm) is derived from the KEM identifier of the DHKEM in use (see ), that is, based on the type of key pair been 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 9180
0x0001	HKDF-SHA256	32	Y
0x0002	HKDF-SHA384	48	Y
0x0003	HKDF-SHA512	64	Y

Input Length Restrictions For one-stage KDFs, there is 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 lower limit on the values they will accept (for example, to avoid dynamic allocations). Implementations SHOULD set such a limit to be no less than maximum Nsk size for a KEM supported by the implementation. For an implementation that supports all of the KEMs in this document, the limit would be 66 bytes, which is the Nsk value for DHKEM(P-521, HKDF-SHA512). 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 9180
0x0001	AES-128-GCM	16	12	16
0x0002	AES-256-GCM	32	12	16
0x0003	ChaCha20Poly1305	32	12	16
0xFFFF	Export-only	N/A	N/A	N/A	RFC 9180

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 should use the Setup info parameter for specifying auxiliary authenticated information. Implementations which only expose single-shot APIs should not allow applications to use both Setup info and Context aad or exporter_context auxiliary information parameters.

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 DeserializationError 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 sender and honest recipient keys, as well as if the honest sender and honest recipient keys are the same. 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 and key-compromise impersonation, which are highlighted in this section because of their particular cryptographic importance, 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 IND-CPA-secure and INT-CTXT-secure scheme, 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 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.

Variant	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.

Post-Quantum Security All of , , and are premised on classical security models and assumptions, and do not consider adversaries capable of quantum computation. A full proof of post-quantum security would need to take appropriate security models and assumptions into account, in addition to simply using a post-quantum KEM. In future work, the analysis from can be extended to cover HPKE's other modes and desired security properties. The hybrid quantum-resistance property described above, which is achieved by using the PSK mode, is not proven in because this analysis requires the random oracle model; in a quantum setting, this model needs 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 . 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 set prior to its encoding as a byte string.

Encap/Decap Interface As mentioned in , provides some indications that if the KEM's Encap()/Decap() interface (which is used in the Base and PSK modes) is IND-CCA2-secure, HPKE is able to satisfy its desired security properties. An appropriate definition of IND-CCA2 security for KEMs can be found in and .

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 sender or 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.

Security Requirements on an AEAD All AEADs MUST be IND-CCA2-secure, as is currently true for all AEADs listed in .

Pre-Shared Key Recommendations In the PSK modes, 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. HPKE is specified to use HKDF as its key derivation function. HKDF is not designed to slow down dictionary attacks (see ). 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.

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 from 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() or Expand(), 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() or Expand(). In HPKE's KeySchedule() this is avoided by using Extract() instead of Hash() on the arbitrary-length inputs info and psk_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 fairly 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 :

Attacker-triggered nonce reuse via replay A: pk A: enc1, ctx = SetupBaseS(pk) ct1 = ctx.seal(aad, pt) A->B: enc1, ct1 B: ctx = SetupBaseR(sk, enc1) 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(sk, enc) 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 the other modes, 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. This attack vector is particularly relevant in the authenticated mode because knowledge of the ephemeral randomness is not enough to derive shared_secret in these modes. 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: 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) and/or the sender's public key (pkS). However, these values themselves might be considered sensitive, since, in a given application context, they 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 new registries as requested in :

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

All these registries are under "Hybrid Public Key Encryption", and administered under a Specification Required policy . This document requests that entries in these registries referring to RFC 9180 be updated to refer to this document.

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
• Reference: Where this algorithm is defined

Initial contents: Provided in

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: The output size of the Extract function in bytes
• Reference: Where this algorithm is defined

Initial contents: Provided in

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

Initial contents: Provided in

References Normative References 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. 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] 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 CWI Amsterdam CWI Amsterdam Springer Berlin Heidelberg 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 Springer Science and Business Media LLC Cornell Tech Cornell Tech Cornell Tech National Institute of Standards and Technology National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology 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. Independent Fastly Cryptography Consulting LLC Cloudflare This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). 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 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 updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. 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. 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. 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 refer to existing registries.
• Added a framework for single-stage KDFs.
• Removed the Auth and AuthPSK modes.
• Extended the discussion of replay to conver considerations related to exported secrets.

Acknowledgements The authors would like to thank Joël Alwen, Jean-Philippe Aumasson, David Benjamin, Benjamin Beurdouche, Bruno Blanchet, Frank Denis, Stephen Farrell, Scott Fluhrer, Eduard Hauck, Scott Hollenbeck, Kevin Jacobs, Burt Kaliski, Eike Kiltz, Julia Len, John Mattsson, Christopher Patton, Doreen Riepel, Raphael Robert, Michael Rosenberg, Michael Scott, Martin Thomson, Steven Valdez, Riad Wahby, and other contributors in the CFRG 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 all sender, recipient, and ephemeral key material. For each role X, where X is one of S, R, or E, as sender, recipient, and ephemeral, respectively, key pairs are generated as (skX, pkX) = DeriveKeyPair(ikmX). Each key pair (skX, pkX) is written in its serialized form, where skXm = SerializePrivateKey(skX) and pkXm = SerializePublicKey(pkX). For applicable modes, the shared PSK and PSK identifier are also included.
2. Context creation intermediate values and outputs: This includes the 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.
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 .

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