[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-barnes-cfrg-hpke) 00 01 02 05

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<MODE>(pkR, info, aad, pt, ...):
     enc, ctx = Setup<MODE>S(pkR, info, ...)
     ct = ctx.Seal(aad, pt)
     return enc, ct

   def Open<MODE>(enc, skR, info, aad, ct, ...):
     ctx = Setup<MODE>R(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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <https://www.rfc-editor.org/info/rfc5116>.

   [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,
              <https://www.rfc-editor.org/info/rfc8017>.






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,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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, <https://doi.org/10.1007/bfb0024447>.

   [BNT19]    Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
              AEAD Revisited", 2019,
              <http://dx.doi.org/10.1007/978-3-030-26948-7_9>.

   [CS01]     Cramer, R. and V. Shoup, "Design and Analysis of Practical
              Public-Key Encryption Schemes Secure against Adaptive
              Chosen Ciphertext Attack", 2001,
              <https://eprint.iacr.org/2001/108>.

   [fiveG]    "Security architecture and procedures for 5G System",
              2019,
              <https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3169>.

   [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,
              <https://link.springer.com/content/
              pdf/10.1007/3-540-44586-2_8.pdf>.

   [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,
              <https://doi.org/10.6028/nist.sp.800-38d>.






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,
              <https://eprint.iacr.org/2013/382>.

   [HPKEAnalysis]
              Lipp, B., "An Analysis of Hybrid Public Key Encryption",
              2020, <https://eprint.iacr.org/2020/243.pdf>.

   [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, <http://www.ietf.org/
              internet-drafts/draft-ietf-mls-protocol-09.txt>.

   [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, <http://www.ietf.org/
              internet-drafts/draft-ietf-tls-esni-07.txt>.

   [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,
              <https://doi.org/10.1007%2F3-540-49677-7_30>.

   [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,
              <https://doi.org/10.6028/nist.sp.800-56ar3>.

   [MAEA10]   Gayoso Martinez, V., Hernandez Alvarez, F., Hernandez
              Encinas, L., and C. Sanchez Avila, "A Comparison of the
              Standardized Versions of ECIES", 2010,
              <https://ieeexplore.ieee.org/abstract/document/5604194/>.



Barnes, et al.           Expires 31 January 2021               [Page 33]


Internet-Draft                    HPKE                         July 2020


   [NaCl]     "Public-key authenticated encryption: crypto_box", 2019,
              <https://nacl.cr.yp.to/box.html>.

   [NISTCurves]
              "Digital Signature Standard (DSS)",
              DOI 10.6028/nist.fips.186-4, National Institute of
              Standards and Technology report, July 2013,
              <https://doi.org/10.6028/nist.fips.186-4>.

   [RFC1113]  Linn, J., "Privacy enhancement for Internet electronic
              mail: Part I - message encipherment and authentication
              procedures", RFC 1113, DOI 10.17487/RFC1113, August 1989,
              <https://www.rfc-editor.org/info/rfc1113>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.

   [RFC6637]  Jivsov, A., "Elliptic Curve Cryptography (ECC) in
              OpenPGP", RFC 6637, DOI 10.17487/RFC6637, June 2012,
              <https://www.rfc-editor.org/info/rfc6637>.

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

   [RFC8439]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
              Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
              <https://www.rfc-editor.org/info/rfc8439>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [S01]      Shoup, V., "A proposal for an ISO standard for public key
              encryption (version 2.1)", 2001,
              <https://eprint.iacr.org/2001/112>.

   [SECG]     "Elliptic Curve Cryptography, Standards for Efficient
              Cryptography Group, ver. 2", 2009,
              <https://secg.org/sec1-v2.pdf>.

   [TestVectors]
              "HPKE Test Vectors", 2020, <https://github.com/cfrg/draft-
              irtf-cfrg-
              hpke/blob/580119bb7bb45fd09a1079b920f8ef257f901309/test-
              vectors.json>.



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,
              <https://doi.org/10.1007/bf00124891>.

   [WireGuard]
              Donenfeld, J.A., "WireGuard: Next Generation Kernel
              Network Tunnel", 2020,
              <https://www.wireguard.com/papers/wireguard.pdf>.

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/