Cisco

rlb@ipv.sx

Inria

karthikeyan.bhargavan@inria.fr

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.

“Hybrid” public-key encryption schemes (HPKE) that combine asymmetric and symmetric algorithms are a substantially more efficient solution than traditional public key encryption techniques such as those based on RSA or ElGamal. Encrypted messages convey a single ciphertext and authentication tag alongside a short public key, which may be further compressed. The key size and computational complexity of elliptic curve cryptographic primitives for authenticated encryption therefore make it compelling for a variety of use cases. This type of public key encryption has many applications in practice, for example: PGP Messaging Layer Security Encrypted Server Name Indication Protection of 5G subscriber identities Currently, there are numerous competing and non-interoperable standards and variants for hybrid encryption, including ANSI X9.63 , IEEE 1363a , ISO/IEC 18033-2 , and SECG SEC 1 . 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 and formally verified.

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.

As a hybrid authentication encryption algorithm, we desire security against (adaptive) chosen ciphertext attacks (IND-CCA2 secure). The HPKE variants described in this document achieve this property under the Random Oracle model assuming the gap Computational Diffie Hellman (CDH) problem is hard . [[ TODO - Provide citations to these proofs once they exist ]]

The following terms are used throughout this document to describe the operations, roles, and behaviors of HPKE: Initiator (I): Sender of an encrypted message. Responder (R): Receiver of an encrypted message. Ephemeral (E): A fresh random value meant for one-time use. (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 len(x): The length of the octet string x, expressed as a two-octet unsigned integer in network (big-endian) byte order encode_big_endian(x, n): An octet string encoding the integer value x as an n-byte big-endian value concat(x0, ..., xN): Concatenation of octet strings. concat(0x01, 0x0203, 0x040506) = 0x010203040506 zero(n): An all-zero octet string of length n. zero(4) = 0x00000000 xor(a,b): XOR of octet strings; xor(0xF0F0, 0x1234) = 0xE2C4. It is an error to call this function with two arguments of unequal length.

HPKE variants rely on the following primitives: A Key Encapsulation Mechanism (KEM): GenerateKeyPair(): Generate a key pair (sk, pk) Marshal(pk): Produce a fixed-length octet string encoding the public key pk Unmarshal(enc): Parse a fixed-length octet string to recover a public key Encap(pk): Generate an ephemeral, fixed-length symmetric key 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 from its encapsulated representation enc AuthEncap(pkR, skI) (optional): Same as Encap(), but the outputs encode an assurance that the ephemeral shared key is known only to the holder of the private key skI AuthDecap(skR, pkI) (optional): Same as Decap(), but the holder of the private key skR is assured that the ephemeral shared key is known only to the holder of the private key corresponding to pkI Nenc: The length in octets of an encapsulated key from this KEM Npk: The length in octets of a public key for this KEM A Key Derivation Function: Hash(m): Compute the cryptographic hash of input message m Extract(salt, IKM): Extract a pseudorandom key of fixed length from input keying material IKM and an optional octet 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 Hash and Extract functions An AEAD encryption algorithm : Seal(key, nonce, aad, pt): Encrypt and authenticate plaintext pt with associated data aad using secret key key and nonce nonce, yielding ciphertext and tag ct Open(key, nonce, aad, ct): Decrypt ciphertext ct using associated data aad with secret key key and nonce nonce, returning plaintext message pt or the error value OpenError Nk: The length in octets of a key for this algorithm Nn: The length in octets of a nonce for this algorithm A set of algorithm identifiers for concrete instantiations of these primitives is provided in . Algorithm identifier values are two octets long.

Suppose we are given a Diffie-Hellman group that provides the following operations: GenerateKeyPair(): Generate an ephemeral key pair (sk, pk) 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 fixed-length shared secret Marshal(pk): Produce a fixed-length octet string encoding the public key pk Unmarshal(enc): Parse a fixed-length octet string to recover a public key Then we can construct a KEM (which we’ll call “DHKEM”) in the following way:

The GenerateKeyPair, Marshal, and Unmarshal functions are the same as for the underlying DH group. The Marshal functions for the curves referenced in {#ciphersuites} are as follows: P-256: The X-coordinate of the point, encoded as a 32-octet big-endian integer P-521: The X-coordinate of the point, encoded as a 66-octet big-endian integer Curve25519: The standard 32-octet representation of the public key Curve448: The standard 56-octet representation of the public key

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 two authenticated variants, one of which authenticates possession of a pre-shared key, and one of which authenticates possession of a KEM private key. The following one-octet values will be used to distinguish between modes: Mode Value mode_base 0x00 mode_psk 0x01 mode_auth 0x02 mode_psk_auth 0x03 All of these cases follow the same basic two-step pattern: Set up an encryption context that is shared between the sender and the recipient 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. The procedures described in this session are laid out in a Python-like pseudocode. The algorithms in use are left implicit.

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: pkR - The receiver’s public key zz - A shared secret generated via the KEM for this transaction enc - An encapsulated key produced by the KEM for the receiver info - Application-supplied information (optional; default value “”) psk - A pre-shared secret held by both the initiator and the receiver (optional; default value zero(Nh)). pskID - An identifier for the PSK (optional; default value "" = zero(0) pkI - The initiator’s public key (optional; default value zero(Npk)) The psk and pskID 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. The key and nonce computed by this algorithm have the property that they are only known to the holder of the receipient private key, and the party that ran the KEM to generate zz and enc. If the psk and pskID arguments are provided, then the recipient is assured that the initiator held the PSK. If the pkIm argument is provided, then the recipient is assued that the initator held the corresponding private key (assuming that zz and enc were generated using the AuthEncap / AuthDecap methods; see below). The HPKE algorithm identifiers, i.e., the KEM kem_id, KDF kdf_id, and AEAD aead_id 2-octet code points, are assumed implicit from the implementation and not passed as parameters.

Note that the context construction in the KeySchedule procedure is equivalent to serializing a structure of the following form in the TLS presentation syntax:

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

This variant extends the base mechansism by allowing the recipient to authenticate that the sender possessed a given pre-shared key (PSK). We assume that both parties have been provisioned with both the PSK value psk and another octet string pskID that is used to identify which PSK should be used. The primary differences from the base case are: The PSK is used as the salt input to the KDF (instead of 0) The PSK ID is added to the context string used as the info input to the KDF This mechanism is not suitable for use with a low-entropy password as the PSK. A malicious recipient that does not possess the PSK can use decryption of a plaintext as an oracle for performing offline dictionary attacks.

This variant extends the base mechansism 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, pkI) produces the correct shared secret only if the encapsulated value enc was produced by AuthEncap(pkR, skI), where skI is the private key corresponding to pkI. In other words, only two people could have produced this secret, so if the recipient is one, then the sender must be the other. The primary differences from the base case are: The calls to Encap and Decap are replaced with calls to AuthEncap and AuthDecap. The initiator public key is added to the context string Obviously, this variant can only be used with a KEM that provides AuthEncap() and AuthDecap() procuedures. This mechanism authenticates only the key pair of the initiator, 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 unknown key share attacks.

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.

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 decryption must be stateful. Each of the setup procedures above produces a context object that stores the required state: The AEAD algorithm in use The key to be used with the AEAD algorithm A base nonce value A sequence number (initially 0) All of these fields except the 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 return an error if the sequence number overflows. Each encryption or decryption operation increments the sequence number for the context in use. A given context SHOULD be used either only for encryption or only for decryption. It is up to the application to ensure that encryptions and decryptions are done in the proper sequence, so that the nonce values used for encryption and decryption line up. If a Seal or Open operation would cause the seq field to wrap, then the implementation MUST return an error.

= (1 << Nn) - 1: return NonceOverflowError self.seq += 1 def Context.Seal(aad, pt): ct = Seal(self.key, self.Nonce(self.seq), aad, pt) self.IncrementSeq() return ct def Context.Open(aad, ct): pt = Open(self.key, self.Nonce(self.seq), aad, ct) if pt == OpenError: return OpenError self.IncrementSeq() return pt ]]>

In many cases, applications encrypt only a single message to a recipient’s public key. This section provides templates for HPKE APIs that implement “single-shot” encryption and decryption using APIs specified in and :

(pkR, info, aad, pt, ...): enc, ctx = SetupI(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. Thus, SealAuthPSK and OpenAuthPSK would be implemented as follows:

Value KEM Nenc Npk Reference 0x0000 (reserved) N/A N/A N/A 0x0001 DHKEM(P-256) 32 32 0x0002 DHKEM(Curve25519) 32 32 0x0003 DHKEM(P-521) 65 65 0x0004 DHKEM(Curve448) 56 56 For the NIST curves P-256 and P-521, the Marshal function of the DH scheme produces the normal (non-compressed) representation of the public key, according to . When these curves are used, the recipient of an HPKE ciphertext MUST validate that the ephemeral public key pkE is on the curve. The relevant validation procedures are defined in For the CFRG curves Curve25519 and Curve448, the Marshal function is the identity function, since these curves already use fixed-length octet strings for public keys.

Value KDF Nh Reference 0x0000 (reserved) N/A N/A 0x0001 HKDF-SHA256 32 0x0002 HKDF-SHA512 64

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

The general security properties of HPKE are described in . In this section, we consider a security issue that may arise in practice and an advanced use case.

The authenticated modes of HPKE (PSK, Auth, AuthPSK) require that the receiver know what key material to use for the initiator. This can be signaled in applications by sending the PSK ID (pskID above) and/or the initiator’s public key (pkI). However, these values themselves might be considered sensitive, since in a given application context, they might identify the initiator. 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 (pskID, pkI, enc, ciphertext) before, it would now send (enc2, ciphertext2, enc, ciphertext), where (enc2, ciphertext2) represent the encryption of the pskID and pkI values. The cost of this approach is an additional KEM operation each for the sender and the receiver. 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.

The Auth and AuthPSK modes HPKE can be used to construct a lightweight “designated-verifier signature” scheme , in the sense that the message is authenticated as coming from the initiator, but the only party who can verify the authentication is the receiver (the holder of skR). To create such a signature, the initator 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 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 receiver performs the corresponding HPKE setup and calls Open with the provided ciphertext. If the AEAD authentication passes, then the signature is valid. This scheme re-uses 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.

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.

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

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 Nenc: The length in bytes of an encapsulated key produced by the algorithm Npk: The length in bytes of a public key for the algorithm Reference: Where this algorithm is defined Initial contents: Provided in

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 length in bytes of the output of the KDF Reference: Where this algorithm is defined Initial contents: Provided in

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

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 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. 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 defines a simple mechanism for encrypting the Server Name Indication for TLS 1.3. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section.

These test vectors are also available in JSON format at .