]> Cisco

rlb@ipv.sx

Inria

karthikeyan.bhargavan@inria.fr

Inria

ietf@benjaminlipp.de

Apple

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 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. 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 an encryption key 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 and TLS Encrypted ClientHello . 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 . This document represents the consensus of the Crypto Forum Research Group (CFRG).

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.
• 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 SHOULD have at least Nsk bytes of entropy (see for discussion).
  • 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 symmetric key (the KEM shared secret) and a fixed-length encapsulation of that key 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 ephemeral symmetric key (the KEM shared secret) from its encapsulated representation enc. This function can raise a DecapError on decapsulation failure.
  • AuthEncap(pkR, skS) (optional): Same as Encap(), and the outputs encode an assurance that the KEM shared secret was generated by the holder of the private key skS.
  • AuthDecap(enc, skR, pkS) (optional): Same as Decap(), and the recipient is assured that the KEM shared secret was generated by the holder of the private key skS.
  • Nsecret: The length in bytes of a KEM shared secret produced by this KEM.
  • Nenc: The length in bytes of an encapsulated key 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):
  • 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. Note that GenerateKeyPair can be implemented as DeriveKeyPair(random(Nsk)). 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 two 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.

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 keys 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 and LabeledExpand 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 and LabeledExpand) 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). It is important to note that the AuthEncap() and AuthDecap() functions of the DHKEM variants defined in this document are vulnerable to key-compromise impersonation (KCI). This means the assurance that the KEM shared secret was generated by the holder of the private key skS does not hold if the recipient private key skR is compromised. See for more details. 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 key 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 three authenticated variants: one that authenticates possession of a pre-shared key, one that authenticates possession of a KEM private key, and one that authenticates possession of both a pre-shared key and a KEM private key. All authenticated variants contribute 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
mode_auth	0x02
mode_auth_psk	0x03

All these cases 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. Note that some KEMs may not support AuthEncap() or AuthDecap(). For such KEMs, only mode_base or mode_psk are supported. Future specifications which define new KEMs MUST indicate whether these modes are supported. 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 psk and psk_id fields 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 fields 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. In the Auth and AuthPSK modes, the recipient is assured that the sender held the private key skS. This assurance is limited for the DHKEM variants defined in this document because of key-compromise impersonation, as described in and . If in the PSK and AuthPSK modes, the psk and psk_id arguments are provided as required, then the recipient is assured that the sender held the corresponding pre-shared key. See for more details. 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 and LabeledExpand is defined based on them as follows: (mode, shared_secret, info, psk, psk_id): VerifyPSKInputs(mode, psk, psk_id) psk_id_hash = LabeledExtract("", "psk_id_hash", psk_id) info_hash = LabeledExtract("", "info_hash", info) key_schedule_context = concat(mode, psk_id_hash, info_hash) secret = LabeledExtract(shared_secret, "secret", psk) key = LabeledExpand(secret, "key", key_schedule_context, Nk) base_nonce = LabeledExpand(secret, "base_nonce", key_schedule_context, Nn) exporter_secret = LabeledExpand(secret, "exp", key_schedule_context, Nh) 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. See for a discussion of the key schedule output, including the role-specific Context structure and its API. 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.

Authentication Using an Asymmetric Key This variant extends the base mechanism by allowing the recipient to authenticate that the sender possessed a given KEM private key. This is because AuthDecap(enc, skR, pkS) produces the correct KEM shared secret only if the encapsulated value enc was produced by AuthEncap(pkR, skS), where skS is the private key corresponding to pkS. In other words, at most two entities (precisely two, in the case of DHKEM) could have produced this secret, so if the recipient is at most one, then the sender is the other with overwhelming probability. The primary difference from the base case is that the calls to Encap() and Decap() are replaced with calls to AuthEncap() and AuthDecap(), which add the sender public key to their internal context string. The function parameters pkR and pkS are public keys, and enc is an encapsulated KEM shared secret. Obviously, this variant can only be used with a KEM that provides AuthEncap() and AuthDecap() procedures. This mechanism authenticates only the key pair of the sender, not any other identifier. If an application wishes to bind HPKE ciphertexts or exported secrets to another identity for the sender (e.g., an email address or domain name), then this identifier should be included in the info parameter to avoid identity misbinding issues .

Authentication Using Both a PSK and an Asymmetric Key This mode is a straightforward combination of the PSK and authenticated modes. Like the PSK mode, a PSK is provided as input to the key schedule, and like the authenticated mode, authenticated KEM variants are used. 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 field to overflow, then the implementation MUST fail with an error. (In the pseudocode below, 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), similar to the TLS 1.3 exporter interface (see , Section 7.5). 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 field 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.

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 one of Base, PSK, Auth, or AuthPSK. The optional parameters indicated by "..." depend on MODE and may be empty. For example, SetupBase() has no additional parameters. SealAuthPSK() and OpenAuthPSK() 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 one of Base, PSK, Auth, or AuthPSK. The optional parameters indicated by "..." depend on MODE and may be empty.

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 and is therefore suitable for the Auth and AuthPSK modes. The meaning of all other columns is explained in . All algorithms are suitable for the PSK mode.

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 = LabeledExpand(dkp_prk, "candidate", I2OSP(counter, 1), Nsk) 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:

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; in authenticated modes, the recipient MUST validate the sender's static public key pkS. 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. The AuthEncap() and AuthDecap() functions are OPTIONAL. If a KEM algorithm does not provide them, only the Base and PSK modes of HPKE are supported. Future specifications that define new KEMs MUST indicate whether or not Auth and AuthPSK modes are supported. 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	Reference
0x0000	Reserved	N/A	RFC 9180
0x0001	HKDF-SHA256	32
0x0002	HKDF-SHA384	48
0x0003	HKDF-SHA512	64

Input Length Restrictions 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 fields 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. The RECOMMENDED limit for these values is 64 bytes. This would enable interoperability with implementations that statically allocate memory for these inputs to avoid memory allocations. 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 key 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. As another example, DHKEM's AuthDecap() function will produce invalid output if given the wrong sender public key. This error is not detectable until subsequent AEAD decryption. 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 PSK, Auth, and AuthPSK modes

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 and Auth modes, 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 and AuthPSK modes, 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. In the Auth mode, sender authentication is generally expected to hold if the sender private key skS is not compromised at the time of message reception. In the AuthPSK mode, sender authentication is generally expected to hold if, at the time of message reception, the sender private key skS and the pre-shared key are not both compromised. 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.

Key-Compromise Impersonation The DHKEM variants defined in this document are vulnerable to key-compromise impersonation attacks , which means that sender authentication cannot be expected to hold in the Auth mode if the recipient private key skR is compromised, and in the AuthPSK mode if the pre-shared key and the recipient private key skR are both compromised. NaCl's box interface has the same issue. At the same time, this enables repudiability. As shown by , key-compromise impersonation attacks are generally possible on HPKE because KEM ciphertexts are not bound to HPKE messages. An adversary who knows a recipient's private key can decapsulate an observed KEM ciphertext, compute the key schedule, and encrypt an arbitrary message that the recipient will accept as coming from the original sender. Importantly, this is possible even with a KEM that is resistant to key-compromise impersonation attacks. As a result, mitigating this issue requires fundamental changes that are out of scope of this specification. Applications that require resistance against key-compromise impersonation SHOULD take extra steps to prevent this attack. One possibility is to produce a digital signature over (enc, ct) tuples using a sender's private key -- where ct is an AEAD ciphertext produced by the single-shot or multi-shot API and enc is the corresponding KEM encapsulated key. Given these properties, pre-shared keys strengthen both the authentication and the secrecy properties in certain adversary models. One particular example in which this can be useful is a hybrid quantum setting: if a non-quantum-resistant KEM used with HPKE is broken by a quantum computer, the security properties are preserved through the use of a pre-shared key. As described in Section 7 of this assumes that the pre-shared key has not been compromised.

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. Analysis of the PSK, Auth, and AuthPSK modes defined in this document additionally requires verifying the sender authentication property. While the PSK mode just adds supplementary keying material to the key schedule, the Auth and AuthPSK modes make use of a non-standard authenticated KEM construction. Generally, the authenticated modes of HPKE can be viewed and analyzed as flavors of signcryption . 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
Auth	Y	Y	Y
AuthPSK	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 HPKE's Auth mode single-shot encryption API has been done in . The paper defines security notions for authenticated KEMs and for authenticated public key encryption, using the outsider and insider security terminology known from signcryption . The analysis proves that DHKEM's AuthEncap()/AuthDecap() interface fulfills these notions for all Diffie-Hellman groups specified in this document. The analysis also provides exact security bounds, under the assumptions that the gap Diffie-Hellman (GDH) problem is hard in the appropriate subgroup , and that HKDF can be modeled as a random oracle. Further, proves composition theorems, showing that HPKE's Auth mode fulfills the security notions of authenticated public key encryption for all KDFs and AEAD schemes specified in this document, given any authenticated KEM satisfying the previously defined security notions for authenticated KEMs. The theorems assume that the KEM is perfectly correct; they could easily be adapted to work with KEMs that have a nonzero but negligible probability for decryption failure. The assumptions on the KDF are that Extract() and Expand() can be modeled as pseudorandom functions wherein the first argument is the key, respectively. The assumption for the AEAD is IND-CPA and IND-CTXT security. In summary, the analysis in proves that the single-shot encryption API of HPKE's Auth mode satisfies the desired message confidentiality and sender authentication properties listed at the beginning of this section; it does not consider multiple messages, nor the secret export API.

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. However, the composition theorems from for HPKE's Auth mode only make standard assumptions (i.e., no random oracle assumption) that are expected to hold against quantum adversaries (although with slightly worse bounds). Thus, these composition theorems, in combination with a post-quantum-secure authenticated KEM, guarantee the post-quantum security of HPKE's Auth mode. 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 or AuthPSK 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 .

AuthEncap/AuthDecap Interface The analysis of HPKE's Auth mode single-shot encryption API in provides composition theorems that guarantee that HPKE's Auth mode achieves its desired security properties if the KEM's AuthEncap()/AuthDecap() interface satisfies multi-user Outsider-CCA, Outsider-Auth, and Insider-CCA security, as defined in the same paper. Intuitively, Outsider-CCA security formalizes confidentiality, and Outsider-Auth security formalizes authentication of the KEM shared secret in case none of the sender or recipient private keys are compromised. Insider-CCA security formalizes confidentiality of the KEM shared secret in case the sender private key is known or chosen by the adversary. (If the recipient private key is known or chosen by the adversary, confidentiality is trivially broken, because then the adversary knows all secrets on the recipient's side). An Insider-Auth security notion would formalize authentication of the KEM shared secret in case the recipient private key is known or chosen by the adversary. (If the sender private key is known or chosen by the adversary, it can create KEM ciphertexts in the name of the sender). Because of the generic attack on an analogous Insider-Auth security notion of HPKE described in , a definition of Insider-Auth security for KEMs used within HPKE is not useful.

KEM Key Reuse An ikm input to DeriveKeyPair() () MUST NOT be reused elsewhere, in particular not with DeriveKeyPair() of a different KEM. The randomness used in Encap() and AuthEncap() to generate the KEM shared secret or its encapsulation MUST NOT be reused elsewhere. 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 and AuthPSK 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() and LabeledExpand() (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. Future KEM instantiations MUST ensure, should Extract() and Expand() be used internally, that they can be modeled as functions independent from the invocations of Extract() and Expand() in the remainder of HPKE. One way to ensure this is by using LabeledExtract() and LabeledExpand() 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() and LabeledExpand() 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.

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 authenticated modes 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: In this example, the length of each secret is based on the AEAD algorithm used for the corresponding HPKE context. Note that HPKE's limitations with regard to sender authentication become limits on recipient authentication in this context. In particular, in the Base mode, there is no authentication of the remote party at all. Even in the Auth mode, where the remote party has proven that they hold a specific private key, this authentication is still subject to key-compromise impersonation, as discussed in .

Metadata Protection The authenticated modes of HPKE (PSK, Auth, and AuthPSK) require 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, pkS, enc, ciphertext) before, it would now send (enc2, ciphertext2, enc, ciphertext), where (enc2, ciphertext2) represent the encryption of the psk_id and pkS values. 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 value 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 has created three new registries:

• 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

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 key 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 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 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] Cisco Inria & Mozilla Phoenix R&D Meta Platforms Google University of Oxford 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 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. Springer Berlin Heidelberg The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms if the existing syntax does not accommodate them. This document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key. 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.

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

Auth Setup Information

Encryptions

Exported Values

AuthPSK Setup Information

Encryptions

Exported Values

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

Base Setup Information

Encryptions

Exported Values

PSK Setup Information

Encryptions

Exported Values

Auth Setup Information

Encryptions

Exported Values

AuthPSK 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

Auth Setup Information

Encryptions

Exported Values

AuthPSK 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

Auth Setup Information

Encryptions

Exported Values

AuthPSK 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

Auth Setup Information

Encryptions

Exported Values

AuthPSK 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

Auth Setup Information

Encryptions

Exported Values

AuthPSK Setup Information

Encryptions

Exported Values

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

Base Setup Information

Exported Values

PSK Setup Information

Exported Values

Auth Setup Information

Exported Values

AuthPSK Setup Information

Exported Values