Network Working Group R.L. Barnes Internet-Draft Cisco Intended status: Informational K. Bhargavan Expires: 31 January 2021 B. Lipp Inria C.A. Wood Cloudflare 30 July 2020 Hybrid Public Key Encryption draft-irtf-cfrg-hpke-05 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 31 January 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Barnes, et al. Expires 31 January 2021 [Page 1] Internet-Draft HPKE July 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Cryptographic Dependencies . . . . . . . . . . . . . . . . . 5 4.1. DH-Based KEM . . . . . . . . . . . . . . . . . . . . . . 7 5. Hybrid Public Key Encryption . . . . . . . . . . . . . . . . 10 5.1. Creating the Encryption Context . . . . . . . . . . . . . 11 5.1.1. Encryption to a Public Key . . . . . . . . . . . . . 14 5.1.2. Authentication using a Pre-Shared Key . . . . . . . . 14 5.1.3. Authentication using an Asymmetric Key . . . . . . . 15 5.1.4. Authentication using both a PSK and an Asymmetric Key . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Encryption and Decryption . . . . . . . . . . . . . . . . 16 5.3. Secret Export . . . . . . . . . . . . . . . . . . . . . . 17 6. Single-Shot APIs . . . . . . . . . . . . . . . . . . . . . . 18 7. Algorithm Identifiers . . . . . . . . . . . . . . . . . . . . 18 7.1. Key Encapsulation Mechanisms (KEMs) . . . . . . . . . . . 19 7.1.1. Serialize/Deserialize . . . . . . . . . . . . . . . . 19 7.1.2. DeriveKeyPair . . . . . . . . . . . . . . . . . . . . 19 7.1.3. Validation of Inputs and Outputs . . . . . . . . . . 20 7.2. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 21 7.2.1. Input Length Restrictions . . . . . . . . . . . . . . 21 7.3. Authenticated Encryption with Associated Data (AEAD) Functions . . . . . . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8.1. Security Properties . . . . . . . . . . . . . . . . . . . 23 8.2. Security Requirements on a KEM used within HPKE . . . . . 26 8.3. Security Requirements on a KDF . . . . . . . . . . . . . 26 8.4. Pre-Shared Key Recommendations . . . . . . . . . . . . . 26 8.5. Domain Separation . . . . . . . . . . . . . . . . . . . . 27 8.6. External Requirements / Non-Goals . . . . . . . . . . . . 28 8.7. Metadata Protection . . . . . . . . . . . . . . . . . . . 28 8.8. Designated-Verifier Signature . . . . . . . . . . . . . . 29 9. Message Encoding . . . . . . . . . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10.1. KEM Identifiers . . . . . . . . . . . . . . . . . . . . 30 10.2. KDF Identifiers . . . . . . . . . . . . . . . . . . . . 30 Barnes, et al. Expires 31 January 2021 [Page 2] Internet-Draft HPKE July 2020 10.3. AEAD Identifiers . . . . . . . . . . . . . . . . . . . . 31 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 12.1. Normative References . . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . 32 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 35 A.1. DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-128-GCM . . 35 A.1.1. Base Setup Information . . . . . . . . . . . . . . . 35 A.1.2. PSK Setup Information . . . . . . . . . . . . . . . . 36 A.1.3. Auth Setup Information . . . . . . . . . . . . . . . 38 A.1.4. AuthPSK Setup Information . . . . . . . . . . . . . . 40 A.2. DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, ChaCha20Poly1305 . . . . . . . . . . . . . . . . . . . . 42 A.2.1. Base Setup Information . . . . . . . . . . . . . . . 42 A.2.2. PSK Setup Information . . . . . . . . . . . . . . . . 44 A.2.3. Auth Setup Information . . . . . . . . . . . . . . . 45 A.2.4. AuthPSK Setup Information . . . . . . . . . . . . . . 47 A.3. DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, AES-128-GCM . . . 49 A.3.1. Base Setup Information . . . . . . . . . . . . . . . 49 A.3.2. PSK Setup Information . . . . . . . . . . . . . . . . 51 A.3.3. Auth Setup Information . . . . . . . . . . . . . . . 53 A.3.4. AuthPSK Setup Information . . . . . . . . . . . . . . 55 A.4. DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, ChaCha20Poly1305 . . . . . . . . . . . . . . . . . . . . 57 A.4.1. Base Setup Information . . . . . . . . . . . . . . . 57 A.4.2. PSK Setup Information . . . . . . . . . . . . . . . . 59 A.4.3. Auth Setup Information . . . . . . . . . . . . . . . 61 A.4.4. AuthPSK Setup Information . . . . . . . . . . . . . . 63 A.5. DHKEM(P-521, HKDF-SHA512), HKDF-SHA512, AES-256-GCM . . . 65 A.5.1. Base Setup Information . . . . . . . . . . . . . . . 65 A.5.2. PSK Setup Information . . . . . . . . . . . . . . . . 67 A.5.3. Auth Setup Information . . . . . . . . . . . . . . . 69 A.5.4. AuthPSK Setup Information . . . . . . . . . . . . . . 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 1. Introduction Encryption schemes that combine asymmetric and symmetric algorithms have been specified and practiced since the early days of public-key cryptography, e.g., [RFC1113]. 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 Barnes, et al. Expires 31 January 2021 [Page 3] Internet-Draft HPKE July 2020 type of public key encryption has many applications in practice, for example: * PGP [RFC6637] * Messaging Layer Security [I-D.ietf-mls-protocol] * TLS Encrypted ClientHello [I-D.ietf-tls-esni] * Protection of 5G subscriber identities [fiveG] Currently, there are numerous competing and non-interoperable standards and variants for hybrid encryption, mostly based on ECIES, including ANSI X9.63 (ECIES) [ANSI], IEEE 1363a [IEEE], ISO/IEC 18033-2 [ISO], and SECG SEC 1 [SECG]. See [MAEA10] 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 [HPKEAnalysis]. A summary of this analysis is in Section 8.1. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. 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. Barnes, et al. Expires 31 January 2021 [Page 4] Internet-Draft HPKE July 2020 * 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 [RFC8017]. 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. 4. 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 Section 7.1.2 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" Barnes, et al. Expires 31 January 2021 [Page 5] Internet-Draft HPKE July 2020 - "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 [RFC5116]: - "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. Barnes, et al. Expires 31 January 2021 [Page 6] Internet-Draft HPKE July 2020 A set of algorithm identifiers for concrete instantiations of these primitives is provided in Section 7. 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: def LabeledExtract(salt, label, ikm): labeled_ikm = concat("HPKE-05 ", suite_id, label, ikm) return Extract(salt, labeled_ikm) def LabeledExpand(prk, label, info, L): labeled_info = concat(I2OSP(L, 2), "HPKE-05 ", suite_id, label, info) return Expand(prk, labeled_info, L) [[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 Section 4.1 and Section 5.1 for details. 4.1. 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) Barnes, et al. Expires 31 January 2021 [Page 7] Internet-Draft HPKE July 2020 * "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. Section 7.1.2 contains the "DeriveKeyPair" function specification for DHKEMs defined in this document. def ExtractAndExpand(dh, kem_context): eae_prk = LabeledExtract("", "eae_prk", dh) shared_secret = LabeledExpand(eae_prk, "shared_secret", kem_context, Nsecret) return shared_secret def Encap(pkR): skE, pkE = GenerateKeyPair() dh = DH(skE, pkR) enc = Serialize(pkE) pkRm = Serialize(pkR) kem_context = concat(enc, pkRm) shared_secret = ExtractAndExpand(dh, kem_context) return shared_secret, enc def Decap(enc, skR): pkE = Deserialize(enc) dh = DH(skR, pkE) pkRm = Serialize(pk(skR)) kem_context = concat(enc, pkRm) shared_secret = ExtractAndExpand(dh, kem_context) return shared_secret def AuthEncap(pkR, skS): skE, pkE = GenerateKeyPair() dh = concat(DH(skE, pkR), DH(skS, pkR)) enc = Serialize(pkE) pkRm = Serialize(pkR) pkSm = Serialize(pk(skS)) kem_context = concat(enc, pkRm, pkSm) shared_secret = ExtractAndExpand(dh, kem_context) Barnes, et al. Expires 31 January 2021 [Page 8] Internet-Draft HPKE July 2020 return shared_secret, enc def AuthDecap(enc, skR, pkS): pkE = Deserialize(enc) dh = concat(DH(skR, pkE), DH(skR, pkS)) pkRm = Serialize(pk(skR)) pkSm = Serialize(pkS) kem_context = concat(enc, pkRm, pkSm) shared_secret = ExtractAndExpand(dh, kem_context) return shared_secret The implicit "suite_id" value used within "LabeledExtract" and "LabeledExpand" is defined as follows, where "kem_id" is defined in Section 7.1: suite_id = concat("KEM", I2OSP(kem_id, 2)) 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 Section 8.3 for a comment on the choice of a KDF for the remainder of HPKE, and Section 8.5 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 Section 8.1 for more details. Senders and recipients MUST validate KEM inputs and outputs as described in Section 7.1. Barnes, et al. Expires 31 January 2021 [Page 9] Internet-Draft HPKE July 2020 5. 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 | +---------------+-------+ Table 1 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 Section 5.3. See Section 5.2 for a description of this structure and its interfaces. HPKE decryption fails when the underlying AEAD decryption fails. Barnes, et al. Expires 31 January 2021 [Page 10] Internet-Draft HPKE July 2020 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 Section 9 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. 5.1. 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 Section 5. * "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 Section 7.1. 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. Barnes, et al. Expires 31 January 2021 [Page 11] Internet-Draft HPKE July 2020 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 Section 7.2.1 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 Section 4.1 and Section 8.1. 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 Section 8.1 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 Section 7, 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: suite_id = concat( "HPKE", I2OSP(kem_id, 2), I2OSP(kdf_id, 2), I2OSP(aead_id, 2) ) Barnes, et al. Expires 31 January 2021 [Page 12] Internet-Draft HPKE July 2020 default_psk = "" default_psk_id = "" def VerifyPSKInputs(mode, psk, psk_id): got_psk = (psk != default_psk) got_psk_id = (psk_id != default_psk_id) if got_psk != got_psk_id: raise Exception("Inconsistent PSK inputs") if got_psk and (mode in [mode_base, mode_auth]): raise Exception("PSK input provided when not needed") if (not got_psk) and (mode in [mode_psk, mode_auth_psk]): raise Exception("Missing required PSK input") def KeySchedule(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) psk_hash = LabeledExtract("", "psk_hash", psk) secret = LabeledExtract(psk_hash, "secret", shared_secret) key = LabeledExpand(secret, "key", key_schedule_context, Nk) nonce = LabeledExpand(secret, "nonce", key_schedule_context, Nn) exporter_secret = LabeledExpand(secret, "exp", key_schedule_context, Nh) return Context(key, nonce, 0, exporter_secret) See Section 5.2 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: struct { uint8 mode; opaque psk_id_hash[Nh]; opaque info_hash[Nh]; } KeyScheduleContext; Barnes, et al. Expires 31 January 2021 [Page 13] Internet-Draft HPKE July 2020 5.1.1. 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. def SetupBaseS(pkR, info): shared_secret, enc = Encap(pkR) return enc, KeySchedule(mode_base, shared_secret, info, default_psk, default_psk_id) def SetupBaseR(enc, skR, info): shared_secret = Decap(enc, skR) return KeySchedule(mode_base, shared_secret, info, default_psk, default_psk_id) 5.1.2. 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 Section 8.1. 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 Section 8.4 for a more detailed discussion. def SetupPSKS(pkR, info, psk, psk_id): shared_secret, enc = Encap(pkR) return enc, KeySchedule(mode_psk, shared_secret, info, psk, psk_id) def SetupPSKR(enc, skR, info, psk, psk_id): shared_secret = Decap(enc, skR) return KeySchedule(mode_psk, shared_secret, info, psk, psk_id) Barnes, et al. Expires 31 January 2021 [Page 14] Internet-Draft HPKE July 2020 5.1.3. 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 [UKS]. def SetupAuthS(pkR, info, skS): shared_secret, enc = AuthEncap(pkR, skS) return enc, KeySchedule(mode_auth, shared_secret, info, default_psk, default_psk_id) def SetupAuthR(enc, skR, info, pkS): shared_secret = AuthDecap(enc, skR, pkS) return KeySchedule(mode_auth, shared_secret, info, default_psk, default_psk_id) 5.1.4. 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. Barnes, et al. Expires 31 January 2021 [Page 15] Internet-Draft HPKE July 2020 def SetupAuthPSKS(pkR, info, psk, psk_id, skS): shared_secret, enc = AuthEncap(pkR, skS) return enc, KeySchedule(mode_auth_psk, shared_secret, info, psk, psk_id) def SetupAuthPSKR(enc, skR, info, psk, psk_id, pkS): shared_secret = AuthDecap(enc, skR, pkS) return KeySchedule(mode_auth_psk, shared_secret, info, psk, psk_id) The PSK SHOULD be of length Nh bytes or longer, and SHOULD have Nh bytes of entropy or more. See Section 8.4 for a more detailed discussion. 5.2. 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 Section 5.3 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. Barnes, et al. Expires 31 January 2021 [Page 16] Internet-Draft HPKE July 2020 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 Section 5.3 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. def Context.ComputeNonce(seq): seq_bytes = I2OSP(seq, Nn) return xor(self.nonce, seq_bytes) def Context.IncrementSeq(): if self.seq >= (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 5.3. Secret Export HPKE provides a interface for exporting secrets from the encryption "Context", similar to the TLS 1.3 exporter interface (See [RFC8446], 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 Barnes, et al. Expires 31 January 2021 [Page 17] Internet-Draft HPKE July 2020 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 Section 7.2.1 for precise limits on this length. def Context.Export(exporter_context, L): return LabeledExpand(self.exporter_secret, "sec", exporter_context, L) 6. 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 Section 5.1.1 and Section 5.2: def Seal(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: def SealAuthPSK(pkR, info, aad, pt, psk, psk_id, skS): enc, ctx = SetupAuthPSKS(pkR, info, psk, psk_id, skS) ct = ctx.Seal(aad, pt) return enc, ct def OpenAuthPSK(enc, skR, info, aad, ct, psk, psk_id, pkS): ctx = SetupAuthPSKR(enc, skR, info, psk, psk_id, pkS) return ctx.Open(aad, ct) 7. Algorithm Identifiers Barnes, et al. Expires 31 January 2021 [Page 18] Internet-Draft HPKE July 2020 7.1. 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, | 32 | 65 |65 | 32 | [NISTCurves], | | | HKDF-SHA256) | | | | | [RFC5869] | +--------+---------------+---------+------+---+-----+---------------+ | 0x0011 | DHKEM(P-384, | 48 | 97 |97 | 48 | [NISTCurves], | | | HKDF-SHA384) | | | | | [RFC5869] | +--------+---------------+---------+------+---+-----+---------------+ | 0x0012 | DHKEM(P-521, | 64 | 133 |133| 66 | [NISTCurves], | | | HKDF-SHA512) | | | | | [RFC5869] | +--------+---------------+---------+------+---+-----+---------------+ | 0x0020 | DHKEM(X25519, | 32 | 32 |32 | 32 | [RFC7748], | | | HKDF-SHA256) | | | | | [RFC5869] | +--------+---------------+---------+------+---+-----+---------------+ | 0x0021 | DHKEM(X448, | 64 | 56 |56 | 56 | [RFC7748], | | | HKDF-SHA512) | | | | | [RFC5869] | +--------+---------------+---------+------+---+-----+---------------+ Table 2 7.1.1. 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 [SECG]. "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 Section 7.1.3 for specifics. 7.1.2. 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. Barnes, et al. Expires 31 January 2021 [Page 19] Internet-Draft HPKE July 2020 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: def DeriveKeyPair(ikm): dkp_prk = LabeledExtract("", "dkp_prk", ikm) sk = 0 counter = 0 while sk == 0 or sk >= 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 [NISTCurves]), 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: def DeriveKeyPair(ikm): dkp_prk = LabeledExtract("", "dkp_prk", ikm) sk = LabeledExpand(dkp_prk, "sk", "", Nsk) return (sk, pk(sk)) 7.1.3. 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". Barnes, et al. Expires 31 January 2021 [Page 20] Internet-Draft HPKE July 2020 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 [keyagreement]. 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 [RFC7748]. In particular, recipients MUST check whether the Diffie-Hellman shared secret is the all-zero value and abort if so. 7.2. Key Derivation Functions (KDFs) +========+=============+=====+===========+ | Value | KDF | Nh | Reference | +========+=============+=====+===========+ | 0x0000 | (reserved) | N/A | N/A | +--------+-------------+-----+-----------+ | 0x0001 | HKDF-SHA256 | 32 | [RFC5869] | +--------+-------------+-----+-----------+ | 0x0002 | HKDF-SHA384 | 48 | [RFC5869] | +--------+-------------+-----+-----------+ | 0x0003 | HKDF-SHA512 | 64 | [RFC5869] | +--------+-------------+-----+-----------+ Table 3 7.2.1. 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: Barnes, et al. Expires 31 January 2021 [Page 21] Internet-Draft HPKE July 2020 +==================+==============+===============+===============+ | 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 | +------------------+--------------+---------------+---------------+ Table 4 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: max_size_hash_input - Nb - size_label_rfcXXXX - size_suite_id - size_input_label The value for "exporter_context" which is an input to "LabeledExpand()" was computed with the following expression: max_size_hash_input - Nb - Nh - size_label_rfcXXXX - size_suite_id - size_input_label - 2 - 1 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.]] Barnes, et al. Expires 31 January 2021 [Page 22] Internet-Draft HPKE July 2020 7.3. 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 | [GCM] | +--------+------------------+-----+-----+-----------+ | 0x0002 | AES-256-GCM | 32 | 12 | [GCM] | +--------+------------------+-----+-----+-----------+ | 0x0003 | ChaCha20Poly1305 | 32 | 12 | [RFC8439] | +--------+------------------+-----+-----+-----------+ Table 5 8. Security Considerations 8.1. 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 Section 8.6, 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 Barnes, et al. Expires 31 January 2021 [Page 23] Internet-Draft HPKE July 2020 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 [BJM97], 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 [NaCl] 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 [WireGuard]. It is shown in [CS01] 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 [HPKEAnalysis]: * DH group: The gap Diffie-Hellman (GDH) problem is hard in the appropriate subgroup [GAP]. * "Extract()" and "Expand()" (in DHKEM): "Extract()" is indifferentiable from a random oracle. "Expand()" is a pseudorandom function, wherein the first argument is the key. Barnes, et al. Expires 31 January 2021 [Page 24] Internet-Draft HPKE July 2020 * "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 Section 7.2 and Section 7.1) satisfy these properties when used as specified. The analysis in [HPKEAnalysis] 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 [HPKEAnalysis]. 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 | +---------+--------------+-------------+--------------+ Table 6 If non-DH-based KEMs are to be used with HPKE, further analysis will be necessary to prove their security. The results from [CS01] provide some indication that any IND-CCA2-secure KEM will suffice here, but are not conclusive given the differences in the schemes. Barnes, et al. Expires 31 January 2021 [Page 25] Internet-Draft HPKE July 2020 In addition, both [CS01] and [HPKEAnalysis] 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 [HPKEAnalysis]; in a quantum setting, the remaining security level is smaller and defined by the post-quantum security level of the AEAD scheme. 8.2. 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 [S01]. 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. 8.3. 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 [HMAC]. 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. 8.4. 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. Barnes, et al. Expires 31 January 2021 [Page 26] Internet-Draft HPKE July 2020 HPKE is specified to use HKDF as key derivation function. HKDF is not designed to slow down dictionary attacks, see [RFC5869]. 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. 8.5. 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. Barnes, et al. Expires 31 January 2021 [Page 27] Internet-Draft HPKE July 2020 8.6. 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. 8.7. 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 [BNT19] could be extended to cover other metadata. However, this construction would require further analysis. Barnes, et al. Expires 31 January 2021 [Page 28] Internet-Draft HPKE July 2020 8.8. Designated-Verifier Signature The Auth and AuthPSK modes can be used to construct a lightweight "designated-verifier signature" scheme [JKR96], 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. 9. 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. 10. IANA Considerations This document requests the creation of three new IANA registries: * HPKE KEM Identifiers * HPKE KDF Identifiers * HPKE AEAD Identifiers Barnes, et al. Expires 31 January 2021 [Page 29] Internet-Draft HPKE July 2020 All of these registries should be under a heading of "Hybrid Public Key Encryption", and administered under a Specification Required policy [RFC8126] 10.1. 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 Section 7.1 10.2. 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 Section 7.2 Barnes, et al. Expires 31 January 2021 [Page 30] Internet-Draft HPKE July 2020 10.3. 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 Section 7.3 11. 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. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . Barnes, et al. Expires 31 January 2021 [Page 31] Internet-Draft HPKE July 2020 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informative References [ANSI] American National Standards Institute, "ANSI X9.63 Public Key Cryptography for the Financial Services Industry -- Key Agreement and Key Transport Using Elliptic Curve Cryptography", 2001. [BJM97] Blake-Wilson, S., Johnson, D., and A. Menezes, "Key agreement protocols and their security analysis", DOI 10.1007/bfb0024447, Crytography and Coding pp. 30-45, 1997, . [BNT19] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed: AEAD Revisited", 2019, . [CS01] Cramer, R. and V. Shoup, "Design and Analysis of Practical Public-Key Encryption Schemes Secure against Adaptive Chosen Ciphertext Attack", 2001, . [fiveG] "Security architecture and procedures for 5G System", 2019, . [GAP] Okamoto, T. and D. Pointcheval, "The Gap-Problems - a New Class of Problems for the Security of Cryptographic Schemes", ISBN 978-3-540-44586-9, 2001, . [GCM] Dworkin, M., "Recommendation for block cipher modes of operation :", DOI 10.6028/nist.sp.800-38d, National Institute of Standards and Technology report, 2007, . Barnes, et al. Expires 31 January 2021 [Page 32] Internet-Draft HPKE July 2020 [HMAC] Dodis, Y., Ristenpart, T., Steinberger, J., and S. Tessaro, "To Hash or Not to Hash Again? (In)differentiability Results for H^2 and HMAC", 2013, . [HPKEAnalysis] Lipp, B., "An Analysis of Hybrid Public Key Encryption", 2020, . [I-D.ietf-mls-protocol] Barnes, R., Beurdouche, B., Millican, J., Omara, E., Cohn- Gordon, K., and R. Robert, "The Messaging Layer Security (MLS) Protocol", Work in Progress, Internet-Draft, draft- ietf-mls-protocol-09, 6 March 2020, . [I-D.ietf-tls-esni] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-07, 1 June 2020, . [IEEE] Institute of Electrical and Electronics Engineers, "IEEE 1363a, Standard Specifications for Public Key Cryptography - Amendment 1 -- Additional Techniques"", 2004. [ISO] International Organization for Standardization / International Electrotechnical Commission, "ISO/IEC 18033-2, Information Technology - Security Techniques - Encryption Algorithms - Part 2 -- Asymmetric Ciphers", 2006. [JKR96] Jakobsson, M., Sako, K., and R. Impagliazzo, "Designated Verifier Proofs and Their Applications", 1996, . [keyagreement] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for pair-wise key-establishment schemes using discrete logarithm cryptography", DOI 10.6028/nist.sp.800-56ar3, National Institute of Standards and Technology report, April 2018, . [MAEA10] Gayoso Martinez, V., Hernandez Alvarez, F., Hernandez Encinas, L., and C. Sanchez Avila, "A Comparison of the Standardized Versions of ECIES", 2010, . Barnes, et al. Expires 31 January 2021 [Page 33] Internet-Draft HPKE July 2020 [NaCl] "Public-key authenticated encryption: crypto_box", 2019, . [NISTCurves] "Digital Signature Standard (DSS)", DOI 10.6028/nist.fips.186-4, National Institute of Standards and Technology report, July 2013, . [RFC1113] Linn, J., "Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures", RFC 1113, DOI 10.17487/RFC1113, August 1989, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in OpenPGP", RFC 6637, DOI 10.17487/RFC6637, June 2012, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [S01] Shoup, V., "A proposal for an ISO standard for public key encryption (version 2.1)", 2001, . [SECG] "Elliptic Curve Cryptography, Standards for Efficient Cryptography Group, ver. 2", 2009, . [TestVectors] "HPKE Test Vectors", 2020, . Barnes, et al. Expires 31 January 2021 [Page 34] Internet-Draft HPKE July 2020 [UKS] Diffie, W., Van Oorschot, P., and M. Wiener, "Authentication and authenticated key exchanges", DOI 10.1007/bf00124891, Designs, Codes and Cryptography Vol. 2, pp. 107-125, June 1992, . [WireGuard] Donenfeld, J.A., "WireGuard: Next Generation Kernel Network Tunnel", 2020, . Appendix A. Test Vectors These test vectors are also available in JSON format at [TestVectors]. 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))". A.1. DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-128-GCM A.1.1. Base Setup Information mode: 0 kem_id: 32 kdf_id: 1 aead_id: 1 info: 4f6465206f6e2061204772656369616e2055726e seedE: a77ae3e14cc2ec9e603a9049423d48e66a5e3139e896e95cf19919430657adc7 seedR: 1289f0db1d8f68d0c531b5e53a40911a2a2347059355d7c267717033fef2b08c enc: 8a07563949fac6232936ed6f36c4fa735930ecdeaef6734e314aeac35a56fd0a shared_secret: f3822302c852b924c5f984f192d39705ddd287ea93bb73e3c5f95ba6da7e01f5 key_schedule_context: 000c085d4e6d2e6a568b5dcf334f7badd56222cd79f2ac98b6 f99059f311c3f16a44c484c33962433c90728ac6c2893f828d58cebf58ba4fdae59b0a8f 7ab84ff8 secret: 98a35c8191d511d39a35afcb6cd4072d5038afb2bcc1ecb468626466b2870447 key: 550ee0b7ec1ea2532f2e2bac87040a4c nonce: 2b855847756795a57229559a exporter_secret: 1aabf0ea393517daa48a9eaf44a886f5e059d455988a65ae8d66b3c017fc3722 A.1.1.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 35] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: 2b855847756795a57229559a ciphertext: 971ba65db526758ea30ae748cd769bc8d90579b62a037816057f24ce4274 16bd47c05ed1c2446ac8e19ec9ae79 sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: 2b855847756795a57229559b ciphertext: f18f1ec397667ca069b9a6ee0bebf0890cd5caa34bb9875b3600ca0142cb a774dd35f2aafd79a02a08ca5f2806 sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: 2b855847756795a572295598 ciphertext: 51a8dea350fe6e753f743ec17c956de4cbdfa35f3018fc6a12752c51d137 2c5093959f18c7253da9c953c6cfbe sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: 2b855847756795a57229559e ciphertext: 2e5fa3a358e3ab64e5e981c4b89b5ae4cc5b800aaf726dc64ff857536a3d b0e6d816199e711aac60c4670c2a31 A.1.2. PSK Setup Information Barnes, et al. Expires 31 January 2021 [Page 36] Internet-Draft HPKE July 2020 mode: 1 kem_id: 32 kdf_id: 1 aead_id: 1 info: 4f6465206f6e2061204772656369616e2055726e seedE: 0fa1407ccee05de0cceb2f2d2381d2df0602dbd43be90eefd288ce4ad0b3ba32 seedR: 326ee379f778718e6cb343f55668fbb9d0098ba0503cd4414a8f1ce252605c39 psk: 5db3b80a81cb63ca59470c83414ef70a psk_id: 456e6e796e20447572696e206172616e204d6f726961 enc: 08d39d3e7f9b586341b6004dafba9679d2bd9340066edb247e3e919013efcd0f shared_secret: 9d4fe1809006b38854f056830b8900086f562207dce6010eadf23d2d5303cdf8 key_schedule_context: 01512564fc13bf3387a7d73eb72eb6b62766480582bfe146c4 e5afb8788652269644c484c33962433c90728ac6c2893f828d58cebf58ba4fdae59b0a8f 7ab84ff8 secret: 84d1c77bdf45e43e2e84f607573f0db0758c56f322500a673be8e2062d343b1f key: 811e9b2d7a10f4f9d58786bf8a534ca6 nonce: b79b0c5a8c3808e238b10411 exporter_secret: 7e9ef6d537503f815d0eaf70550a1f8e9af12c1cccb76919aafe93535547c150 A.1.2.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 37] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: b79b0c5a8c3808e238b10411 ciphertext: fb68f911b4e4033d1547f646ea30c9cee987fb4b4a8c30918e5de6e96de3 2fc63466f2fc05e09aeff552489741 sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: b79b0c5a8c3808e238b10410 ciphertext: 85e7472fbb7e2341af35fb2a0795df9a85caa99a8f584056b11d452bc160 470672e297f9892ce2c5020e794ae1 sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: b79b0c5a8c3808e238b10413 ciphertext: 74229b7491102bcf94cf7633888bc48baa4e5a73cc544bfad4ff61585506 facb44b359ade03c0b2b35c6430e4c sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: b79b0c5a8c3808e238b10415 ciphertext: 5aeb09a3798d21dc2ca01f5c255624c9c8c20d75d79d19269eca7b280be0 cb7851fae82b646bd5673d10368276 A.1.3. Auth Setup Information Barnes, et al. Expires 31 January 2021 [Page 38] Internet-Draft HPKE July 2020 mode: 2 kem_id: 32 kdf_id: 1 aead_id: 1 info: 4f6465206f6e2061204772656369616e2055726e seedE: 02900cb4856b5f222293a9bd7bda2f1f81c562dc3002336ad1c39f6572402b7d seedR: 518df90f0f5044ce653180c700e4902d37a7ba1cd23482a76e18b300fecaac4e seedS: 262a05ad0c08030cdbbaafc03d64f33b95bf8089f216c62ac39b72064a4b4dcb enc: 56a21e8b5416d187c3d865765794e7f361d631049ebbb6a64ed28fd071068121 shared_secret: dec9ae331e9017669151e07c06d1cd7f3dd318c180c9cad5223e1c2b019d2243 key_schedule_context: 020c085d4e6d2e6a568b5dcf334f7badd56222cd79f2ac98b6 f99059f311c3f16a44c484c33962433c90728ac6c2893f828d58cebf58ba4fdae59b0a8f 7ab84ff8 secret: a78ac3f106be621d7ce48d7f02e9c69f23c042912697a985787c34e5340ca8e7 key: 82a24b8790521d6b2d260664d9bfaefc nonce: bb0cb3a72dff841c796fce56 exporter_secret: 933d7ef819b2fabc810db31f7fcbe5b16c4efa0f4b715e888466829d9b22062d A.1.3.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 39] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: bb0cb3a72dff841c796fce56 ciphertext: 86dea722bc4f4cb0983b70dbdb539cf79e393546805d90d3f832af5f907c 86f37ac579976db191a479c9450f37 sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: bb0cb3a72dff841c796fce57 ciphertext: 4f6b757fc0e807cf8f4726ed1bd05c6b87714b2332372795f7e8579fe21e 104ff8180fea797855a62f71a37aea sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: bb0cb3a72dff841c796fce54 ciphertext: 999285da95ed93dfb48bbe99d46ebba43c98e35f6ccd4fed92edf9d618e9 8174b63a0a2c12ab91521669fdad2c sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: bb0cb3a72dff841c796fce52 ciphertext: 1ac6af74dfe65c63b046eb99fb9036ce759ddf5bfb3a396796892c78ce3f 35beeedb7b3d1b515a9dff7d9af365 A.1.4. AuthPSK Setup Information Barnes, et al. Expires 31 January 2021 [Page 40] Internet-Draft HPKE July 2020 mode: 3 kem_id: 32 kdf_id: 1 aead_id: 1 info: 4f6465206f6e2061204772656369616e2055726e seedE: c1d1028243a951dbf6469025f3a1304407b08fb932104e61c7aab42ab4f1995c seedR: 02a965d8f53bbdcc11cc618d4f31f69277500b75959ca97fd533058315511d1b seedS: e9c09a3e50073935e75d3846007a26088a93ebf58ad0bb30ad6c42a9d4d2419e psk: 5db3b80a81cb63ca59470c83414ef70a psk_id: 456e6e796e20447572696e206172616e204d6f726961 enc: 0f496b65ac352457865d9f6cb30e0ceaffee742accb016c2c1a7cec68a33244c shared_secret: 83272c7b992c197f882d992ef6737bb7f4b17ddf103368e1d7e90b07c946b2e3 key_schedule_context: 03512564fc13bf3387a7d73eb72eb6b62766480582bfe146c4 e5afb8788652269644c484c33962433c90728ac6c2893f828d58cebf58ba4fdae59b0a8f 7ab84ff8 secret: 619e4c000edf5cb8c2b795fbf2dce842d0ff5cba4e12312f5fc67510eb059560 key: b305d06827e854504246d9bbae3b1f80 nonce: 4940e55b734bbe1d46e24bd6 exporter_secret: bd6ec34885e97fe0c07bda3454d47ece7b6e9a1a05f729223485e4335c40cbdf A.1.4.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 41] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: 4940e55b734bbe1d46e24bd6 ciphertext: c7200a5246b4aa9e6878e22830d19466ca31394651ae84383f183991d3a8 662415d60e1e073209e6dadd480ff2 sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: 4940e55b734bbe1d46e24bd7 ciphertext: 8071f54a0a43f77a30de1fd96133d91184b5f863525d7810eb9350aa2555 8bc470781e62c27fe9a566f15efdc8 sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: 4940e55b734bbe1d46e24bd4 ciphertext: fc9747b21f74c098899e408d86c11d28617a1a3eb2d985fe4af7ccea2023 43df096920759614bfa2586f0f1c5a sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: 4940e55b734bbe1d46e24bd2 ciphertext: d85c2d06220ae34064210c4129f8c95dd43c45fb87ab25885467dc2c6a66 3deb84043eedde254968c55ef693e6 A.2. DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, ChaCha20Poly1305 A.2.1. Base Setup Information Barnes, et al. Expires 31 January 2021 [Page 42] Internet-Draft HPKE July 2020 mode: 0 kem_id: 32 kdf_id: 1 aead_id: 3 info: 4f6465206f6e2061204772656369616e2055726e seedE: 8c5a8a722a10c144a7577a73bbbbddb0284ea3436f9901a12c54eafd6eb5cb81 seedR: da0002ddf1803c7d54c1fb10fd68eb76afa2aa4577352b9ce26462cf63a97f6f enc: 716281787b035b2fee90455d951fa70b3db6cc92f13bedfd758c3487994b7020 shared_secret: f995f043efe63c77ac333fbe6007240fd01006bac1b075d2807845afae89a19f key_schedule_context: 00cbe688614d6e54c26594f3c118e6cb1a01f6c6572a9112dc 2687bd3e8b1e6ba06da3f8f29fa93987a2c185c1c17e719f7ae8eb4d564b80119e012c9c 959b0ca1 secret: b061e1b7e604df2fe8a4d32e25d33aeb5a0849e7b15dd212231adbf656259f8b key: 1d5e71e2885ddadbcc479798cc65ea74d308f2a9e99c0cc7fe480adce66b5722 nonce: 8354a7fcfef97d4bbef6d24e exporter_secret: 3ef38fcad3a0bc7fca8ba8ccea4a556db32320bca35140cb9ee6ec6dd801b602 A.2.1.1. Encryptions sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: 8354a7fcfef97d4bbef6d24e ciphertext: fa4632a400962c98143e58450e75d879365359afca81a5f5b5997c655564 7ec302045a80c57d3e2c2abe7e1ced sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: 8354a7fcfef97d4bbef6d24f ciphertext: 8313fcbf760714f5a93b6864820e48dcec3ddd476ad4408ff1c1a1f7bfb8 cb8699fada4a9e59bf8086eb1c0635 sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: 8354a7fcfef97d4bbef6d24c ciphertext: 020f2856d95b85e1def9549bf327c484d327616f1e213045f117be4c2875 71ab983958f74766cbc6f8197c8d8d sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: 8354a7fcfef97d4bbef6d24a ciphertext: 5e688918b05e96631628eef3e74781caf41c4f25ee1ef52ca1d746ca3156 1392c8833a7232036bf8e839a4c8e0 Barnes, et al. Expires 31 January 2021 [Page 43] Internet-Draft HPKE July 2020 A.2.2. PSK Setup Information mode: 1 kem_id: 32 kdf_id: 1 aead_id: 3 info: 4f6465206f6e2061204772656369616e2055726e seedE: 31c63611a67f55281f76477958758873f7a65113f3e1666ba5fce96e96852684 seedR: 2dc8b23353f632c2797ba4644fafb7363d958c1fce79162a215863951bd9a06c psk: 5db3b80a81cb63ca59470c83414ef70a psk_id: 456e6e796e20447572696e206172616e204d6f726961 enc: f4639297e3305b03d34dd5d86522ddc6ba11a608a0003670a30734823cdd3763 shared_secret: 95978c18311fc9e360209dd2cd10b2fcacf019ed25f7703cb2b4e4538558c13f key_schedule_context: 01f5f7e2ba59c3ff0cff51f71c4204fcfc76c95f778b37ccdc 6a83b3df36c33e7b6da3f8f29fa93987a2c185c1c17e719f7ae8eb4d564b80119e012c9c 959b0ca1 secret: 2c25a1d6e3b889cc8ea031a96aa3357f16973f83ab1d444114e7bb4f56e4a639 key: 396c06a52b39d0930594aa2c6944561cc1741f638557a12bef1c1cad349157c9 nonce: baa4ecf96b5d6d536d0d7210 exporter_secret: 96c88d4b561a2fc98cbafc9cb7d98895c8962ba5d9693da550cf7ed115d9753f A.2.2.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 44] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: baa4ecf96b5d6d536d0d7210 ciphertext: f97ca72675b8199e8ffec65b4c200d901110b177b246f241b6f9716fb60b 35b32a6d452675534b591e8141468a sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: baa4ecf96b5d6d536d0d7211 ciphertext: 57796e2b9dd0ddf807f1a7cb5884dfc50e61468c4fd69fa03963731e5167 4ca88fee94eeac3290734e1627ded6 sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: baa4ecf96b5d6d536d0d7212 ciphertext: b514150af1057151687d0036a9b4a3ad50fb186253f839d8433622baa857 19ed5d2532017a0ce7b9ca0007f276 sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: baa4ecf96b5d6d536d0d7214 ciphertext: 6232e4a184dbff7361f9e4d6bfaaf97631225ee317e63cb09e8f74fc93ef eedb6385d4f4cb2e30ffb82aea0e1f A.2.3. Auth Setup Information Barnes, et al. Expires 31 January 2021 [Page 45] Internet-Draft HPKE July 2020 mode: 2 kem_id: 32 kdf_id: 1 aead_id: 3 info: 4f6465206f6e2061204772656369616e2055726e seedE: c9c2d6f5a6f88e4c2bf5600817aa140fcb46dc682942bfca357c30fe2db17d6b seedR: 71237558db2b55c1a09f6695187d2af6e7d1dd97256cbb927bfc8a794476d07f seedS: 4255c61730d15a7ed2018a023ad45274c1ab38ce621d4b597636e08e97619ef1 enc: f82cc290dd57c0c63f041ad62605d1ae0c5436243e18758b2b63658904ee6a09 shared_secret: 92d03a5e87f58fda583129e62f1cb55769df02a2453863b0a09f55e4bd5ff7be key_schedule_context: 02cbe688614d6e54c26594f3c118e6cb1a01f6c6572a9112dc 2687bd3e8b1e6ba06da3f8f29fa93987a2c185c1c17e719f7ae8eb4d564b80119e012c9c 959b0ca1 secret: 4760feb6cc5ac6891ef2114490723c6ca2ad3352b2c52a60b390616d731f7767 key: 7638c7ade5856344fbc3a92600fa278dfff1c22b5857fe2c391e5bd248ac32ac nonce: 1d14b2320b54376e6c43e791 exporter_secret: 0ea20eb846e3c26f1ee8b2ecf55c9abdfecc910387945528c73a5ff91bc4ef38 A.2.3.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 46] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: 1d14b2320b54376e6c43e791 ciphertext: 30b013196168dcaf7a07047eda596f8c4f425abe6cfa269a7602b2a2b0be a958e2ded3c68c8c9e341ca4bf2e31 sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: 1d14b2320b54376e6c43e790 ciphertext: a259ce67a35c44ff9616f83cceadb2f0f542b208e9410686ece7e3eb92f0 8ca2e3fc95ccde64e849c96367952a sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: 1d14b2320b54376e6c43e793 ciphertext: 4691caf957cf159e39a3f66cee9cd76e06ae3e7f97c577898423babfdc98 00669d69356531dab839e0a491d502 sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: 1d14b2320b54376e6c43e795 ciphertext: 471ccbb6a81a3bfcc4c11dbeed62e95a7279fdab214f3b0cf22e998a89a2 fd054fdf6326ea6a340b20cfafae20 A.2.4. AuthPSK Setup Information Barnes, et al. Expires 31 January 2021 [Page 47] Internet-Draft HPKE July 2020 mode: 3 kem_id: 32 kdf_id: 1 aead_id: 3 info: 4f6465206f6e2061204772656369616e2055726e seedE: ca35fe19e214033e34465a3bb125dfea8b483e55fb8163774413d95a4d9b1f0e seedR: 9a063358dc95c04f2bdf2a9a2911145c0632f49012829d92b2b5d9f398a9cbe3 seedS: bc7c6a9ce74ba9e7fff0644da70899148f4775eaa1857478f0275af76cabb764 psk: 5db3b80a81cb63ca59470c83414ef70a psk_id: 456e6e796e20447572696e206172616e204d6f726961 enc: a6125996b3bb128bfa05392ffb39afd1e5b0031625e26c8c484e4aea0721ec39 shared_secret: 0c9ac657691ef63b088f9777e84a9a8ccda766f0c9834ad318c0e49cc34fa43f key_schedule_context: 03f5f7e2ba59c3ff0cff51f71c4204fcfc76c95f778b37ccdc 6a83b3df36c33e7b6da3f8f29fa93987a2c185c1c17e719f7ae8eb4d564b80119e012c9c 959b0ca1 secret: 502a94d9ee9cf5367beb65a97e7bfeae19a7cfbff25c6a4d2a9d1ece4d744b41 key: 968ebe599b1443cbfbd1914daa5bf667a52cf7a3339ecb209e8684f1f9c97d86 nonce: a0bcc93f25f5b9e707f453e3 exporter_secret: 12fa76c18f0c16769262574bc6d49e9b22cac1d963e3e6b91031f61ef4277350 A.2.4.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 48] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: a0bcc93f25f5b9e707f453e3 ciphertext: 1b049559f757b7c16d77bec8a8cf9c1cecc6becaa08aa513c791822b8293 45cf4477936df226e34804acb93b33 sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: a0bcc93f25f5b9e707f453e2 ciphertext: 21311cd102acdb30e18669620623c54dc66eb0c5cc7fad1ac1a327062d89 fc1fb6cd1228f8de48418d089a709d sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: a0bcc93f25f5b9e707f453e1 ciphertext: 3e84e9e5c3d004a6d8cea022c8ae5a10bac7d75829a189b137db55e6a5c1 1974792e8a6b92cc208d615f424d45 sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: a0bcc93f25f5b9e707f453e7 ciphertext: 595f2004a961c4762e418d33821f5c73335a681e75512134c5a5e3912d24 bd089b074e018f042e6164bc72c5f5 A.3. DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, AES-128-GCM A.3.1. Base Setup Information Barnes, et al. Expires 31 January 2021 [Page 49] Internet-Draft HPKE July 2020 mode: 0 kem_id: 16 kdf_id: 1 aead_id: 1 info: 4f6465206f6e2061204772656369616e2055726e seedE: 616ed5a6277fd3324e0cc0f4349cd345b0adbb1ceb98de44c03aab083fbaa6e6 seedR: 67bc0b8ba01fd8a1526d13c803d4d9ffe1a9914ac27e7a6c925b1580893a8485 enc: 048a0c9b27c844f5f1c6a1d9d570e34909c6359997b6acbd8132f1536d1f7685ff0 d203f205dfe4a789e4af3f599172b613d060c80d0e1341f066a87c0f83d827c shared_secret: 5f175bec391524f0153b05559212adbc2f5d6981b95a5d53fa7ed58fe5e156be key_schedule_context: 00c14ae6a0da7c6764c62eba270ec0cc28b5b568b4849a9b59 425c08860800fad8a633c96fae27707d2cfedac544e900a8b52a016cf86e4bf25a7d350f be847f8d secret: f753e6728460efed42ca308bef93e8b6646cec0252a0154d8310984445bb0629 key: d0696b5461fee5620d54f33b04a00f79 nonce: 99f33bd3ad9ad334b17de055 exporter_secret: f79e9a0e83b5c678cc0c9240b68fc3a84096ce374f37673ad4ea345ef0a3510c A.3.1.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 50] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: 99f33bd3ad9ad334b17de055 ciphertext: 0d77ad2340cc7af125fcd7f4ea63bca7e857d774d08365eff8c7f63091a5 e5aebca4721c854579b11149649209 sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: 99f33bd3ad9ad334b17de054 ciphertext: 90260e86b560860d0bf7bd1273bf7b6f4bf43aa94d475c93015c5d5b536a ae7631227968ab1aecc337cd080988 sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: 99f33bd3ad9ad334b17de057 ciphertext: fba616306cbe53eb8faef059a8d39947102a037c2e5bfb6b770bf7241576 b74e197ae6972c39177b8393e4bece sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: 99f33bd3ad9ad334b17de051 ciphertext: ca7c1e359bb916ec8aed3a10bd2a703d044af6a1a1b5a8f8bbba63141f35 ca7c292516bda6c97c4bfe85333f6f A.3.2. PSK Setup Information Barnes, et al. Expires 31 January 2021 [Page 51] Internet-Draft HPKE July 2020 mode: 1 kem_id: 16 kdf_id: 1 aead_id: 1 info: 4f6465206f6e2061204772656369616e2055726e seedE: 8131f719cf2d1f5263da51e133876a99eaaf5d5fb118bda64ef12ca6fa40f987 seedR: 236ddc165201cb79b2d8c7399c7f6e6e8cc4542b2fd1b75d107875db2b89cced psk: 5db3b80a81cb63ca59470c83414ef70a psk_id: 456e6e796e20447572696e206172616e204d6f726961 enc: 04df79d22d7cba95ff448cf84ffa01cdd87a68c9ef70dd926fe164a76d2cd243036 f3a34e9bac0725406fcb46d7c723248e42c3b329bed5bf8fcaa47d87d9d3e00 shared_secret: 1f245a22765eaf94b3a76463b9a248941078d138c3216acfcbd1d25f8772afda key_schedule_context: 018c27d3410cb79f908302ae06a67ad4c6f971cc37f64c2380 7cb4de4adeaa7d76a633c96fae27707d2cfedac544e900a8b52a016cf86e4bf25a7d350f be847f8d secret: fc6a6aca6b179515d69086844efec0acda07bd55efd50873cb46fb811faea941 key: 89fb75a38ba6bab89b1a8b0fc7db366e nonce: 00b1c2de64b6a56a51921d56 exporter_secret: cbd0d3b0ce32cc4ad834a0e81cecd21ecba042a0f4f25ae839a1fe95e56b89ff A.3.2.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 52] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: 00b1c2de64b6a56a51921d56 ciphertext: 75e82c5e991af745c380557b2f03f793dde5f4a78b3bf31429735aebbbd8 81580917e8a489fb0da3b081444319 sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: 00b1c2de64b6a56a51921d57 ciphertext: bc7e436c6435634a69147dc20e3abae51f2c02f96ec2b198138b5e10e284 20cb45a7ee149b1d936154ca320e08 sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: 00b1c2de64b6a56a51921d54 ciphertext: bd020f02b8eaae481e512bfe4969b2b285c636f756c72d70022f31af52bf 00692c57264bb214a412ac8fb1b965 sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: 00b1c2de64b6a56a51921d52 ciphertext: b1ff4e7b8ec452aff36b06c5c1bcf7e4e1cdd3211f1516ce752366f1b81d 5cc813e4d5e2142239afcbd1a75f4e A.3.3. Auth Setup Information Barnes, et al. Expires 31 January 2021 [Page 53] Internet-Draft HPKE July 2020 mode: 2 kem_id: 16 kdf_id: 1 aead_id: 1 info: 4f6465206f6e2061204772656369616e2055726e seedE: f9b977313fa3cd4dd8637307fc93e48093ab6bcd45781ad9f7a79f5f0e379bb6 seedR: 740a67dba29760f8d95e953a1ae75fda6d5eede2a41c15f4860b5557d4763fbf seedS: 174deda86fb885b78e5ef8ad158be3c38349c5322120f03ee9ddb6336788d8ca enc: 04686fc26c925890636fdaabae3434af53172035f7a191bc21fbc7ad9161ee1673c 0e6b61d0c4b2db3140d622c46c8e42fd4e10fb48b4fd522ff59f795659a5b13 shared_secret: 8e1409be7adea332a36fbf29bf8668ae13d66cfecf5d02e8d2cb2c16950af36e key_schedule_context: 02c14ae6a0da7c6764c62eba270ec0cc28b5b568b4849a9b59 425c08860800fad8a633c96fae27707d2cfedac544e900a8b52a016cf86e4bf25a7d350f be847f8d secret: 35cafa2133584ef110a63010be05bcbc32fe5b5985f5b62ae94c07cd3a844ae1 key: 40eef365aa0dcee18cb7d16b0d24e35d nonce: a5f0d2f22f3e404976ca7b1b exporter_secret: 162a8e2af6ba4e66e110b8dca44a076f49d4fba4614540341f4013159eab5e69 A.3.3.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 54] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: a5f0d2f22f3e404976ca7b1b ciphertext: 1e9233f2b21834f72bc2b23173b107770d97092d1fc57960aaf0d011b1bb 8f1767d6ff8cb3b5bdb857168260ee sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: a5f0d2f22f3e404976ca7b1a ciphertext: e870727eec0872dfc176e3d48e894a6fd23c560b2f7c097febd70cf81971 0e8a0c30adfe0a1d740b5e42d09325 sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: a5f0d2f22f3e404976ca7b19 ciphertext: 1b28bcf1c88146063ca68a999bee8b6d339bf9ec9ce1b22aad255abf96b7 951f0d14db39d2a7042402d2ff3b41 sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: a5f0d2f22f3e404976ca7b1f ciphertext: 10ec221a706669d206e4fdaffe72adadf4c98286728aa58b91ffea203517 9ecf97677723a814464d6c0e3220f5 A.3.4. AuthPSK Setup Information Barnes, et al. Expires 31 January 2021 [Page 55] Internet-Draft HPKE July 2020 mode: 3 kem_id: 16 kdf_id: 1 aead_id: 1 info: 4f6465206f6e2061204772656369616e2055726e seedE: ac7928bd504449496e56517f59ad30ba62575c3c328864340247d73217823bb3 seedR: 85c7ca573ca20cffc0db7748f2b93a1faaa951aaedace61a6cc0b15755cf7cdb seedS: adfa10a0be028fec577fc0d8da73b3af3f6c8d96976ac3664b1a191c8ef0506c psk: 5db3b80a81cb63ca59470c83414ef70a psk_id: 456e6e796e20447572696e206172616e204d6f726961 enc: 0435ea0b3e1693ee6c10ab35b0d6a01d9c6879be1ca8676cc2fd16e94b622368b41 25f4528deeb1d32dbb0a9b815341ee6dc723e00dfad789a46abc337c0cb2d74 shared_secret: acabc837f0148300e7264c7bfc597ce119a5a77c51eb091fb943573cafa69ce2 key_schedule_context: 038c27d3410cb79f908302ae06a67ad4c6f971cc37f64c2380 7cb4de4adeaa7d76a633c96fae27707d2cfedac544e900a8b52a016cf86e4bf25a7d350f be847f8d secret: dbbb9e2244449b76d56b48a7c8257f8b03e9a5948fc382528ad4f8464f3b8ee9 key: 51ad48b07edc1bc355bbd8ba1288f90d nonce: fa9f85cd9f4e97cc5655eeee exporter_secret: 25fa7177ee5c4686f095fc5c51d2ce5c5871a6d1210c3e345fe4ba2fc8febbdf A.3.4.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 56] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: fa9f85cd9f4e97cc5655eeee ciphertext: bab2fad2725ecde8486e17afb2ea44d908c023f80ee2592273e8ca7a2536 7c946d318f3bf241038f9ebd0267b3 sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: fa9f85cd9f4e97cc5655eeef ciphertext: 63270c658fe7f960837760b763d487ba9b663643a3843399328aa90d06a1 9046e76b6e5a23460dec758b41a03c sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: fa9f85cd9f4e97cc5655eeec ciphertext: 9ee05381c12b4ac0d6fdddfb0efaf7ebe126474af24785af7ead4730b338 2155a7924996410f42905b05a7a3de sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: fa9f85cd9f4e97cc5655eeea ciphertext: 971ba4154f709dcd45fd46b3a7cf53cfaa34ffcf8758c7bc6beea9e91b57 25cd611356da09dff633517c9284d2 A.4. DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, ChaCha20Poly1305 A.4.1. Base Setup Information Barnes, et al. Expires 31 January 2021 [Page 57] Internet-Draft HPKE July 2020 mode: 0 kem_id: 16 kdf_id: 1 aead_id: 3 info: 4f6465206f6e2061204772656369616e2055726e seedE: fcdcc1cd73bf5cc87b991ca1f7b2f4f0ec2aac20e105efcb7111177a150af48c seedR: 483bb0a0fe639035e3909be5c43af275da1cc8a0f355385fc4c7af211fbcad60 enc: 042eba2b8c1fa16ee99ab9f4627aee2358f71d6240955e5747ab869b5531a43ddab 8dec00e9fbdfb2f92073774a9981f72312ff6361b551bb254295fffea04de02 shared_secret: 23df0808be6ebbef5822349e5dae008d2c1e9f4020367097bde447ed5fcf383e key_schedule_context: 005193809f9701d761ad3e980ec406cc14ea789817d821d0cb 139989260f37f4c6d3da0100c16489caa7ad5adf41151b806e7a2a438b79586881afdfaf 8bc6fedd secret: e0001a90ebb7efc5e85e1f72c90ea2e98b14c0431379789250bd2acda2a95208 key: 652abfcff470224fec73d73cef7c424401cb4d72d92ff5a8447a865c19830535 nonce: 07e632ae808cddf6acaeb15b exporter_secret: f3a31ef376affde7513fa5989ffadf6e32b8c7ee40a71d2c2f890dda77a5dadd A.4.1.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 58] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: 07e632ae808cddf6acaeb15b ciphertext: edcfa837ec3e00787a52b462ac2a3a438a75e8df971fd21fa617998398c3 4ecfb69b4878faaa68c21edc39be2a sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: 07e632ae808cddf6acaeb15a ciphertext: 02dfb0620b7d7835f66dd53b3444742649104532a808aab474b13c311b3d 5dfb99e80f00988b9e70546c369021 sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: 07e632ae808cddf6acaeb159 ciphertext: f42d3def0a450bbf6d15a6950a64c198bd36760a9b53e775bc3e60f9ec38 253597b725181e6d3b5feaa0ad80ef sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: 07e632ae808cddf6acaeb15f ciphertext: 03769cf4d9e13994376ee35afd627b9f7d1f495ae2d1d3538c4c803e9c08 aa13cf9ae7ec545c0f17b28d6b1cba A.4.2. PSK Setup Information Barnes, et al. Expires 31 January 2021 [Page 59] Internet-Draft HPKE July 2020 mode: 1 kem_id: 16 kdf_id: 1 aead_id: 3 info: 4f6465206f6e2061204772656369616e2055726e seedE: d5f77ccc5d8a284a97f6c9c72fa5cba1daff07cb177770796733129a39de0c14 seedR: 4ac36e24812130586b5326c046de98d3186124dedc8fa6afe6bb1181540bd0f7 psk: 5db3b80a81cb63ca59470c83414ef70a psk_id: 456e6e796e20447572696e206172616e204d6f726961 enc: 04f6ddb4c4f41ec4c1577e34519fb3a5b8d659945d425b4b117e02636841c4287fa 34bab4c35a5d41d788a8c321b8256cd71c93ff4a8799ed28301114196f9f6a6 shared_secret: c6ab3fe04a92b975f5fd98a09db71063814b03ba86a69da3004e3a0dda8bbc40 key_schedule_context: 017d40471421306b100f7401fbf733fef208e1508bd2744517 e95ef7471f21a1dad3da0100c16489caa7ad5adf41151b806e7a2a438b79586881afdfaf 8bc6fedd secret: 6ab05d9bade32456ac456527e164651f1e7b90a22cec55cd32878dd4770271bc key: abc5af188ea872c94cafd11dbdb7836cc1930ca0271833ba2a36a04d54404912 nonce: 4724facf9d0af1c7a55a0560 exporter_secret: 38e87692f83d991b20e731e1a29fa86bb92630824de1df6aeaf04fd4d59778e9 A.4.2.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 60] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: 4724facf9d0af1c7a55a0560 ciphertext: 6972d38453567d2624db55ad748d42ff3177d1e941bbe57f68d03b53fb0f 1d48b6fc2dfcb84d8ef39f3a8ad6c5 sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: 4724facf9d0af1c7a55a0561 ciphertext: 6ff2faf2ec58ddd27c3a97a25a1d1b3db45484f2bb1c84c751f58c03d660 cee4b942a10bac339044bd65157c65 sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: 4724facf9d0af1c7a55a0562 ciphertext: e2203b51c7d776ed347168dd7d93066184bb7e775277dea7f95bcc3e897c edd52fdcea492158116a8354387f85 sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: 4724facf9d0af1c7a55a0564 ciphertext: c953c3657872749b048d8245ef98cf33a2f7e4c62f27d9b9e3496fdf50b9 51e63031092466f4bc67fb93bcee82 A.4.3. Auth Setup Information Barnes, et al. Expires 31 January 2021 [Page 61] Internet-Draft HPKE July 2020 mode: 2 kem_id: 16 kdf_id: 1 aead_id: 3 info: 4f6465206f6e2061204772656369616e2055726e seedE: 336770111a4f3e97ddd1592a15e4734b910b9a5b566e846cd8f28c6199f8c5e7 seedR: df66678a95aaf77b4a3ec2635b23b181dd3d8a05c68022cb6d5d71b119c1535d seedS: 01bbe1ed07b0688a97d888880ca203b9ac5ebf298f4a5a081e1fa46dbb6e183f enc: 044b364b95db5fadf0617c48688eed541aab99ddf72a5357ae371c34df7803fcd0d a422f17ce4c68d03fef7c6ab272041230a3901361445644c2a6c3d02e9532c5 shared_secret: f7b6fa8884784f6723692603cd958db6830cb0c87718f72cdff10758cb97a3ab key_schedule_context: 025193809f9701d761ad3e980ec406cc14ea789817d821d0cb 139989260f37f4c6d3da0100c16489caa7ad5adf41151b806e7a2a438b79586881afdfaf 8bc6fedd secret: 53be166abcfea99cf7bbe7c20e3704bccee414244cebed9dd5a2bc9f3ffe1600 key: 807c3ed1b3fdfa8ffb052e01e2f60e75aa9f47ed8378c17ad737e58f32954888 nonce: 7c84b0a76e3bff59f55eeb66 exporter_secret: ad0c4d9ecace4d473c702f15f83c14964abc8340d560fb103a8ed9e96d30477a A.4.3.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 62] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: 7c84b0a76e3bff59f55eeb66 ciphertext: b626e15a016a4d1141404694d4f42300324839c26442761558aff3f11bea d5af3102ca3eaa3d9ebe7d61b5e9ad sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: 7c84b0a76e3bff59f55eeb67 ciphertext: 9a71859d14fc01dd756e9c5ae3bd17f30276f60702913ed52d9bdd1f984d d3c1f8d8da0e3cf80d7948322e5272 sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: 7c84b0a76e3bff59f55eeb64 ciphertext: 56e9a11b272337128786b69cbf4969d92bfa91ff642c76815c3ed4169d87 08d1736466d5ba124de3de05e274ed sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: 7c84b0a76e3bff59f55eeb62 ciphertext: 47c2b0dd4cc2a0cdb9ece76eca03d71556f33554f52800adc208c1c954a5 0035d3a0c442ad07e5a4a0af2d3987 A.4.4. AuthPSK Setup Information Barnes, et al. Expires 31 January 2021 [Page 63] Internet-Draft HPKE July 2020 mode: 3 kem_id: 16 kdf_id: 1 aead_id: 3 info: 4f6465206f6e2061204772656369616e2055726e seedE: 7454e819f88659590461a91dff451738df7789f5b4ced005211ed7b264be713f seedR: 5f587a548f7cba21c98ac0dfdac619e962aba8526339c7ad98e804abd9fcbf19 seedS: 1093c27b5e2719ffade39714b76a8e994341b019de9522d89133b41a200f97da psk: 5db3b80a81cb63ca59470c83414ef70a psk_id: 456e6e796e20447572696e206172616e204d6f726961 enc: 042b8f991a7f0e1a833f58ce65bf65c96780e9620ae3ab6e8df1645b54b70ed89ad bc9c2db9f4b6a0c7c08a76523f24ccbd555da8cdd0403e5f1aaf3f68e0dc62d shared_secret: ae88d508550ecc1804706bf7ef31c329cd2475f20b3ce3082207dc7c806121d5 key_schedule_context: 037d40471421306b100f7401fbf733fef208e1508bd2744517 e95ef7471f21a1dad3da0100c16489caa7ad5adf41151b806e7a2a438b79586881afdfaf 8bc6fedd secret: 35a0d70ef7522b31c1d534e268a6d5139b0943b598e61c1c81f8d21633f459cf key: 2fc299bf7d673aa547d3cb9972a7976bc262508c52a1a84c617e0f0b6bca3c39 nonce: 4af68b1b2cd29814fc8020d5 exporter_secret: 6370cd9058b498d3db6cce9beb618b094ff0981b846d5cf59676cd7e5e41dd3b A.4.4.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 64] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: 4af68b1b2cd29814fc8020d5 ciphertext: 694ad6fefd198fece3706b5fd6fb696ed03f399f3bdfabaec36b52fa6315 3db22a50978c6b0329a6c583a7380b sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: 4af68b1b2cd29814fc8020d4 ciphertext: b0f4eeb0f9ef54c9f5dbc1b16dec408dc4160e255e768b00cc21aec6c5fb 65b29835131275ce081ff80e9f05ff sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: 4af68b1b2cd29814fc8020d7 ciphertext: 7d72a1eaeb27669fe6fa123a6c4bebecfe9fc035c8b0b2402ccab99dd92c 4047c9953a537fb1e647b9e8d49e0f sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: 4af68b1b2cd29814fc8020d1 ciphertext: b55b04cb0cfa1911bf1c4cef46fdafeb2352de13cdb25e254d4b611ae59c b2342208ccd645e4be0f6d02a34125 A.5. DHKEM(P-521, HKDF-SHA512), HKDF-SHA512, AES-256-GCM A.5.1. Base Setup Information Barnes, et al. Expires 31 January 2021 [Page 65] Internet-Draft HPKE July 2020 mode: 0 kem_id: 18 kdf_id: 3 aead_id: 2 info: 4f6465206f6e2061204772656369616e2055726e seedE: 1ed3768f499b5b3c2beda3166528b649d4b117a0bd450f0e9e19815c2597d1777 ac67ea367415fb28c8819c94b383a0a8a15c9f03b4835330e3e6c8bc8319202e473 seedR: 62641514bccd2858f3d6513305288d6ca0e443f00a86eb33ccd519d1803aebc5d 07bbad0e1013ce61d9c9d713b3c90c8e79a1af01d6c69750f67cbbd1d9d4afeedfa enc: 04000fe222a93e988f2b890bf98345fdd3c08724631091dfbd8c3572a91e2fc8bd8 78f1537852bffdaaf55e168cfa4511445c390a705bf322ded61f4bf7e5a9f69248101acb 73eb821bf6c757ab35286af062fa59f614e319c7eb62a1423c84c86eba1ae8d65280fd69 916ff758825e2944c2df3242b3f6b110da559bf20919431cab76cfa shared_secret: 836dec8ee53432fe6135a364858d61a256848874d645c286d454411ee fde448bc7654cf506bf1e4ab3dd43f5d9baeb05b24e2ee6b3591b5136432ff747c71722 key_schedule_context: 005c0b2bdbbffbea1af82c95fa5560defe4ba0a05fd3c301cd fab3bbc2fba9783d13d14ecba2cdc7a7c1f544087eb5b3a22ca199e34879b2bbeab3d644 cb2a005dd8854451600d718851b126f132b5ea0cf6942b64e7e586a7f8877bbcc281c8f6 c005e9d1c201fa65882d2162ed577741da4aed5c33fa050d83feb94a4e88638c secret: 71529ceee3d8881f66363e99cd1bade88b2ea7b8c19363fc0e093bb92b961c31 d61e9147aeed52bc81be1e4f5ce18bb758a97dc54030e63ce37d3a92860328d6 key: 80358d48c8324176a44632f90c826a6bbfe7b2126f9ee47eca65f58faee8946f nonce: 7502fc65d8e5db6fd14285c5 exporter_secret: d876060f03e1ba934c3e3c93416e91888b0a02614f8c5a27d24f311 2754c4d654bbc04fd54c1aa052c5dd81358362ecea1c15e20c9cebaa5393e52da73d4f61 1 A.5.1.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 66] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: 7502fc65d8e5db6fd14285c5 ciphertext: ba38cbcd619868b4e993b7757cf8449aeab47d07741a62ec8b3fa72c136b 7e5f6c11ee2faceea367f4126181ca sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: 7502fc65d8e5db6fd14285c4 ciphertext: a97932db8c889e85e844b1b8fc75fb3a21e25569bcfacc74ce47287eb35b 59372f0e6c1762446674aec9469774 sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: 7502fc65d8e5db6fd14285c7 ciphertext: dffe364d097f06751044647b5b992a834414c0d629b25f9db8e0bde6687e 26f73cd7f77078bd9d677a4e3555ed sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: 7502fc65d8e5db6fd14285c1 ciphertext: e48c2e05ec38338e78a2ed2473a6052006f474957d9ff98ff26c07d51418 bda9bebb572b6a46bdb8367a65595c A.5.2. PSK Setup Information Barnes, et al. Expires 31 January 2021 [Page 67] Internet-Draft HPKE July 2020 mode: 1 kem_id: 18 kdf_id: 3 aead_id: 2 info: 4f6465206f6e2061204772656369616e2055726e seedE: 64463def238f309f1e9d1f28c15dc126cffa4ded911a4c527eeb71ba593847fb4 05756239d2c694ce4effa3996cafb5cc0b3736dd988deb7289210ec92bf6b339302 seedR: 41b782c18c14986c9d7a636152f13677aeddf479c1c7791ea46e0ebbe35ca9dd5 24c23d730eef443741d7d965415833d6c549c8c1b31ad05f2b9a88f916b2930528e psk: 5db3b80a81cb63ca59470c83414ef70a psk_id: 456e6e796e20447572696e206172616e204d6f726961 enc: 040041d3923b7218cf378f7336712e2ab1d254a2e7b0e67b85ccd149f68115e9d1e d4492f5542923586feecf2e5500be432e181e73bbcf87947914ba760ab1216e62f80067e 0e0899fbc87ffcf0b2e7556f4bac9395aa3e284f73323c87ab3e5bb8409e2b85ed657170 aacad0d83cd8ea71dee1b480634f818383d75899c877d3fa263fe49 shared_secret: 8fb618ff94fca65c1bb2183b5683bbefd0aefe66d1610e0d1623c8b3d 00c2fb5feba21b1050d7752ad1f0b52250624881902f3d5156b4b3c454aaee2b2b20a89 key_schedule_context: 017344e204124da2a856fc5693999bbfd1242c27f4b2f16fdc 92751d458fbb606adde7aecc32db4dd5b0fdbea7655c7c0e8363da1a34370ba59bfdb421 08a4bebbd8854451600d718851b126f132b5ea0cf6942b64e7e586a7f8877bbcc281c8f6 c005e9d1c201fa65882d2162ed577741da4aed5c33fa050d83feb94a4e88638c secret: edfc1907ed7d5006b7e821f9802b49192ebd40dad26bb9ebc20192bfc4e6319f 22dd9950d51fe7c07c48739ff424509b056acf2a2acb655b59999626b91741b8 key: 6fb2ffb368d1d76a743b9e51d8293d0960810936399fb51dcffe83ddf14c6271 nonce: ba6d3b6c7435583230a60d86 exporter_secret: 1926473db83cdccbfc308c0a286b0e248c2d2cda275c6c511f50d64 768d483229f24f770271cdb01096bdcb15c8269ef5e80e592998fb43c93ea3b8c0e1e46d 2 A.5.2.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 68] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: ba6d3b6c7435583230a60d86 ciphertext: 264cd2ede05a9ab1527a01508fd537afe67b6c6f89d5a09e9e28bb3e0a52 c61a174f9ae71681f548ec44b38ccd sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: ba6d3b6c7435583230a60d87 ciphertext: 4b439bc9afa3ce832cbda50c31b549fcab63a7ffd040907e1fdc5200e01d 5d0ba4b4349eda9c135d4b1a39da7d sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: ba6d3b6c7435583230a60d84 ciphertext: b8bf1321fa9d670cd0fea9c59ca8a88583f793a27633a8ab5b026e3309b7 861d98c1546ee4205621da2d5899c0 sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: ba6d3b6c7435583230a60d82 ciphertext: 84a1574168983ccb5b52a5e0b522f04cf5283bd6e818e0f4c3b165e179ad 899e34f8675aea5b905605f10cfb15 A.5.3. Auth Setup Information Barnes, et al. Expires 31 January 2021 [Page 69] Internet-Draft HPKE July 2020 mode: 2 kem_id: 18 kdf_id: 3 aead_id: 2 info: 4f6465206f6e2061204772656369616e2055726e seedE: 81dc51e31ef8e9b33fefcdf00bd3b0ff585b941fe76cf39a86c269e2f53be7edb 3db0be1a58b6cb8d8e6020fe8a2018c59d47cacb35b2b8c61bd4155438b5eda5c0d seedR: 54af23ea93c8fc34deb6a7cd70e657ea8990fc4e9a18656d5764b62f7a33a9e02 12adeae1585ad2ef28688c1b558866c1975973c4dff08955c1f9fd7939b10b5fbfc seedS: b65599d814192278ab826ef197a61b77db50f40495f77502dfaa03acd1f3565a3 cefebd59de2328ece0638c90d8a89f9ca58f2850e39e9a4c9c339290d66da12fdf0 enc: 0400c708757d53d8a1ac555426d660014fefab2676fcebf62d7589339f24a0f632e 51da9e1b13631f461a48753b756c3322032cc27b32cea63cfefadba56952d7ae35c0166b 63cc1e329938a33728a2ef6fce3372589da2b9bcc80ae007dee3e084b1656349f1514590 5689ef920807ff239f94891b22057385c7b97ea517b1ab21bf5fec8 shared_secret: 7258e75f7c2a8ded295523a7b99c1045925dca1628a91bdca9a2e1bdc c187eee3b627f2ab6a73853c8dcb13a95d0980585c21c25cf92b7c9d945430dfc47e690 key_schedule_context: 025c0b2bdbbffbea1af82c95fa5560defe4ba0a05fd3c301cd fab3bbc2fba9783d13d14ecba2cdc7a7c1f544087eb5b3a22ca199e34879b2bbeab3d644 cb2a005dd8854451600d718851b126f132b5ea0cf6942b64e7e586a7f8877bbcc281c8f6 c005e9d1c201fa65882d2162ed577741da4aed5c33fa050d83feb94a4e88638c secret: dc6a1631b3fbc9d6b6b856d60738cefe1743cfc14d1ae0627b38386b9abc9b2f 86dde080bb6b9d7c3eb579d6bf599765cb4a5e27cd134703acc06142901164c9 key: eedfdbacc250f004a9a4027184a95388f9ebf86ce9593c81921da9eef5d9f6e9 nonce: 8c1fb99aa9cca28b2a1ac3ec exporter_secret: 1f64d525bc6f36488c46c0650b6f0c10a887e0e300737a2c167e4ff d1b4d91193750fcf26173f0c8924f6a86b01fac3f6753d4e9f91abd92b042ae3218d7f45 e A.5.3.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 70] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: 8c1fb99aa9cca28b2a1ac3ec ciphertext: 1f4da6829a7336ec414ffeebec31807dd1acb2ec248b165b5d29732dd005 7fa76be483b9af01437b32ebe6c061 sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: 8c1fb99aa9cca28b2a1ac3ed ciphertext: 168714b29e7f1c3a91dffdb6cc576b7be34ef929b7ccd598435c4ef1af52 c5d7ddbe43f51ac50b27bbf9ce0e73 sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: 8c1fb99aa9cca28b2a1ac3ee ciphertext: 639d9f6c9ca75d91fff8d4a9b0608d10db800fe6a1ed208a09fb907f70a3 27c61414a20e4910a54f12f2ada7a6 sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: 8c1fb99aa9cca28b2a1ac3e8 ciphertext: e325abd75e86991abc1ba269fef64c5ccb3a5c1636f4c8e026205ad45470 cae1771d9a5c87a3a21af1d6b89cc0 A.5.4. AuthPSK Setup Information Barnes, et al. Expires 31 January 2021 [Page 71] Internet-Draft HPKE July 2020 mode: 3 kem_id: 18 kdf_id: 3 aead_id: 2 info: 4f6465206f6e2061204772656369616e2055726e seedE: dc1fda9b21a1af6925ecf9ad79d2422f698b4168587c7908b36f5f58352181b95 06554d8d8c9427e0dd2cfda25f0eabf58e9f5597e1b76ac12c799fe96e3cc03dc59 seedR: 46592c2b171b8cdcce89601fab103f63ed43badadcf9df62a928ae3b7fa91f269 eff3485f6401c374e19a8bb988005626b9c26d39795282b1095bcc4f62a67255e15 seedS: d02446c344c10cd162486caa69aa1156ac3066e0fd668fa7faaf13bdbc944edbc 0cd68ee36e4c30ecc36c2c5ab0978473eb1b5dcfff27985c9328877e85fd48b657d psk: 5db3b80a81cb63ca59470c83414ef70a psk_id: 456e6e796e20447572696e206172616e204d6f726961 enc: 04007abb917b25112c8bf9a75233c90e0f55a4b6cd4f52a9f8a8856e85f82bbd84a c0d1941f01aab2c7846e6b562c0f5168727f4443acb84249f357d591f7bef8651d2019e0 f9ef53c20a74f6cc9e6080e792877201ec7d4fb5fa22e184d1d848314811a3d110112172 bc802805ef7405dc0fac4f5f401865f0410c05d172524a71039963e shared_secret: 82913b51b3809a9177ab90ca628e661126d8b64ca95739f6172b93ff5 11ccc0b7b6255dd9bc17d692b598acd10c1a3b86fb242554824f06df693f75c5d2935d6 key_schedule_context: 037344e204124da2a856fc5693999bbfd1242c27f4b2f16fdc 92751d458fbb606adde7aecc32db4dd5b0fdbea7655c7c0e8363da1a34370ba59bfdb421 08a4bebbd8854451600d718851b126f132b5ea0cf6942b64e7e586a7f8877bbcc281c8f6 c005e9d1c201fa65882d2162ed577741da4aed5c33fa050d83feb94a4e88638c secret: fd3c39728bad99fcb7c2430841690994f624a2bcfaba38affe3596b651bae01c cd0b7b1c9fbf10de0fddb9ec06bfc9dfcd0c1fcdb2cbfee6e27e4a653bc24344 key: 7262c38cfa0c8f468160fb1530579d53c433559a58bc1acf1facf5231bdbc7cf nonce: 65560e6c300fd5a0a7dba420 exporter_secret: 58a7173f251e03619d615542539e40c9bf480f96efd026216211062 96dbff95aff003971cafb9265d92ba3d7fbf67283c40364f7def04cd4d6429c015172e76 e A.5.4.1. Encryptions Barnes, et al. Expires 31 January 2021 [Page 72] Internet-Draft HPKE July 2020 sequence number: 0 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d30 nonce: 65560e6c300fd5a0a7dba420 ciphertext: e0d4d9b38eb8b8dc1f2c986005a83b7df5bde76d48c95dd59bd60456639a 82feb3ea3205b6fce5e672fad9c73d sequence number: 1 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d31 nonce: 65560e6c300fd5a0a7dba421 ciphertext: a905aa5e9c23600c8bdd8c45b2bdd3352727175c565d4d60b7e4d7083b10 fe26afde4ccdab36726e6e0c26d78f sequence number: 2 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d32 nonce: 65560e6c300fd5a0a7dba422 ciphertext: f8d5733f3b2e850176ae68f998268125662161b4edf86752a80b70ec0376 2dcbb8508c495852fc313cbca8e065 sequence number: 4 plaintext: 4265617574792069732074727574682c20747275746820626561757479 aad: 436f756e742d34 nonce: 65560e6c300fd5a0a7dba424 ciphertext: 644ce2fe731274c00b455a25e7a733032dd2916d25a4a39d28a89f3f5282 b12b20afde48860ea31f187c4c4ecd Authors' Addresses Richard L. Barnes Cisco Email: rlb@ipv.sx Karthik Bhargavan Inria Email: karthikeyan.bhargavan@inria.fr Benjamin Lipp Inria Email: ietf@benjaminlipp.de Barnes, et al. Expires 31 January 2021 [Page 73] Internet-Draft HPKE July 2020 Christopher A. Wood Cloudflare Email: caw@heapingbits.net Barnes, et al. Expires 31 January 2021 [Page 74]