Cisco

rlb@ipv.sx

Inria

karthikeyan.bhargavan@inria.fr

Inria

ietf@benjaminlipp.de

Cloudflare

caw@heapingbits.net

Internet-Draft This document describes a scheme for hybrid public-key encryption (HPKE). This scheme provides authenticated public key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. We provide instantiations of the scheme using widely-used and efficient primitives, such as Elliptic Curve Diffie-Hellman key agreement, HKDF, and SHA2.

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 schemes (HPKE), 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, for example:

• PGP
• Messaging Layer Security
• TLS Encrypted ClientHello
• Protection of 5G subscriber identities

Currently, there are numerous competing and non-interoperable standards and variants for hybrid encryption, mostly based on ECIES, including ANSI X9.63 (ECIES) , IEEE 1363a , ISO/IEC 18033-2 , and SECG SEC 1 . See for a thorough comparison. All of these existing schemes have problems, e.g., because they rely on outdated primitives, lack proofs of 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 this analysis 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 BCP14 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 KEM key pair used in role X; skX is the private key and pkX is the public key.
• pk(skX): The public key corresponding to private key skX.
• Sender (S): Role of entity which sends an encrypted message.
• Recipient (R): Role of entity which receives an encrypted message.
• Ephemeral (E): Role of a fresh random value meant for one-time use.
• I2OSP and OS2IP: Convert a byte string to and from a non-negative integer as described in . Note that these functions operate on byte strings in 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(): Generate a key pair (skX, pkX)
  • DeriveKeyPair(ikm): Derive a key pair (skX, pkX) from the byte string ikm, where ikm SHOULD have at least Nsk bytes of entropy (see for discussion)
  • Serialize(pk): Produce a byte string of length Npk encoding the public key pk
  • Deserialize(enc): Parse the byte string enc of length Npk to recover a public key (note: this function can raise an error upon enc deserialization failure)
  • Encap(pk): 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 pk
  • Decap(enc, sk): Use the private key sk to recover the ephemeral symmetric key (the KEM shared secret) from its encapsulated representation enc
  • AuthEncap(pkR, skS) (optional): Same as Encap(), and the outputs encode an assurance that the KEM shared secret key was generated by the holder of the private key skS
  • AuthDecap(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 (note: this function can raise a NonceOverflowError 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 (note: this function can raise an OpenError or NonceOverflowError upon failure)
  • Nk: The length in bytes of a key for this algorithm
  • Nn: The length in bytes of a nonce for this algorithm

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 following two functions are defined to facilitate domain separation of KDF calls as well as context binding: [[RFC editor: please change "HPKE-05" to "RFCXXXX", where XXXX is the final number, before publication.]] The value of suite_id depends on where the KDF is used; it is assumed implicit from the implementation and not passed as 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 Suppose we are given a KDF, and a Diffie-Hellman group providing the following operations:

• GenerateKeyPair(): Generate an ephemeral key pair (skX, pkX) for the DH group in use
• DH(sk, pk): Perform a non-interactive DH exchange using the private key sk and public key pk to produce a Diffie-Hellman shared secret of length Ndh
• Serialize(pk): Produce a byte string of length Npk encoding the public key pk
• Deserialize(enc): Parse a byte string of length Npk to recover a public key (note: this function can raise an error upon enc deserialization failure)
• 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 called DHKEM(Group, KDF) in the following way, where Group denotes the Diffie-Hellman group and KDF the KDF. The function parameters pkR and pkS are deserialized public keys, and enc is a serialized public key. 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, 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 Ndh of the Diffie-Hellman shared secret is equal to Npk, and the size Nsecret of the KEM shared secret is equal to the output length of the hash function underlying the KDF. 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 key 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 the private key corresponding to pkR can decapsulate the key from enc and decrypt the ciphertexts. All of 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 which authenticates possession of a pre-shared key, one which authenticates possession of a KEM private key, and one which 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:

Mode	Value
mode_base	0x00
mode_psk	0x01
mode_auth	0x02
mode_auth_psk	0x03

All of 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 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 sender to receiver. 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 or not these modes are supported. The procedures described in this session 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, 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 , 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: See for a description of the Context() output. 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 a serialized public key.

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 SHOULD be of length Nh bytes or longer, and SHOULD have Nh bytes of entropy or more. 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 assurance is based on the assumption that 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 a serialized public key. 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 identity. If an application wishes to authenticate some other identity for the sender (e.g., an email address or domain name), then this identity should be included in the info parameter to avoid identity mis-binding issues .

Authentication using both a PSK and an Asymmetric Key This mode is a straightforward combination of the PSK and authenticated modes. The PSK is passed through to the key schedule as in the former, and as in the latter, we use the authenticated KEM variants. The PSK SHOULD be of length Nh bytes or longer, and SHOULD have Nh bytes of entropy or more. 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 context object that stores the AEAD and Secret Export parameters. The AEAD parameters consist of:

• The AEAD algorithm in use
• The key to be used with the AEAD algorithm
• A base nonce value
• A sequence number (initially 0)

The Secret Export parameters consist of:

• The ciphersuite in use
• The exporter secret used for the Secret Export interface; see

All of these parameters except the AEAD sequence number are constant. The sequence number is used to provide nonce uniqueness: The nonce used for each encryption or decryption operation is the result of XORing the base nonce with the current sequence number, encoded as a big-endian integer of the same length as the nonce. Implementations MAY use a sequence number that is shorter than the nonce (padding on the left with zero), but MUST raise an error if the sequence number overflows. Encryption is unidirectional from sender to recipient. Each encryption or decryption operation increments the sequence number for the context in use. The sender's context MUST NOT be used for decryption. Similarly, the recipient's context MUST NOT be used for encryption. Higher-level protocols re-using the HPKE key exchange for more general purposes can derive separate keying material as needed using use the Export interface; see 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 Context.Seal() or Context.Open() would cause the seq field to overflow, then the implementation MUST fail with an error. (In the pseudocode below, Context.IncrementSeq() fails with an error when seq overflows, which causes Context.Seal() and Context.Open() to fail accordingly.) Note that the internal Seal() and Open() calls inside correspond to the context's AEAD algorithm. = (1 << (8*Nn)) - 1: raise NonceOverflowError self.seq += 1 def Context.Seal(aad, pt): ct = Seal(self.key, self.ComputeNonce(self.seq), aad, pt) self.IncrementSeq() return ct def Context.Open(aad, ct): pt = Open(self.key, self.ComputeNonce(self.seq), aad, ct) if pt == OpenError: raise OpenError self.IncrementSeq() return pt ]]>

Secret Export HPKE provides a interface for exporting secrets from the encryption Context, similar to the TLS 1.3 exporter interface (See , Section 7.5). This interface takes as input a context string exporter_context and 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 which 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.

Single-Shot APIs 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. SetupBase(), for example, has no additional parameters. SealAuthPSK() and OpenAuthPSK() would be implemented as follows:

Algorithm Identifiers

Key Encapsulation Mechanisms (KEMs)

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

Serialize/Deserialize For P-256, P-384 and P-521, the Serialize() function of the KEM performs the uncompressed Elliptic-Curve-Point-to-Octet-String conversion according to . Deserialize() performs the uncompressed Octet-String-to-Elliptic-Curve-Point conversion. For X25519 and X448, the Serialize() and Deserialize() 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.

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 Expand) 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)) ]]> where order is the order of the curve being used (this can be found in section D.1.2 of ), and 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. 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. 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.

Key Derivation Functions (KDFs)

Value	KDF	Nh	Reference
0x0000	(reserved)	N/A	N/A
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, 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:

Input	HKDF-SHA256	HKDF-SHA384	HKDF-SHA512
psk	2^{61} - 91	2^{125} - 155	2^{125} - 155
psk_id	2^{61} - 93	2^{125} - 157	2^{125} - 157
info	2^{61} - 92	2^{125} - 156	2^{125} - 156
exporter_context	2^{61} - 121	2^{125} - 201	2^{125} - 217

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 which define new KDFs MUST specify bounds for these variable-length parameters. The values for psk, psk_id, and info 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_label_rfcXXXX is the size of "HPKE-05 " in bytes and equals 8, size_suite_id is the size of the suite_id and equals 9, and size_input_label is the size of the label used as parameter to LabeledExtract() or LabeledExpand(). [[RFC editor: please change "HPKE-05" to "RFCXXXX", where XXXX is the final number, before publication.]]

Authenticated Encryption with Associated Data (AEAD) Functions

Value	AEAD	Nk	Nn	Reference
0x0000	(reserved)	N/A	N/A	N/A
0x0001	AES-128-GCM	16	12
0x0002	AES-256-GCM	32	12
0x0003	ChaCha20Poly1305	32	12

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: Privacy of the sender's messages, i.e., IND-CCA2 security
• Export key secrecy: Indistinguishability of each export secret from a uniformly random bitstring of equal length
• 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. As noted in , HPKE does not provide forward secrecy. 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 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. 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. However, it is important to note that 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. 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 the Auth and AuthPSK enc output using a sender's private key, as a proof of possession. 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. This assumes that the pre-shared key has not been compromised, as described in . It is shown in that a hybrid public-key encryption scheme of essentially the same form described here is IND-CCA2-secure as long as the underlying KEM and AEAD schemes are IND-CCA2-secure. The main difference between the scheme proposed there and the scheme in this document (both named HPKE) is that we interpose some KDF calls between the KEM and the AEAD. Analyzing the HPKE instantiation in this document therefore required verifying that the additional KDF calls do not cause the IND-CCA2 property to fail, as well as verifying the two additional properties noted above (export key secrecy and sender authentication). This work has been done for the case where the KEM is DHKEM, the AEAD is any IND-CCA2-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() (in DHKEM): Extract() is indifferentiable from a random oracle. Expand() is a pseudorandom function, wherein the first argument is the key.
• Extract() and Expand() (elsewhere): Extract() is indifferentiable from a random oracle. Expand() is 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 X means the given mode satisfies the property.

Variant	Message Sec.	Export Sec.	Sender Auth.
Base	X	X	N/A
PSK	X	X	X
Auth	X	X	X
AuthPSK	X	X	X

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. In addition, both 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. The hybrid quantum-resistance property described above, which is achieved by using the PSK or AuthPSK mode, is proven in ; in a quantum setting, the remaining security level is smaller and defined by the post-quantum security level of the AEAD scheme.

Security Requirements on a KEM used within HPKE A KEM used within HPKE MUST ensure the following to avoid identity mis-binding issues: The KEM shared secret computed by Encap() and Decap() MUST depend explicitly on the KEM public key pkR and the encapsulated key enc, as observed in . The KEM shared secret returned by AuthEncap() and AuthDecap() MUST explicitly depend on the KEM public keys pkR and pkS and the encapsulated key enc. This is usually implemented by including these values explicitly into the context of the key derivation function used to compute the KEM shared secret. This is also how DHKEM meets the requirement.

Security Requirements on a KDF The choice of the KDF for the remainder of HPKE SHOULD be made based on the security level provided by the KEM and, if applicable, by the PSK. The KDF SHOULD have at least have the security level of the KEM and SHOULD at least have the security level provided by the PSK. HPKE's KeySchedule() uses LabeledExtract() to convert an arbitrary-length PSK into a fixed-length PSK. This is necessary because of the restrictions on the key in HMAC's indifferentiability theorem . A future instantiation of HPKE MAY omit this line and use the PSK directly as salt for the computation of secret, if: Extract() is not instantiated by HKDF-Extract() and there is an indifferentiability theorem for Extract() without restriction on the key's length.

Pre-Shared Key Recommendations In the PSK and AuthPSK modes, the PSK SHOULD be of length Nh bytes or longer, and SHOULD have Nh bytes of entropy or more. Using a PSK shorter than Nh bytes is permitted. A PSK that is longer than Nh bytes or that has more than Nh bytes of entropy, respectively, does not increase the security level of HPKE, because the extraction step involving the PSK only outputs Nh bytes. HPKE is specified to use HKDF as 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 allows to distinguish between a good and a wrong PSK, it can perform a dictionary attack on the PSK. This oracle can be the decryption operation on a captured HPKE ciphertext or any other recipient behavior which 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 sender.

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 have different prefix-free encodings for the second parameter. This is achieved by the different prefix-free label parameters in the calls to LabeledExtract() and LabeledExpand(). This serves to separate the input domains of all Extract() and Expand() invocations. It also justifies modeling them as independent functions even if instantiated by the same KDF. Future KEM instantiations MUST ensure that all internal invocations of Extract() and Expand() 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 an equal or similar prefixing scheme with an identifier different from "HPKE-05 ". 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, psk_id, and psk. The string literal "HPKE-05 " used in LabeledExtract() and LabeledExpand() ensures that any secrets derived in HPKE are bound to the scheme's name, even when possibly derived from the same Diffie-Hellman or KEM shared secret as in another scheme.

External Requirements / Non-Goals HPKE is designed to be a fairly low-level primitive, and thus does not provide several features that a more high-level protocol might provide, for example:

• 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 Context.Open() function in the same order they were generated by Context.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-secure. In Base and Auth modes, a given ciphertext can be decrypted if the recipient's public encryption key is compromised. In PSK and AuthPSK modes, a given ciphertext can be decrypted if the recipient's public encryption key and the PSK are compromised.

Metadata Protection The authenticated modes of HPKE (PSK, Auth, 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.

Designated-Verifier Signature The Auth and AuthPSK modes can be used to construct a lightweight "designated-verifier signature" scheme , in the sense that the message is authenticated as coming from the sender, but the only party who can verify the authentication is the recipient (the holder of skR). To create such a signature, the sender simply performs a normal HPKE setup in the proper mode, and calls the Seal method on the resulting context with an empty plaintext value and the content to be signed as AAD. This produces an encoded key enc and a ciphertext value that contains only the AAD tag. For example, using DHKEM(X25519, HKDF-SHA256) and AES-128-GCM, this would produce a 48-byte signature comprising a 32-byte ephemeral X25519 key and a 16-byte GCM tag. To verify such a signature, the recipient performs the corresponding HPKE setup and calls Open() with the provided ciphertext. If the AEAD authentication passes, then the signature is valid. This scheme reuses the authentication scheme underlying the AEAD algorithm in use, while using the KEM to establish a one-time authentication key from a pair of KEM public keys.

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 which 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 receiver public key used for encapsulation, which may be needed if a receiver has more than one public key.

IANA Considerations This document requests the creation of three new IANA registries:

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

All of these registries should be under a heading of "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 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 encapsulated key produced by the algorithm
• Npk: The length in bytes of an encoded public key for the algorithm
• 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 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 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
• Reference: Where this algorithm is defined

Initial contents: Provided in

Acknowledgements The authors would like to thank David Benjamin, Benjamin Beurdouche, Frank Denis, Kevin Jacobs, Raphael Robert, Michael Rosenberg, Michael Scott, Steven Valdez, Riad Wahby, and other contributors in the CFRG for helpful feedback that greatly improved this document.

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 Inria Paris 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 University of California, San Diego NEC Corporation University of California, San Diego Department of Computer Science, New York University Department of Computer Sciences, University of Wisconsin–Madison Institute of Theoretical Computer Science, Tsinghua University CSAIL, Massachusetts Institute of Technology This RFC specifies features for private electronic mail based on encryption technology. [STANDARDS-TRACK] This document defines an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology. The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension and these Elliptic Curves. [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 and post-compromise security for groups in size ranging from two to thousands. This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. 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 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 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.

Test Vectors These test vectors are also available in JSON format at . Note that the plaintext is the same for each test vector. Only the nonce and AAD values differ. In these vectors, GenerateKeyPair() is implemented as DeriveKeyPair(random(Nsk)).

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

Base Setup Information

Encryptions

PSK Setup Information

Encryptions

Auth Setup Information

Encryptions

AuthPSK Setup Information

Encryptions

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

Base Setup Information

Encryptions

PSK Setup Information

Encryptions

Auth Setup Information

Encryptions

AuthPSK Setup Information

Encryptions

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

Base Setup Information

Encryptions

PSK Setup Information

Encryptions

Auth Setup Information

Encryptions

AuthPSK Setup Information

Encryptions

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

Base Setup Information

Encryptions

PSK Setup Information

Encryptions

Auth Setup Information

Encryptions

AuthPSK Setup Information

Encryptions

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

Base Setup Information

Encryptions

PSK Setup Information

Encryptions

Auth Setup Information

Encryptions

AuthPSK Setup Information

Encryptions