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

Versions: (draft-barnes-cfrg-hpke) 00 01 02 03 04 05 06 07

Network Working Group                                        R.L. Barnes
Internet-Draft                                                     Cisco
Intended status: Informational                              K. Bhargavan
Expires: 26 April 2021                                           B. Lipp
                                                                   Inria
                                                               C.A. Wood
                                                              Cloudflare
                                                         23 October 2020


                      Hybrid Public Key Encryption
                        draft-irtf-cfrg-hpke-06

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 26 April 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Barnes, et al.            Expires 26 April 2021                 [Page 1]


Internet-Draft                    HPKE                      October 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  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   4
   3.  Notation  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Cryptographic Dependencies  . . . . . . . . . . . . . . . . .   5
     4.1.  DH-Based KEM  . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Hybrid Public Key Encryption  . . . . . . . . . . . . . . . .  10
     5.1.  Creating the Encryption Context . . . . . . . . . . . . .  12
       5.1.1.  Encryption to a Public Key  . . . . . . . . . . . . .  14
       5.1.2.  Authentication using a Pre-Shared Key . . . . . . . .  15
       5.1.3.  Authentication using an Asymmetric Key  . . . . . . .  15
       5.1.4.  Authentication using both a PSK and an Asymmetric
               Key . . . . . . . . . . . . . . . . . . . . . . . . .  16
     5.2.  Encryption and Decryption . . . . . . . . . . . . . . . .  17
     5.3.  Secret Export . . . . . . . . . . . . . . . . . . . . . .  18
   6.  Single-Shot APIs  . . . . . . . . . . . . . . . . . . . . . .  19
     6.1.  Encryption and Decryption . . . . . . . . . . . . . . . .  19
     6.2.  Secret Export . . . . . . . . . . . . . . . . . . . . . .  19
   7.  Algorithm Identifiers . . . . . . . . . . . . . . . . . . . .  20
     7.1.  Key Encapsulation Mechanisms (KEMs) . . . . . . . . . . .  20
       7.1.1.  SerializePublicKey and DeserializePublicKey . . . . .  21
       7.1.2.  SerializePrivateKey and DeserializePrivateKey . . . .  21
       7.1.3.  DeriveKeyPair . . . . . . . . . . . . . . . . . . . .  21
       7.1.4.  Validation of Inputs and Outputs  . . . . . . . . . .  23
       7.1.5.  Future KEMs . . . . . . . . . . . . . . . . . . . . .  23
     7.2.  Key Derivation Functions (KDFs) . . . . . . . . . . . . .  23
       7.2.1.  Input Length Restrictions . . . . . . . . . . . . . .  24
     7.3.  Authenticated Encryption with Associated Data (AEAD)
           Functions . . . . . . . . . . . . . . . . . . . . . . . .  25
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
     8.1.  Security Properties . . . . . . . . . . . . . . . . . . .  25
       8.1.1.  Key-Compromise Impersonation  . . . . . . . . . . . .  26
       8.1.2.  Computational Analysis  . . . . . . . . . . . . . . .  27
       8.1.3.  Post-Quantum Security . . . . . . . . . . . . . . . .  29
     8.2.  Security Requirements on a KEM used within HPKE . . . . .  29
       8.2.1.  Encap/Decap Interface . . . . . . . . . . . . . . . .  29
       8.2.2.  AuthEncap/AuthDecap Interface . . . . . . . . . . . .  30
     8.3.  Security Requirements on a KDF  . . . . . . . . . . . . .  30



Barnes, et al.            Expires 26 April 2021                 [Page 2]


Internet-Draft                    HPKE                      October 2020


     8.4.  Pre-Shared Key Recommendations  . . . . . . . . . . . . .  30
     8.5.  Domain Separation . . . . . . . . . . . . . . . . . . . .  31
     8.6.  External Requirements / Non-Goals . . . . . . . . . . . .  32
     8.7.  Metadata Protection . . . . . . . . . . . . . . . . . . .  32
   9.  Message Encoding  . . . . . . . . . . . . . . . . . . . . . .  33
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  33
     10.1.  KEM Identifiers  . . . . . . . . . . . . . . . . . . . .  33
     10.2.  KDF Identifiers  . . . . . . . . . . . . . . . . . . . .  34
     10.3.  AEAD Identifiers . . . . . . . . . . . . . . . . . . . .  34
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  35
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  35
     12.2.  Informative References . . . . . . . . . . . . . . . . .  35
   Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .  39
     A.1.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-128-GCM  . .  39
       A.1.1.  Base Setup Information  . . . . . . . . . . . . . . .  39
       A.1.2.  PSK Setup Information . . . . . . . . . . . . . . . .  40
       A.1.3.  Auth Setup Information  . . . . . . . . . . . . . . .  42
       A.1.4.  AuthPSK Setup Information . . . . . . . . . . . . . .  44
     A.2.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256,
           ChaCha20Poly1305  . . . . . . . . . . . . . . . . . . . .  46
       A.2.1.  Base Setup Information  . . . . . . . . . . . . . . .  46
       A.2.2.  PSK Setup Information . . . . . . . . . . . . . . . .  48
       A.2.3.  Auth Setup Information  . . . . . . . . . . . . . . .  50
       A.2.4.  AuthPSK Setup Information . . . . . . . . . . . . . .  52
     A.3.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, AES-128-GCM . . .  54
       A.3.1.  Base Setup Information  . . . . . . . . . . . . . . .  54
       A.3.2.  PSK Setup Information . . . . . . . . . . . . . . . .  56
       A.3.3.  Auth Setup Information  . . . . . . . . . . . . . . .  58
       A.3.4.  AuthPSK Setup Information . . . . . . . . . . . . . .  60
     A.4.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA512, AES-128-GCM . . .  62
       A.4.1.  Base Setup Information  . . . . . . . . . . . . . . .  62
       A.4.2.  PSK Setup Information . . . . . . . . . . . . . . . .  64
       A.4.3.  Auth Setup Information  . . . . . . . . . . . . . . .  66
       A.4.4.  AuthPSK Setup Information . . . . . . . . . . . . . .  68
     A.5.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA256,
           ChaCha20Poly1305  . . . . . . . . . . . . . . . . . . . .  70
       A.5.1.  Base Setup Information  . . . . . . . . . . . . . . .  70
       A.5.2.  PSK Setup Information . . . . . . . . . . . . . . . .  72
       A.5.3.  Auth Setup Information  . . . . . . . . . . . . . . .  74
       A.5.4.  AuthPSK Setup Information . . . . . . . . . . . . . .  76
     A.6.  DHKEM(P-521, HKDF-SHA512), HKDF-SHA512, AES-256-GCM . . .  78
       A.6.1.  Base Setup Information  . . . . . . . . . . . . . . .  78
       A.6.2.  PSK Setup Information . . . . . . . . . . . . . . . .  80
       A.6.3.  Auth Setup Information  . . . . . . . . . . . . . . .  82
       A.6.4.  AuthPSK Setup Information . . . . . . . . . . . . . .  84
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  86




Barnes, et al.            Expires 26 April 2021                 [Page 3]


Internet-Draft                    HPKE                      October 2020


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
   type of public key encryption has many applications in practice,
   including Messaging Layer Security [I-D.ietf-mls-protocol] and TLS
   Encrypted ClientHello [I-D.ietf-tls-esni].

   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 [IEEE1363], 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],
   [ABHKLR20].  A summary of these analyses 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.



Barnes, et al.            Expires 26 April 2021                 [Page 4]


Internet-Draft                    HPKE                      October 2020


   *  "pk(skX)": The KEM public key corresponding to the KEM private key
      "skX".

   *  Sender (S): Role of entity which sends an encrypted message.

   *  Recipient (R): Role of entity which receives an encrypted message.

   *  Ephemeral (E): Role of a fresh random value meant for one-time
      use.

   *  I2OSP and OS2IP: Convert a byte string to and from a non-negative
      integer as described in [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()": Randomized algorithm to generate a key
         pair "(skX, pkX)"

      -  "DeriveKeyPair(ikm)": Deterministic algorithm to derive a key
         pair "(skX, pkX)" from the byte string "ikm", where "ikm"
         SHOULD have at least "Nsk" bytes of entropy (see Section 7.1.3
         for discussion)

      -  "SerializePublicKey(pkX)": Produce a byte string of length
         "Npk" encoding the public key "pkX".

      -  "Encap(pk)": Randomized algorithm to generate an ephemeral,
         fixed-length symmetric key (the KEM shared secret) and a fixed-
         length encapsulation of that key that can be decapsulated by
         the holder of the private key corresponding to "pk".







Barnes, et al.            Expires 26 April 2021                 [Page 5]


Internet-Draft                    HPKE                      October 2020


      -  "Decap(enc, sk)": Deterministic algorithm using the private key
         "sk" to recover the ephemeral symmetric key (the KEM shared
         secret) from its encapsulated representation "enc".  This
         function can raise an "DecapError" on decapsulation failure.

      -  "AuthEncap(pkR, skS)" (optional): Same as "Encap()", and the
         outputs encode an assurance that the KEM shared secret was
         generated by the holder of the private key "skS".

      -  "AuthDecap(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".  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".  This function can
         raise an "OpenError" or "NonceOverflowError" upon failure.




Barnes, et al.            Expires 26 April 2021                 [Page 6]


Internet-Draft                    HPKE                      October 2020


      -  "Nk": The length in bytes of a key for this algorithm

      -  "Nn": The length in bytes of a nonce for this algorithm

   Beyond the above, a KEM MAY also expose the following functions,
   whose behavior is detailed in Section 7.1.2:

   *  "SerializePrivateKey(sk)": Produce a byte string of length "Nsk"
      encoding the private key "sk"

   *  "DeserializePrivateKey(enc)": Parse a byte string of length "Nsk"
      to recover a private key.  This function can raise a
      "DeserializeError" error upon "enc" deserialization failure.

   A _ciphersuite_ is a triple (KEM, KDF, AEAD) containing a choice of
   algorithm for each primitive.

   A set of algorithm identifiers for concrete instantiations of these
   primitives is provided in Section 7.  Algorithm identifier values are
   two bytes long.

   Note that "GenerateKeyPair" can be implemented as
   "DeriveKeyPair(random(Nsk))".

   The notation "pk(skX)", depending on its use and the KEM and its
   implementation, is either the computation of the public key using the
   private key, or just syntax expressing the retrieval of the public
   key assuming it is stored along with the private key object.

   The following two functions are defined to facilitate domain
   separation of KDF calls as well as context binding:

  def LabeledExtract(salt, label, ikm):
    labeled_ikm = concat("HPKE-06", suite_id, label, ikm)
    return Extract(salt, labeled_ikm)

  def LabeledExpand(prk, label, info, L):
    labeled_info = concat(I2OSP(L, 2), "HPKE-06", suite_id, label, info)
    return Expand(prk, labeled_info, L)

   [[RFC editor: please change "HPKE-06" to "RFCXXXX", where XXXX is the
   final number, before publication.]]









Barnes, et al.            Expires 26 April 2021                 [Page 7]


Internet-Draft                    HPKE                      October 2020


   The value of "suite_id" depends on where the KDF is used; it is
   assumed implicit from the implementation and not passed as a
   parameter.  If used inside a KEM algorithm, "suite_id" MUST start
   with "KEM" and identify this KEM algorithm; if used in the remainder
   of HPKE, it MUST start with "HPKE" and identify the entire
   ciphersuite in use.  See sections 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()": Randomized algorithm to generate a key pair
      "(skX, pkX)" for the DH group in use

   *  "DeriveKeyPair(ikm)": Deterministic algorithm to derive a key pair
      "(skX, pkX)" from the byte string "ikm", where "ikm" SHOULD have
      at least "Nsk" bytes of entropy (see Section 7.1.3 for discussion)

   *  "DH(skX, pkY)": Perform a non-interactive DH exchange using the
      private key "skX" and public key "pkY" to produce a Diffie-Hellman
      shared secret of length "Ndh".  This function can raise a
      "ValidationError" as described in Section 7.1.4.

   *  "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.  This function can raise a "DeserializeError" error
      upon "enc" deserialization failure.

   *  "Ndh": The length in bytes of a Diffie-Hellman shared secret
      produced by "DH()"

   *  "Nsk": The length in bytes of a Diffie-Hellman private key

   Since an encapsulated key is a Diffie-Hellman public key in this KEM
   algorithm, we use "Serialize()" to encode them, and "Npk" equals
   "Nenc".  The same applies to "Deserialize()".

   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.3 contains the "DeriveKeyPair" function specification for
   DHKEMs defined in this document.




Barnes, et al.            Expires 26 April 2021                 [Page 8]


Internet-Draft                    HPKE                      October 2020


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)
  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



Barnes, et al.            Expires 26 April 2021                 [Page 9]


Internet-Draft                    HPKE                      October 2020


   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
   "Nsecret" of the KEM shared secret is equal to the output length of
   the hash function underlying the KDF.  For P-256, P-384 and P-521,
   the size "Ndh" of the Diffie-Hellman shared secret is equal to 32,
   48, and 66, respectively, corresponding to the x-coordinate of the
   resulting elliptic curve point [IEEE1363].  For X25519 and X448, the
   size "Ndh" of is equal to 32 and 56, respectively (see [RFC7748],
   Section 5).

   It is important to note that the "AuthEncap()" and "AuthDecap()"
   functions of the DHKEM variants defined in this document are
   vulnerable to key-compromise impersonation (KCI).  This means the
   assurance that the KEM shared secret was generated by the holder of
   the private key "skS" does not hold if the recipient private key
   "skR" is compromised.  See Section 8.1 for more details.

   Senders and recipients MUST validate KEM inputs and outputs as
   described in Section 7.1.

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 "skR" 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



Barnes, et al.            Expires 26 April 2021                [Page 10]


Internet-Draft                    HPKE                      October 2020


   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.

   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.  See Section 7.1.5 for more details.



Barnes, et al.            Expires 26 April 2021                [Page 11]


Internet-Draft                    HPKE                      October 2020


   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.

   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", "base_nonce", and "exporter_secret" computed by the key
   schedule have the property that they are only known to the holder of
   the recipient private key, and the entity that used the KEM to
   generate "shared_secret" and "enc".











Barnes, et al.            Expires 26 April 2021                [Page 12]


Internet-Draft                    HPKE                      October 2020


   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 26 April 2021                [Page 13]


Internet-Draft                    HPKE                      October 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)

  secret = LabeledExtract(shared_secret, "secret", psk)

  key = LabeledExpand(secret, "key", key_schedule_context, Nk)
  base_nonce = LabeledExpand(secret, "base_nonce", key_schedule_context, Nn)
  exporter_secret = LabeledExpand(secret, "exp", key_schedule_context, Nh)

  return Context(key, base_nonce, 0, exporter_secret)

   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;

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.




Barnes, et al.            Expires 26 April 2021                [Page 14]


Internet-Draft                    HPKE                      October 2020


   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 MUST have at least 32 bytes of entropy and SHOULD be of
   length "Nh" bytes or longer.  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)

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



Barnes, et al.            Expires 26 April 2021                [Page 15]


Internet-Draft                    HPKE                      October 2020


   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 identifier.  If an application wishes to bind HPKE ciphertexts
   or exported secrets to another identity for the sender (e.g., an
   email address or domain name), then this identifier should be
   included in the "info" parameter to avoid identity mis-binding issues
   [IMB].

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.

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 MUST have at least 32 bytes of entropy and SHOULD be of
   length "Nh" bytes or longer.  See Section 8.4 for a more detailed
   discussion.





Barnes, et al.            Expires 26 April 2021                [Page 16]


Internet-Draft                    HPKE                      October 2020


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

   *  A secret "key"

   *  A base nonce "base_nonce"

   *  A sequence number (initially 0)

   The Secret Export parameters consist of:

   *  The HPKE ciphersuite in use

   *  An "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 "base_nonce" with the current sequence number, encoded as a
   big-endian integer of the same length as "base_nonce".
   Implementations MAY use a sequence number that is shorter than the
   nonce length (padding on the left with zero), but MUST raise an error
   if the sequence number overflows.

   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.






Barnes, et al.            Expires 26 April 2021                [Page 17]


Internet-Draft                    HPKE                      October 2020


   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.base_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 an interface for exporting secrets from the encryption
   "Context" using a variable-length PRF, similar to the TLS 1.3
   exporter interface (see [RFC8446], Section 7.5).  This interface
   takes as input a context string "exporter_context" and a desired
   length "L" in bytes, and produces a secret derived from the internal
   exporter secret using the corresponding KDF Expand function.  For the
   KDFs defined in this specification, "L" has a maximum value of
   "255*Nh".  Future specifications 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.




Barnes, et al.            Expires 26 April 2021                [Page 18]


Internet-Draft                    HPKE                      October 2020


def Context.Export(exporter_context, L):
  return LabeledExpand(self.exporter_secret, "sec", exporter_context, L)

6.  Single-Shot APIs

6.1.  Encryption and Decryption

   In many cases, applications encrypt only a single message to a
   recipient's public key.  This section provides templates for HPKE
   APIs that implement stateless "single-shot" encryption and decryption
   using APIs specified in 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)

6.2.  Secret Export

   Applications may also want to derive a secret known only to a given
   recipient.  This section provides templates for HPKE APIs that
   implement stateless "single-shot" secret export using APIs specified
   in Section 5.3:










Barnes, et al.            Expires 26 April 2021                [Page 19]


Internet-Draft                    HPKE                      October 2020


   def SendExport<MODE>(pkR, info, exporter_context, L, ...):
     enc, ctx = Setup<MODE>S(pkR, info, ...)
     exported = ctx.Export(exporter_context, L)
     return enc, exported

   def ReceiveExport<MODE>(enc, skR, info, exporter_context, L, ...):
     ctx = Setup<MODE>R(enc, skR, info, ...)
     return ctx.Export(exporter_context, L)

   As in Section 6.1, the "MODE" template parameter is one of Base, PSK,
   Auth, or AuthPSK.  The optional parameters indicated by "..." depend
   on "MODE" and may be empty.

7.  Algorithm Identifiers

7.1.  Key Encapsulation Mechanisms (KEMs)

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

                                  Table 2

   The "Auth" column indicates if the KEM algorithm provides the
   "AuthEncap()"/"AuthDecap()" interface.  The meaning of all other
   columns is explained in Section 10.1.








Barnes, et al.            Expires 26 April 2021                [Page 20]


Internet-Draft                    HPKE                      October 2020


7.1.1.  SerializePublicKey and DeserializePublicKey

   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.4 for specifics.

7.1.2.  SerializePrivateKey and DeserializePrivateKey

   For P-256, P-384 and P-521, the "SerializePrivateKey()" function of
   the KEM performs the Field-Element-to-Octet-String conversion
   according to [SECG].  If the private key is an integer outside the
   range "[0, order-1]", where "order" is the order of the curve being
   used, the private key MUST be reduced to its representative in "[0,
   order-1]" before being serialized.  "DeserializePrivateKey()"
   performs the Octet-String-to-Field-Element conversion according to
   [SECG].

   For X25519 and X448, private keys are identical to their byte string
   representation, so little processing has to be done.  The
   "SerializePrivateKey()" function MUST clamp its output and
   "DeserializePrivateKey()" MUST clamp its input, where _clamping_
   refers to the bitwise operations performed on "k" in the
   "decodeScalar25519()" and "decodeScalar448()" functions defined in
   section 5 of [RFC7748].

   To catch invalid keys early on, implementors of DHKEMs SHOULD check
   that deserialized private keys are not equivalent to 0 (mod "order"),
   where "order" is the order of the DH group.

7.1.3.  DeriveKeyPair

   The keys that "DeriveKeyPair()" produces have only as much entropy as
   the provided input keying material.  For a given KEM, the "ikm"
   parameter given to "DeriveKeyPair()" SHOULD have length at least
   "Nsk", and SHOULD have at least "Nsk" bytes of entropy.

   All invocations of KDF functions (such as "LabeledExtract" or
   "LabeledExpand") in any DHKEM's "DeriveKeyPair()" function use the
   DHKEM's associated KDF (as opposed to the ciphersuite's KDF).




Barnes, et al.            Expires 26 April 2021                [Page 21]


Internet-Draft                    HPKE                      October 2020


   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))

   "order" is the order of the curve being used (see section D.1.2 of
   [NISTCurves]), and is listed below for completeness.

   P-256:
   0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551

   P-384:
   0xffffffffffffffffffffffffffffffffffffffffffffffffc7634d81f4372ddf
     581a0db248b0a77aecec196accc52973

   P-521:
   0x01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
     fa51868783bf2f966b7fcc0148f709a5d03bb5c9b8899c47aebb6fb71e91386409

   "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))









Barnes, et al.            Expires 26 April 2021                [Page 22]


Internet-Draft                    HPKE                      October 2020


7.1.4.  Validation of Inputs and Outputs

   The following public keys are subject to validation if the group
   requires public key validation: the sender MUST validate the
   recipient's public key "pkR"; the recipient MUST validate the
   ephemeral public key "pkE"; in authenticated modes, the recipient
   MUST validate the sender's static public key "pkS".

   For P-256, P-384 and P-521, senders and recipients MUST perform
   partial public-key validation on all public key inputs, as defined in
   section 5.6.2.3.4 of [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.1.5.  Future KEMs

   Section 8.2 lists security requirements on a KEM used within HPKE.

   The "AuthEncap()" and "AuthDecap()" functions are OPTIONAL.  If a KEM
   algorithm does not provide them, only the Base and PSK modes of HPKE
   are supported.  Future specifications which define new KEMs MUST
   indicate whether or not Auth and AuthPSK modes are supported.

   A KEM algorithm may support different encoding algorithms, with
   different output lengths, for KEM public keys.  Such KEM algorithms
   MUST specify only one encoding algorithm whose output length is
   "Npk".

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] |
                +--------+-------------+-----+-----------+



Barnes, et al.            Expires 26 April 2021                [Page 23]


Internet-Draft                    HPKE                      October 2020


                                 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:

    +==================+==============+===============+===============+
    | Input            | HKDF-SHA256  | HKDF-SHA384   | HKDF-SHA512   |
    +==================+==============+===============+===============+
    | psk              | 2^{61} - 88  | 2^{125} - 152 | 2^{125} - 152 |
    +------------------+--------------+---------------+---------------+
    | psk_id           | 2^{61} - 93  | 2^{125} - 157 | 2^{125} - 157 |
    +------------------+--------------+---------------+---------------+
    | info             | 2^{61} - 91  | 2^{125} - 155 | 2^{125} - 155 |
    +------------------+--------------+---------------+---------------+
    | exporter_context | 2^{61} - 120 | 2^{125} - 200 | 2^{125} - 216 |
    +------------------+--------------+---------------+---------------+

                                  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-06" in bytes and equals 7, "size_suite_id" is the size



Barnes, et al.            Expires 26 April 2021                [Page 24]


Internet-Draft                    HPKE                      October 2020


   of the "suite_id" and equals 10, and "size_input_label" is the size
   of the label used as parameter to "LabeledExtract()" or
   "LabeledExpand()".

   [[RFC editor: please change "HPKE-06" to "RFCXXXX", where XXXX is the
   final number, before publication.]]

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: Confidentiality of the sender's messages against
      chosen ciphertext attacks

   *  Export key secrecy: Indistinguishability of each export secret
      from a uniformly random bitstring of equal length, i.e.,
      "Context.Export" is a variable-length PRF

   *  Sender authentication: Proof of sender origin for PSK, Auth, and
      AuthPSK modes

   These security goals are expected to hold for any honest sender and
   honest recipient keys, as well as if the honest sender and honest
   recipient keys are the same.






Barnes, et al.            Expires 26 April 2021                [Page 25]


Internet-Draft                    HPKE                      October 2020


   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
   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.

8.1.1.  Key-Compromise Impersonation

   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.

   As shown by [ABHKLR20], key-compromise impersonation attacks are
   generally possible on HPKE because KEM ciphertexts are not bound to
   HPKE messages.  An adversary who knows a recipient's private key can
   decapsulate an observed KEM ciphertext, compute the key schedule, and
   encrypt an arbitrary message that the recipient will accept as coming
   from the original sender.  Importantly, this is possible even with a
   KEM that is resistant to key-compromise impersonation attacks.  As a
   result, mitigating this issue requires fundamental changes that are
   out-of-scope of this specification.

   Applications that require resistance against key-compromise
   impersonation SHOULD take extra steps to prevent this attack.  One
   possibility is to produce a digital signature over "(enc, ct)" tuples
   using a sender's private key - where "ct" is an AEAD ciphertext
   produced by the single-shot or multi-shot API, and "enc" the
   corresponding KEM encapsulated key.

   Given these properties, pre-shared keys strengthen both the
   authentication and the secrecy properties in certain adversary
   models.  One particular example in which this can be useful is a
   hybrid quantum setting: if a non-quantum-resistant KEM used with HPKE
   is broken by a quantum computer, the security properties are
   preserved through the use of a pre-shared key.  This assumes that the
   pre-shared key has not been compromised, as described in [WireGuard].



Barnes, et al.            Expires 26 April 2021                [Page 26]


Internet-Draft                    HPKE                      October 2020


8.1.2.  Computational Analysis

   It is shown in [CS01] that a hybrid public-key encryption scheme of
   essentially the same form as the Base mode described here is IND-
   CCA2-secure as long as the underlying KEM and AEAD schemes are IND-
   CCA2-secure.  Moreover, it is shown in [HHK06] that IND-CCA2 security
   of the KEM and the data encapsulation mechanism are necessary
   conditions to achieve IND-CCA2 security for hybrid public-key
   encryption.  The main difference between the scheme proposed in
   [CS01] and the Base mode in this document (both named HPKE) is that
   we interpose some KDF calls between the KEM and the AEAD.  Analyzing
   the HPKE Base mode instantiation in this document therefore requires
   verifying that the additional KDF calls do not cause the IND-CCA2
   property to fail, as well as verifying the additional export key
   secrecy property.

   Analysis of the PSK, Auth, and AuthPSK modes defined in this document
   additionally requires verifying the sender authentication property.
   While the PSK mode just adds supplementary keying material to the key
   schedule, the Auth and AuthPSK modes make use of a non-standard
   authenticated KEM construction.  Generally, the authenticated modes
   of HPKE can be viewed and analyzed as flavors of signcryption
   [SigncryptionDZ10].

   A preliminary computational analysis of all HPKE modes has been done
   in [HPKEAnalysis], indicating asymptotic security for the case where
   the KEM is DHKEM, the AEAD is any IND-CPA and INT-CTXT-secure scheme,
   and the DH group and KDF satisfy the following conditions:

   *  DH group: The gap Diffie-Hellman (GDH) problem is hard in the
      appropriate subgroup [GAP].

   *  "Extract()" and "Expand()" (in DHKEM): "Extract()" can be modeled
      as a random oracle.  "Expand()" can be modeled as a pseudorandom
      function, wherein the first argument is the key.

   *  "Extract()" and "Expand()" (elsewhere): "Extract()" can be modeled
      as a random oracle.  "Expand()" can be modeled as a pseudorandom
      function, wherein the first argument is the key.












Barnes, et al.            Expires 26 April 2021                [Page 27]


Internet-Draft                    HPKE                      October 2020


   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 "y"
   means the given mode satisfies the property.

          +=========+==============+=============+==============+
          | Variant | Message Sec. | Export Sec. | Sender Auth. |
          +=========+==============+=============+==============+
          | Base    |      y       |      y      |     N/A      |
          +---------+--------------+-------------+--------------+
          | PSK     |      y       |      y      |      y       |
          +---------+--------------+-------------+--------------+
          | Auth    |      y       |      y      |      y       |
          +---------+--------------+-------------+--------------+
          | AuthPSK |      y       |      y      |      y       |
          +---------+--------------+-------------+--------------+

                                  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.

   A detailed computational analysis of HPKE's Auth mode single-shot
   encryption API has been done in [ABHKLR20].  The paper defines
   security notions for authenticated KEMs and for authenticated public
   key encryption, using the outsider and insider security terminology
   known from signcryption [SigncryptionDZ10].  The analysis proves that
   DHKEM's "AuthEncap()"/"AuthDecap()" interface fulfills these notions
   for all Diffie-Hellman groups specified in this document, and
   indicates exact security bounds, under the assumption that the gap
   Diffie-Hellman (GDH) problem is hard in the appropriate subgroup
   [GAP], and that HKDF can be modeled as a random oracle.

   Further, [ABHKLR20] proves composition theorems, showing that HPKE's
   Auth mode fulfills the security notions of authenticated public key
   encryption for all KDFs and AEAD schemes specified in this document,
   given any authenticated KEM satisfying the previously defined



Barnes, et al.            Expires 26 April 2021                [Page 28]


Internet-Draft                    HPKE                      October 2020


   security notions for authenticated KEMs.  The assumptions on the KDF
   are that "Extract()" and "Expand()" can be modeled as pseudorandom
   functions wherein the first argument is the key, respectively.  The
   assumption for the AEAD is IND-CPA and IND-CTXT security.

   In summary, the analysis in [ABHKLR20] proves that the single-shot
   encryption API of HPKE's Auth mode satisfies the desired message
   confidentiality and sender authentication properties listed at the
   beginning of this section; it does not consider multiple messages,
   nor the secret export API.

8.1.3.  Post-Quantum Security

   All of [CS01], [HPKEAnalysis], and [ABHKLR20] are premised on
   classical security models and assumptions, and do not consider
   adversaries capable of quantum computation.  A full proof of post-
   quantum security would need to take appropriate security models and
   assumptions into account, in addition to simply using a post-quantum
   KEM.  However, the composition theorems from [ABHKLR20] for HPKE's
   Auth mode only make standard assumptions (i.e., no random oracle
   assumption) that are expected to hold against quantum adversaries
   (although with slightly worse bounds).  Thus, these composition
   theorems, in combination with a post-quantum-secure authenticated
   KEM, guarantee the post-quantum security of HPKE's Auth mode.  In
   future work, the analysis from [ABHKLR20] can be extended to cover
   HPKE's other modes and desired security properties.  The hybrid
   quantum-resistance property described above, which is achieved by
   using the PSK or AuthPSK mode, is not proven in [HPKEAnalysis]
   because this analysis requires the random oracle model; in a quantum
   setting, this model needs adaption to, for example, the quantum
   random oracle model.

8.2.  Security Requirements on a KEM used within HPKE

   A KEM used within HPKE MUST allow HPKE to satisfy its desired
   security properties described in Section 8.1.  In particular, the KEM
   shared secret MUST be a uniformly random byte string of length
   "Nsecret".  This means, for instance, that it would not be sufficient
   if the KEM shared secret is only uniformly random as an element of
   some set prior to its encoding as byte string.

8.2.1.  Encap/Decap Interface

   As mentioned in Section 8, [CS01] provides some indications that if
   the KEM's "Encap()"/"Decap()" interface (which is used in the Base
   and PSK modes), is IND-CCA2-secure, HPKE is able to satisfy its
   desired security properties.  An appropriate definition of IND-
   CCA2-security for KEMs can be found in [CS01] and [BHK09].



Barnes, et al.            Expires 26 April 2021                [Page 29]


Internet-Draft                    HPKE                      October 2020


8.2.2.  AuthEncap/AuthDecap Interface

   The analysis of HPKE's Auth mode single-shot encryption API in
   [ABHKLR20] provides composition theorems that guarantee that HPKE's
   Auth mode achieves its desired security properties if the KEM's
   "AuthEncap()"/"AuthDecap()" interface satisfies multi-user Outsider-
   CCA, Outsider-Auth, and Insider-CCA security as defined in the same
   paper.

   Intuitively, Outsider-CCA security formalizes confidentiality, and
   Outsider-Auth security formalizes authentication of the KEM shared
   secret in case none of the sender or recipient private keys are
   compromised.  Insider-CCA security formalizes confidentiality of the
   KEM shared secret in case the sender private key is known or chosen
   by the adversary.  (If the recipient private key is known or chosen
   by the adversary, confidentiality is trivially broken, because then
   the adversary knows all secrets on the recipient's side).

   An Insider-Auth security notion would formalize authentication of the
   KEM shared secret in case the recipient private key is known or
   chosen by the adversary.  (If the sender private key is known or
   chosen by the adversary, it can create KEM ciphertexts in the name of
   the sender).  Because of the generic attack on an analogous Insider-
   Auth security notion of HPKE described in Section 8.1, a definition
   of Insider-Auth security for KEMs used within HPKE is not useful.

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.

8.4.  Pre-Shared Key Recommendations

   In the PSK and AuthPSK modes, the PSK MUST have at least 32 bytes of
   entropy and SHOULD be of length "Nh" bytes or longer.  Using a PSK
   longer than 32 bytes but shorter than "Nh" bytes is permitted.

   HPKE is specified to use HKDF as 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
   PSK-recovering attacks.  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



Barnes, et al.            Expires 26 April 2021                [Page 30]


Internet-Draft                    HPKE                      October 2020


   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.

   To recover a lower entropy PSK, an attacker in this scenario can
   trivially perform a dictionary attack.  Given a set "S" of possible
   PSK values, the attacker generates an HPKE ciphertext for each value
   in "S", and submits the resulting ciphertexts to the oracle to learn
   which PSK is being used by the receiver.  Further, because HPKE uses
   AEAD schemes that are not key-committing, an attacker can mount a
   partitioning oracle attack [LGR20] which can recover the PSK from a
   set of "S" possible PSK values, with |S| = m*k, in roughly m + log k
   queries to the oracle using ciphertexts of length proportional to k,
   the maximum message length in blocks.  The PSK must therefore be
   chosen with sufficient entropy so that m + log k is prohibitive for
   attackers (e.g., 2^128).

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-06".
   Particular attention needs to be paid if the KEM directly invokes
   functions that are used internally in HPKE's "Extract()" or
   "Expand()", such as "Hash()" and "HMAC()" in the case of HKDF.  It
   MUST be ensured that inputs to these invocations cannot collide with
   inputs to the internal invocations of these functions inside Extract
   or Expand.  In HPKE's "KeySchedule()" this is avoided by using
   "Extract()" instead of "Hash()" on the arbitrary-length inputs "info"
   and "psk_id".

   The string literal "HPKE-06" 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 26 April 2021                [Page 31]


Internet-Draft                    HPKE                      October 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 the
      Base and Auth modes, a given ciphertext can be decrypted if the
      recipient's public encryption key is compromised.  In the PSK and
      AuthPSK modes, a given ciphertext can be decrypted if the
      recipient's public encryption key and the PSK are compromised.

   *  Hiding plaintext length - AEAD ciphertexts produced by HPKE do not
      hide the plaintext length.  Applications requiring this level of
      privacy should use a suitable padding mechanism.  See
      [I-D.ietf-tls-esni] and [RFC8467] for examples of protocol-
      specific padding policies.

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.






Barnes, et al.            Expires 26 April 2021                [Page 32]


Internet-Draft                    HPKE                      October 2020


   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.

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 the recipient public key used for
   encapsulation, which may be needed if a recipient 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

   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 encoded encapsulated key produced
      by the algorithm



Barnes, et al.            Expires 26 April 2021                [Page 33]


Internet-Draft                    HPKE                      October 2020


   *  Npk: The length in bytes of an encoded public key for the
      algorithm

   *  Nsk: The length in bytes of an encoded private key for the
      algorithm

   *  Auth: A boolean indicating if this algorithm provides the
      "AuthEncap()"/"AuthDecap()" interface

   *  Reference: Where this algorithm is defined

   Initial contents: Provided in 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

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




Barnes, et al.            Expires 26 April 2021                [Page 34]


Internet-Draft                    HPKE                      October 2020


   *  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>.

   [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

   [ABHKLR20] Alwen, J., Blanchet, B., Hauck, E., Kiltz, E., Lipp, B.,
              and D. Riepel, "A Formal Analysis of the HPKE Standard",
              2020.

   [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.



Barnes, et al.            Expires 26 April 2021                [Page 35]


Internet-Draft                    HPKE                      October 2020


   [BHK09]    Mihir Bellare, ., Dennis Hofheinz, ., and . Eike Kiltz,
              "Subtleties in the Definition of IND-CCA: When and How
              Should Challenge-Decryption be Disallowed?", 2009,
              <https://eprint.iacr.org/2009/418>.

   [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>.

   [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>.

   [HHK06]    Herranz, J., Hofheinz, D., and E. Kiltz, "Some
              (in)sufficient conditions for secure hybrid encryption",
              2006, <https://eprint.iacr.org/2006/265>.

   [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>.









Barnes, et al.            Expires 26 April 2021                [Page 36]


Internet-Draft                    HPKE                      October 2020


   [I-D.ietf-mls-protocol]
              Barnes, R., Beurdouche, B., Millican, J., Omara, E., Cohn-
              Gordon, K., and R. Robert, "The Messaging Layer Security
              (MLS) Protocol", Work in Progress, Internet-Draft, draft-
              ietf-mls-protocol-09, 6 March 2020, <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-08, 16 October 2020,
              <http://www.ietf.org/internet-drafts/draft-ietf-tls-esni-
              08.txt>.

   [IEEE1363] Institute of Electrical and Electronics Engineers, "IEEE
              1363a, Standard Specifications for Public Key Cryptography
              - Amendment 1 -- Additional Techniques"", 2004.

   [IMB]      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>.

   [ISO]      International Organization for Standardization /
              International Electrotechnical Commission, "ISO/IEC
              18033-2, Information Technology - Security Techniques -
              Encryption Algorithms - Part 2 -- Asymmetric Ciphers",
              2006.

   [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>.

   [LGR20]    Len, J., Grubbs, P., and T. Ristenpart, "Partitioning
              Oracle Attacks".

   [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/>.

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



Barnes, et al.            Expires 26 April 2021                [Page 37]


Internet-Draft                    HPKE                      October 2020


   [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>.

   [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>.

   [RFC8467]  Mayrhofer, A., "Padding Policies for Extension Mechanisms
              for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
              October 2018, <https://www.rfc-editor.org/info/rfc8467>.

   [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>.

   [SigncryptionDZ10]
              "Practical Signcryption", DOI 10.1007/978-3-540-89411-7,
              Information Security and Cryptography, 2010,
              <https://doi.org/10.1007/978-3-540-89411-7>.







Barnes, et al.            Expires 26 April 2021                [Page 38]


Internet-Draft                    HPKE                      October 2020


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

   [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
ikmE: 591c66abd531b9c8287cf76ac053efba38d61e994e7f656c30dab6723a8af9ce
pkEm: b6e788b2785b5db5e76a752f1a4a7b33e58bb7de3744289450c9254049824950
skEm: 683439661e9d9b3c71215a4a82b6821a54a21ddc97d5760e7ba461a56d64b760
ikmR: 8a219e9a42233826f165d2c1036399fa84cfb3bcb93872bc49287dfbe6f1fec9
pkRm: 693e421a7747f0b5cc05716351a9409de672d205f2a178ed70294c7afad22620
skRm: 480e958c0a0a03ab89cd09e2cb5a2232b30447df71b0288b96eb5d59cab13141
enc: b6e788b2785b5db5e76a752f1a4a7b33e58bb7de3744289450c9254049824950
shared_secret:
6817cec017ccc5a25d3a08e7d1fc75eba4b3698a9d827df743d3a243a95a982a
key_schedule_context: 00dd53f4a24da94754dd05f363191d063a9803d098415c2c82
eedfae1e5b44f897b78d74d1e5a553aec6506b75c00b4f71a132eedae22fbf04fb3b2795
48a3a2d4
secret: f71c9e9c65b2eb62ef3dc277865fa2fa837bd064105cfac6451b2df5e3751dc8
key: d9d566f12e8705d7f06f1db28dc83be4
base_nonce: 2b36540d322ad5964a6b9e6f
exporter_secret:
5d9fee94396e086981d8825a019bd6d5582f5d89d47158b2b0d64c26a44a18cc

A.1.1.1.  Encryptions





Barnes, et al.            Expires 26 April 2021                [Page 39]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 2b36540d322ad5964a6b9e6f
ciphertext: 0bfac95d72da4a56168ca0ab8c025ba7f70520260cde4057ce2782007e84
eec9969294d1f2b323a3bf19186a3a

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 2b36540d322ad5964a6b9e6e
ciphertext: 8379e50a176e6afa3ad98ab03898aac824388e6e86f8e1c327485112ba40
7cd6e61414d18e2db7ddc559768920

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 2b36540d322ad5964a6b9e6d
ciphertext: 506bd1b0f7e980d648e4413f8ae06fdd4d25424f401a1984d266c85cfabf
5d9fba80c886e3510af88fb24408c5

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 2b36540d322ad5964a6b9e6b
ciphertext: daa13ffe8668d5e847d77896652495c7461df7fc014d8f80692d8789350e
d2760e531a4388336799ab7c9d0c40

A.1.2.  PSK Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 40]


Internet-Draft                    HPKE                      October 2020


mode: 1
kem_id: 32
kdf_id: 1
aead_id: 1
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: f39542a6e45dc0e6225de671455fea9d918d4fa241c7fb301895a138ce7c2f52
pkEm: 25a22354b1b25393d4e6b11d36750a492ffd9bac7c074f5868d7ead5b6193e5e
skEm: f0d160a3eec4710d1f9308acc9ed44f6eff8a56b05120e334b0287c7888b786d
ikmR: 5aa0335739cb3dbafce48d5d9cccd7d499b0727b445522e1408aba8171aabfae
pkRm: d669cec49c19280cce80833dd810d7257023b40478d8186c88c96e80097c466f
skRm: 68f29eafb4c2455176bf0b5a710eb303b42b0575fbe38538cae7251ab773d953
psk: 0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
psk_id: 456e6e796e20447572696e206172616e204d6f726961
enc: 25a22354b1b25393d4e6b11d36750a492ffd9bac7c074f5868d7ead5b6193e5e
shared_secret:
a4d169695feca7236c56dc07d2a3a43da83edb9a964ac23232b476e14cfb4d8e
key_schedule_context: 019091352b85603e6962c46b744ea932dc3817e8f943688182
965d3b6bcca57426b78d74d1e5a553aec6506b75c00b4f71a132eedae22fbf04fb3b2795
48a3a2d4
secret: 9bb26c08d2a8761b1ad5c696ea46db3c75e8fb63649af2290c87709610893cd2
key: 7905e373fde3715f5a57f0788b9d4bde
base_nonce: 3e9943b0d6714285524bef2e
exporter_secret:
85246513510459fc858b289d4f73c1ad7adab013485ed49066667be0e5e5626c

A.1.2.1.  Encryptions

























Barnes, et al.            Expires 26 April 2021                [Page 41]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 3e9943b0d6714285524bef2e
ciphertext: 03d1ccbf3f8366efdfdcbe10582cf6a62420674a09e2deafebfd4858c1a0
894ef7b823348096ce489d24749835

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 3e9943b0d6714285524bef2f
ciphertext: d0aa46849b996b760d15fb5663f647b42d16f04d9e3e3371585ca398ce4f
2e4a4176030ce03909d05d19a2d233

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 3e9943b0d6714285524bef2c
ciphertext: 42dc3035e77ad0f6cf67a03ea583e1e0598f686251f3899aece75aa0d32a
0ab404fe63214d33092d457ce08bc2

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 3e9943b0d6714285524bef2a
ciphertext: 408b1b7cad15df0cd776c625725ca6bd5940afea57bfe13cefadba741041
9039cd2a503ed1ebfe795e1920483e

A.1.3.  Auth Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 42]


Internet-Draft                    HPKE                      October 2020


mode: 2
kem_id: 32
kdf_id: 1
aead_id: 1
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: 0b119a7a132355f3c2a0ad03e10e252d7292fcde480e726d03a81f127d02c050
pkEm: ffb0bc4d8f0bd23360a7a533c12a4d0410b413da73d0876a1705d1b87487327c
skEm: 20484da5c6f5d8bafdedd689cf8898b76539a3c1db617d7395cdc4f4f2f9cc60
ikmR: 874ba77ded181cd1cb4f2b4f37386a5b2b86c84c57d2a6d1b93a05fb5edd69f0
pkRm: dd7a63455626e5c33a11cbf1e314c7a949b2fb833db635a47e9adcc25f19e829
skRm: 3835d6f979ea2181b97bd15388e2ac8897c1d1405bdbef24a6ab780290ebbd7c
ikmS: 2e369ba803dcee17dba926e4252b8dd9a47417a35bcf90f0e55e4af85c83153b
pkSm: 6aabf1e7b486cd13fdbde77e75ec7a23e15e965b86ef7ac3a91ea9c19f455c16
skSm: 58252076a99dab5f355a48af0d5db3561fb55b9a17d3e13ae512a6ccf8747a57
enc: ffb0bc4d8f0bd23360a7a533c12a4d0410b413da73d0876a1705d1b87487327c
shared_secret:
fdcad7684434cf118756c011c64b2544e71c82aff0175500010916279a7e304b
key_schedule_context: 02dd53f4a24da94754dd05f363191d063a9803d098415c2c82
eedfae1e5b44f897b78d74d1e5a553aec6506b75c00b4f71a132eedae22fbf04fb3b2795
48a3a2d4
secret: 8fb31816f23af1a01a3ce962f576f124128139a62930d7035f27be098d266aa6
key: 9773c94c6625c9a7ee59dab97fd25aa3
base_nonce: 21dcf14262d688b7af24bf69
exporter_secret:
2918046274554b8648f3aae9dd593a744fbbb1182fd2d05dde1655d7041d4600

A.1.3.1.  Encryptions
























Barnes, et al.            Expires 26 April 2021                [Page 43]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 21dcf14262d688b7af24bf69
ciphertext: 15f26bd792dd146838ff1ccb2a5f827a03c7d1c3c5dcc7c36e3afc0b6017
c51196df9c5a778af9ab3cd3896d0e

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 21dcf14262d688b7af24bf68
ciphertext: f2af9f6193010212116bb316d9d96711d82f5cabc75171669fab74349a52
33d6c0855be62f528f2a9e08519ee0

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 21dcf14262d688b7af24bf6b
ciphertext: b0ac5fd0d0e0ec0039e844f6419f0b8db98bb9c04433fa76c25b93067f53
c8e13c3f153e3332ff73fb10d7576d

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 21dcf14262d688b7af24bf6d
ciphertext: 85644b5186bcb0b61083fa402ac7c91f7d6479a75db671bf2013944a3b9a
a9da9c704d87c0f093f000a91ef6bc

A.1.4.  AuthPSK Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 44]


Internet-Draft                    HPKE                      October 2020


mode: 3
kem_id: 32
kdf_id: 1
aead_id: 1
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: 96360b18f7822f85f4a0a1dd200d00ab82ad0032b05a1f34cb120a0cbda4865a
pkEm: add99baa00e7555b74c6ce71aa930164573cd2b1d945af8762239e92a8cd693c
skEm: 20fe5b27f4d868fcaf9fa9d960cabe25d61efd034607e6cc3210f1f0534a7351
ikmR: 48710faa5c8b8b2a4447c9ccf1cc232fb49f6c0fd04b151949757e15b414eea8
pkRm: f0c5f00da33674d2cdb24cfaad4b9532d36a0004523b9760dfea6ddc56a8253e
skRm: 3834553e37a88c94799e3df9f053e8931e39f7033c12f257009303572558436b
ikmS: dd413f8d2d4b195a7cd0793453d04660203a51db65a57d16c2a720e6d44e526c
pkSm: 72a277e700bde918281817e6cf85424886f98220f89365069908e80892b8d30f
skSm: 08b90a0b40fb81f703e6435520586c7da06f2ef477a0378e60b38a4f456a0c7d
psk: 0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
psk_id: 456e6e796e20447572696e206172616e204d6f726961
enc: add99baa00e7555b74c6ce71aa930164573cd2b1d945af8762239e92a8cd693c
shared_secret:
94f5e6dec5754e69001e3a63647832c8403e75e21a94df1acf5f056c60d0b6a6
key_schedule_context: 039091352b85603e6962c46b744ea932dc3817e8f943688182
965d3b6bcca57426b78d74d1e5a553aec6506b75c00b4f71a132eedae22fbf04fb3b2795
48a3a2d4
secret: 6cf00e0589584b1bde61a63765571aeb9f3f0573d01f2e375d59f237cc7b1076
key: fd3320f848f64ee87a2aad0a68be16fb
base_nonce: 3674eb17633d9fefcc4be497
exporter_secret:
ded2df464152869d2a96f7c1f129341a5fb34d77c0fa0baafd9a5bc2c4ab6d6a

A.1.4.1.  Encryptions






















Barnes, et al.            Expires 26 April 2021                [Page 45]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 3674eb17633d9fefcc4be497
ciphertext: 1ae6ea4b0b9ce236fb78828b529894b0a11ae66211dd09d121cf83bec8fb
d9b4a97071660cddad708fcf4720dd

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 3674eb17633d9fefcc4be496
ciphertext: 35340fbe3748e1edcd85e7d7c2a92ebfe12bf5a5f6ee2a71b9d4ad273bdd
d513e1c3dca6b98ad53445c30991da

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 3674eb17633d9fefcc4be495
ciphertext: 86c733b2eea61edfae798704de1a6747e822ee9ff9f1d2e8fff9dda02f0d
45f8cf752b78100fda00d03037cc58

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 3674eb17633d9fefcc4be493
ciphertext: 20622465f93bde3767af03ce76f6b17c00c83ce5f3c6672d60b5447a9c92
5ab73ebd5e28d4c741ba7cc0075e0a

A.2.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, ChaCha20Poly1305

A.2.1.  Base Setup Information




















Barnes, et al.            Expires 26 April 2021                [Page 46]


Internet-Draft                    HPKE                      October 2020


mode: 0
kem_id: 32
kdf_id: 1
aead_id: 3
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: 171f5d09460ed3d1548c1091f2fad8f6e36deb3aac295b74b45bf50259c47e61
pkEm: 037a01fb15f146b69782d3c30a61dc4694de9e5dd9745bc72ee102ab6ee4c966
skEm: f8e47322a562c3cee3696ed61efd8875158ee5f52a81e9a5fbcdb9c72aa11068
ikmR: c560145a2ec58c3ea790bcfafa693968d27480a6349696574a99e076c8a4d33c
pkRm: 3a2ffb89d997a3e4f1599297790bf510690bb2d7634174da71780b2ea399604f
skRm: 10520858737ab92288e16b2bfe62263a6b3b0df57d771ed776359f7cbad4cd59
enc: 037a01fb15f146b69782d3c30a61dc4694de9e5dd9745bc72ee102ab6ee4c966
shared_secret:
4fff33b836fa6614e2c77937c8a3d3af0077fdcc9aee4cafbbc1fa532bd09086
key_schedule_context: 00baa0bb3cdf58aef2e3fd558b9def8ad7f7f902e7a6c83f25
64ca3e9eeb3d26f222e12f3643e2ad9a56477d7c83c86837ec8333a41879b3acfa67bcae
5d3201c2
secret: ecc6b6f848a2d9537671fa1a7497dced0881f2c5b9276cc045fd464b855c31fa
key: ebcce547b7a3a915838978ecc9dff85e6c9e05465a651d5aa277a13bc37cf7df
base_nonce: 0e9fd4c86bf09117672bd6a2
exporter_secret:
267fe045dc8bc12b984bd42fb64acef63f5049e6f1cace163506510896aa5386

A.2.1.1.  Encryptions



























Barnes, et al.            Expires 26 April 2021                [Page 47]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 0e9fd4c86bf09117672bd6a2
ciphertext: 8d58646d36804b70546d4b3e7ae257ffacf53b5b39616d16f980f28b9517
fec1da643665a890563682ef4eb523

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 0e9fd4c86bf09117672bd6a3
ciphertext: 88c1a6dc85ec79ffaa25237ad55a8cdc3684f55b1c5f126f55d9169736e3
194689768ae5e901408ad2a544639d

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 0e9fd4c86bf09117672bd6a0
ciphertext: 6d0bd0f37f6695d5a8471be81e343dcb99391eab3bf44b51662a1bcd7ac3
a2384d3c0e99171b99362ff0353e80

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 0e9fd4c86bf09117672bd6a6
ciphertext: 75f95dc409def5a6edef0813f750af2d512f7f8fe071bbfa360f5345ac68
f663e36eafedb297c37a830997572a

A.2.2.  PSK Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 48]


Internet-Draft                    HPKE                      October 2020


mode: 1
kem_id: 32
kdf_id: 1
aead_id: 3
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: 4065d076fa40dc4b9822f252dfd86aae5fbc6d8a978451fefe2c6adee0a3752a
pkEm: 9406902b7cd89994c943c2ecafb54624bb512d97e03e7a03805a0a7fa2189754
skEm: 30ac0eaae6bc2e74765536e8993a3cd9a54e1b236545bb5f36f7c7348f0ec678
ikmR: 40f8ddc363f09a96dea9ee4e476cf915441ca44476f081f78fc6ae987d6a9308
pkRm: 68487e0ef957249a8aed137964e214dbf8c1905e3b830764e386853fd95d8953
skRm: f81b84854e6f0698474230bcf27a2ebe1d57b2ffa946891de2674194b9a45269
psk: 0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
psk_id: 456e6e796e20447572696e206172616e204d6f726961
enc: 9406902b7cd89994c943c2ecafb54624bb512d97e03e7a03805a0a7fa2189754
shared_secret:
173af1aa50980bd14e6fdb4defecc33cb085c5e6a29e11c86ebf082ccd7ea6fe
key_schedule_context: 018f4d1acd9ce69745cd8822fb9818aa352a419a838cac9822
6401609cc3a5adf122e12f3643e2ad9a56477d7c83c86837ec8333a41879b3acfa67bcae
5d3201c2
secret: c8a5d6f3734607c8d15db2714837aba5e31338ab4b862825f53d67f29552613f
key: 3dfa61a224f96c987e5b81a916389b5a2bdf3f5481443b86f187fad5f6b86cd8
base_nonce: 6a76370e2eece7c0c25e2ffb
exporter_secret:
593cb7bebe571c567078cf3f586ae7445944b2a632d9691da499522bfcb6bedb

A.2.2.1.  Encryptions

























Barnes, et al.            Expires 26 April 2021                [Page 49]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 6a76370e2eece7c0c25e2ffb
ciphertext: 837a5d0d63f409880162eab7152caea3c24667af4c0ca5a084dda82dde40
5ead37dc434be5ed62bdcb08cfdb5e

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 6a76370e2eece7c0c25e2ffa
ciphertext: 909396541bd52a5954c3d5b64b0e7c3c4701f8253e8f0eaaffd231e08275
31da465a5456baaf84bb2be644385c

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 6a76370e2eece7c0c25e2ff9
ciphertext: 5d2c8d7240c712571a8c6edb5800c07d129f5439825c5ef169253d10eafe
3cc703b5995636c8b148bf82281067

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 6a76370e2eece7c0c25e2fff
ciphertext: 34ce9d082c1c4f30d1409f150764e0aee59d08667f838563acb6637dcd87
1964d07af70df9abd0c765e5bf337a

A.2.3.  Auth Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 50]


Internet-Draft                    HPKE                      October 2020


mode: 2
kem_id: 32
kdf_id: 1
aead_id: 3
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: aa8f9c7b6e24761102a42a9f18685fe192eb69f3ebf8b65758c3bef42b822359
pkEm: 9a9c96b3d83c3de361c9461ae569bb31012e1e8e2ab81e522ce596f38a81ba29
skEm: 102f9b349cbb0c2dbb2cd42a25797e7a359e81710c0319013ff6b2e09e199865
ikmR: 6a00b42bcd534a6153319027dda70efd176eed620d999caafcd4f39beb6f1e87
pkRm: b46d13d85802d3c7fefd0c2a1f1e7939d668718a5d6ae78bac3abb00c1de4976
skRm: 80f80262917f46ba62b24bcc3a7463f94b7e45e12513ba00628450a7d6a21053
ikmS: c87864714467e330be58598d7f1ee9ab932d1688e79aaf6897e9a2584adc8fea
pkSm: b096d08110ca33b1fdfc35eafce2506753fe1da69ee4f763a2a1f9e8e96b875a
skSm: 482b16d27c88e1e9f0d2679e0a9b47f1525d6261e0f5c86a2c0f4cebc6a2f763
enc: 9a9c96b3d83c3de361c9461ae569bb31012e1e8e2ab81e522ce596f38a81ba29
shared_secret:
d3500faebbdbf5b74ae5779cb12c49d98e0c5db44c96f9716b016a9026b45e35
key_schedule_context: 02baa0bb3cdf58aef2e3fd558b9def8ad7f7f902e7a6c83f25
64ca3e9eeb3d26f222e12f3643e2ad9a56477d7c83c86837ec8333a41879b3acfa67bcae
5d3201c2
secret: 39abf4d90dfa1516e785efa7babfafb3257dd72905d87d60f9ce8335ce7e6765
key: b36936938c54d636d094bca5fc809ec8e7d591f6b762fb27baed8ef28ad48e85
base_nonce: 918645fde0a5293992a9c968
exporter_secret:
e70079046ea5ce127bd3b7437659f5e9b1d9f7e50adac01499c6901970a3757b

A.2.3.1.  Encryptions
























Barnes, et al.            Expires 26 April 2021                [Page 51]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 918645fde0a5293992a9c968
ciphertext: cb5b9eb59e6710d457cef2476f4ea6b82bf1b056a8dd9abda4698a614f13
4a1a744f2c8d3d9218edd46a9a8db3

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 918645fde0a5293992a9c969
ciphertext: c8fda3c71009031299ee9849456a70b5ba536bcc84ec315e91f8c46477b2
92f58b5e6a8c8879c7e7308b616a8b

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 918645fde0a5293992a9c96a
ciphertext: ff251753238eb6b15ac70350985859d57acd7b34cc67fdbc2cc59fa2f758
3675448a1ed51f2484510dcfaff3ca

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 918645fde0a5293992a9c96c
ciphertext: 488d1d7f782b242ccc56ab7d680e41bdd7438ec4736de9191886247d5d9b
b4708ee84aa870868a35a963596e2b

A.2.4.  AuthPSK Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 52]


Internet-Draft                    HPKE                      October 2020


mode: 3
kem_id: 32
kdf_id: 1
aead_id: 3
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: e35be6682528887e5a1f7d3acae9575c284aa5cd493d1bded9cb30c5a9a67f21
pkEm: 371145b2a0685a13591df34ce3c1f48165d5fe9962f20c4efa7fcbd53569ab4e
skEm: 801f3329585ae52515f1572fcf8a89cd3bad1d122544ab0c89f91d3f221a0f62
ikmR: 9bb89b210547e0bcb1e5f7dba91d6ed88840b14ef87927876d74c52021068dfd
pkRm: 6d14279ab914ab5ada05c829fc787617f52b4d58b6b6608b2c1d047c6e28686f
skRm: d0fdc040c9ba78ee7c63d948f30608af5f6f71100fcf6baa294056e41a04b472
ikmS: 9f499334a0533990c6fbeab4fd5e5c47ba2dbfdfe59cfcbf1241016f835700ae
pkSm: 84437eb7dc9839cbc958c95d0e2cab767023b2ed214d071ff2bcbe845c02a716
skSm: 90607143ab3ec8cd2c4bc7eb98dd4cad56e00e5b38c2148569d169914b61ce42
psk: 0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
psk_id: 456e6e796e20447572696e206172616e204d6f726961
enc: 371145b2a0685a13591df34ce3c1f48165d5fe9962f20c4efa7fcbd53569ab4e
shared_secret:
0e62c9404892833322a864332e3588a093cfd220ba9453efd9724f88d370cf1b
key_schedule_context: 038f4d1acd9ce69745cd8822fb9818aa352a419a838cac9822
6401609cc3a5adf122e12f3643e2ad9a56477d7c83c86837ec8333a41879b3acfa67bcae
5d3201c2
secret: b5f2a31e43d9e62c6f6f9b207e0511cface0833369bb7f4af81c711dd56fc758
key: 16b29df75a13e4f34a11ddfbf4d20c75d66726cfa6c8a5e710ec723e622fd8e4
base_nonce: 2c1b8bc877af10aefa7417a4
exporter_secret:
f0322de06c632ecd6ab6152584e2cc82d9b07a8e8d53bf153fdbd62817226409

A.2.4.1.  Encryptions






















Barnes, et al.            Expires 26 April 2021                [Page 53]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 2c1b8bc877af10aefa7417a4
ciphertext: e30d73a6ce44a7a1868e2175e5c2da951119572e0b203b68e7e441ea0fcc
b78792e6e0fc12d145ec0c7db3078d

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 2c1b8bc877af10aefa7417a5
ciphertext: 5967b1b673d705f7a2dadcac64f41313d0d9565332bf4937d6d2c6b9c87d
aef3ff4ed67190e02654f1ea890dd4

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 2c1b8bc877af10aefa7417a6
ciphertext: bb5f759c15700185b0767dd307580d418fa1761f99b9abc58b5d4065d6da
4697c6c6ff1f3456af61742d2cc27c

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 2c1b8bc877af10aefa7417a0
ciphertext: 9fb9f4f3a21c53b8b0dcc9d68cbc2dbf8a4745dd7c87e7130c07a7b38fbd
de8f33c862df31d19c0f54a4ccd6e8

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

A.3.1.  Base Setup Information




















Barnes, et al.            Expires 26 April 2021                [Page 54]


Internet-Draft                    HPKE                      October 2020


mode: 0
kem_id: 16
kdf_id: 1
aead_id: 1
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: 827f27da166dfeaa8929c92d2a67018a66d7b465a44c168220088d430461bb72
pkEm: 04a01b79a7807750c860610342450d54b5d4d91b8c51b698b37b6fdee6b97fa73d
a344ce28dafd89dc1daa929d1aa76349f6f4bc2bb0782674121a620072eb3b15
skEm: a679400e350e9da1bd1c36de49fc481cc6150e172d5f7aa9e97740b09f16f557
ikmR: 3c991968c9ce6f8e8f0fef41083ab91e9855b368b8714d78aacde3fc74b0fb5e
pkRm: 04a33be520167c96134a03754478b115880f307fcfc7ae9873d6449963e2487b3a
021be50200f71d4fe9c6dc4a2db04451fa8ff8b5840e1263697df8854b1187df
skRm: 31de13900c6f7ca8844239628949b07969cec1968fdc3307e5868d1ae10d7e2d
enc: 04a01b79a7807750c860610342450d54b5d4d91b8c51b698b37b6fdee6b97fa73da
344ce28dafd89dc1daa929d1aa76349f6f4bc2bb0782674121a620072eb3b15
shared_secret:
98ce9c4505de60f00baa68df92dfbcc89ccd1cf2bbfcbabb368a68b9e43b99be
key_schedule_context: 007a447b53a1bab6377f6d0fcd13c880e84b7b6f8c9d48909c
2681378f2dae2f735fb35e69f4b2ad8cb96fdecc61f90a4e3168e52786bc426eada7863d
a4b00f23
secret: 273a04827b269dd8f670ff33e60150bda39af36783b5e2c15e5973bbfc89e20d
key: 0f1d817716a9fcfb3a733d7a9495b5ea
base_nonce: 1b961630d98ed4bfde61a590
exporter_secret:
cec277f90ab42ff8b7e35a10802b5155f112eaf5b97ce19f9986ffccf77aa59e

A.3.1.1.  Encryptions
























Barnes, et al.            Expires 26 April 2021                [Page 55]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 1b961630d98ed4bfde61a590
ciphertext: 6691e12b2ff62ee7afd44b1ffeb5cc90399f0509d153d8c1bd56dec39bc1
df84617a6daf3c1a96dcfa5d6eab5d

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 1b961630d98ed4bfde61a591
ciphertext: 3bcc473facb1803c3b526b61e0cb5158ea0c9148df3a2b86b55e8e494647
20491fd557093f8303d825ead9b864

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 1b961630d98ed4bfde61a592
ciphertext: 32a45576443463950cca04906d2ca90d7271b6cab593a3a76bc5f19447ee
1890c1eb07c3b5419c6a2f3f480851

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 1b961630d98ed4bfde61a594
ciphertext: 03ac6b8b51f5a1897b59115d3b4854e1f044e25942c802531c1766db9552
f6262986eb089bbc171405b4c4cf7b

A.3.2.  PSK Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 56]


Internet-Draft                    HPKE                      October 2020


mode: 1
kem_id: 16
kdf_id: 1
aead_id: 1
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: 38ba9b0034b4b5817a48e331882952b5f73c3e8b3fa8bae22b1350bee31b0b52
pkEm: 04876ee0955ddb4c88a947b63910e9fd0cf6abd978c00f6a22470125364b82f61f
4d9d519f86521ef4122c30117650bb275ddb9a9b61d89aee117c63f51435de31
skEm: b9a314d8e61a93f4b93c7937bddb91ef36389ae09f10aa3aafe50723766f176e
ikmR: e4c2394942c47e25c24a93d4414bfa6c9ddc09c281f922a507acaa3276809f16
pkRm: 04c84a9e3179b21364316447674430bff4592844fcc1b508f3aded9d76bc324f6b
345c74c142e4d2d02c7c9ac3dfcab28f8a819bf105ea0bb917d4d1b4bf10a2da
skRm: 72ce45fe0b20006f839372528265f74e78dafb68f99e129f03c9f16d698005e4
psk: 0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
psk_id: 456e6e796e20447572696e206172616e204d6f726961
enc: 04876ee0955ddb4c88a947b63910e9fd0cf6abd978c00f6a22470125364b82f61f4
d9d519f86521ef4122c30117650bb275ddb9a9b61d89aee117c63f51435de31
shared_secret:
0bf5f8ce9a4b09a833ef37cee530074379950192aee7e1f349109509565357d7
key_schedule_context: 01fb64c721c330b25c0f399265499887256e6888b3316ace66
dd64c5d6b22282cc5fb35e69f4b2ad8cb96fdecc61f90a4e3168e52786bc426eada7863d
a4b00f23
secret: b51c63ae27995b77af27176d91babf25da5478ae3f7e299bc51a9ca6e8e61108
key: 3059b5cdb3be25ad8bcd5d670cfd8923
base_nonce: 5126130bfb1912ee174541d8
exporter_secret:
7f800f9dfbfdab3115997928daae8adc47849de64a329dca5808aad1eb88f9a6

A.3.2.1.  Encryptions






















Barnes, et al.            Expires 26 April 2021                [Page 57]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 5126130bfb1912ee174541d8
ciphertext: bb3993b1ef657c79a662487699a4ae4b50920422016e2f22f237c729be8b
189fbd2fdbd70dbcbd2da3ad5e80c6

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 5126130bfb1912ee174541d9
ciphertext: 0268d6531e9f48440822ab1e7b9584b63fd5d00e6943774f9766f7dff362
daa0755909cd722aa763bf2abcafb4

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 5126130bfb1912ee174541da
ciphertext: dd28d9ea055b12f32b1ad09ee917c3165fcc35ea83331ac0c79e8ad01938
54303ffdc7f3c174799cd1ee0c39f7

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 5126130bfb1912ee174541dc
ciphertext: 6186a02a8e2473fb290087c3356c9664cf53e0e6a41998f4f3a86d47416a
756a2cc8aec6bfbfebceafac88d7ea

A.3.3.  Auth Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 58]


Internet-Draft                    HPKE                      October 2020


mode: 2
kem_id: 16
kdf_id: 1
aead_id: 1
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: b93d334f9b1de8d7e3ca0605fdb8d076a6a5fdaafde8eca7d67da75146413ff5
pkEm: 04d1c3e146ffd21b0798fb01db93a7d0b51b3e99a10a8794599693dba29626221d
548260d2cd01e74b9e73a4a26d1917e738f8d88b4086ee2c07a4ac25357de875
skEm: fb847e4b0f31996758312e37570ec8ba8c0eb4b0125ebd123fd77fab18f7972b
ikmR: f8a5c3a4afac029a42127f00ef607ef69c545eed537b7f0696e3d3a32dbd1b04
pkRm: 04fe92a2804e2a3881aed4a8460b91f17e473b31159f972a92dad286a43545f9c8
3a2c02624cbdcf16fa4a605224269cb59c2e60dd3e83b45c17e0716c824c7a2d
skRm: cd87881c87b05b913b482e18b4a6b4b4ce91c243b8e54cd66f36031ba9f0c197
ikmS: 972ef5a16a6c0d7f4a02d3411c7e15f962c90406820685627bfd1a30c26c92d7
pkSm: 043a47c673deb5133376a269eb24feca51148e34ad22dfbf62811b1851e0174f5c
65f0696268d4d9fb5e5acb616d669164e9658dd07de4ac7a811d6e076672f056
skSm: 17f1dcf868fae53516ebd9d4c20196ba3730db4f1ec9ff64914bf229a67b8393
enc: 04d1c3e146ffd21b0798fb01db93a7d0b51b3e99a10a8794599693dba29626221d5
48260d2cd01e74b9e73a4a26d1917e738f8d88b4086ee2c07a4ac25357de875
shared_secret:
0c3fd84ee365b91ad3df60c287d76603f3aec351fbb1d6e33325654cf4557b5e
key_schedule_context: 027a447b53a1bab6377f6d0fcd13c880e84b7b6f8c9d48909c
2681378f2dae2f735fb35e69f4b2ad8cb96fdecc61f90a4e3168e52786bc426eada7863d
a4b00f23
secret: 61498735aa7a83ed2aef880e240314a1f793d6e847f588b146bd6023e5701de0
key: b3bd2473b024dc462f0599ff8f88f26d
base_nonce: 5c0a4779fc33b33cca08f223
exporter_secret:
12b1f1e6712be78f1a39320356e81ff8dc21ec457c35e4d98aa08af0cc6ee717

A.3.3.1.  Encryptions




















Barnes, et al.            Expires 26 April 2021                [Page 59]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 5c0a4779fc33b33cca08f223
ciphertext: 5d19ca11d7fdc8693ce9ca04832507c912894b0ca156b620fe40e56d4f35
92977ae52cda9b5dfaf7ee348ec0d6

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 5c0a4779fc33b33cca08f222
ciphertext: b5a0b849efbf88e71fa44436cd3b4635bb15de2344e63946ce57daa891e7
475e1f510212939aec220e0a547326

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 5c0a4779fc33b33cca08f221
ciphertext: 450eb2c219c2df213346bb814e2e46f7e1741a8851d26a590080ac08138b
cab203ceed3b1be762a206fbd335d3

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 5c0a4779fc33b33cca08f227
ciphertext: 2143af9290b40fb86537ebb8a7e5bc63548de87396775c0cce707cddc722
ff44e155854d452a808a027f35c269

A.3.4.  AuthPSK Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 60]


Internet-Draft                    HPKE                      October 2020


mode: 3
kem_id: 16
kdf_id: 1
aead_id: 1
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: ab72de85d4f56ece8c99eaf846f1309761726aebdfcc98ee0b2325a0b0e05747
pkEm: 0451c17475f92a0f950a56bf5912798fd7a45ba0048fa04302c2c8013692f31916
5da9d853a2ecd8399d323e0a4d8fbb24c22031442709129c73d9e38194ee19b4
skEm: 55d949c902bb9d9e7a76492bf2f7cd90a1f6414e5d7bcd3d4233f9a9dd2e3d9d
ikmR: b27e63ef5f94a3aed99170485f0c9335b160c8cd56c3b270c11442b0d66cb458
pkRm: 0415df4b0cffe5238d4e5d9a128fd19ef0b1ca9c3a499e250060e4fe186400a8d6
8f5e16fa0ca3635c411e0fb0d7059757b5612d3803c69f96c1c140fe80fa5282
skRm: 8d6c16c0726453a3d8fd5136e9ffe1dc4760efc53ca4d8b5adbcfa496c073223
ikmS: 50750d36da3239c76d4d4ec1129460e5fec239b77d7a0de8094d58da7d4a24eb
pkSm: 046f215a93873508bbe37be23394cc79478fe719b72f4faca3237d67532279c74c
9f1fd2b69a82bbb92af5b3b3af50020d7a199ed7e8c617aee8c78d5f3fdb15bd
skSm: 1ca55b7f8393abf475b1283d68bbae5daac575702da3ecbbd0485902ac93dd30
psk: 0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
psk_id: 456e6e796e20447572696e206172616e204d6f726961
enc: 0451c17475f92a0f950a56bf5912798fd7a45ba0048fa04302c2c8013692f319165
da9d853a2ecd8399d323e0a4d8fbb24c22031442709129c73d9e38194ee19b4
shared_secret:
d5e50b21898311eb7d7cb91e84f08232a105d8cae469ab99a29b8316866762d5
key_schedule_context: 03fb64c721c330b25c0f399265499887256e6888b3316ace66
dd64c5d6b22282cc5fb35e69f4b2ad8cb96fdecc61f90a4e3168e52786bc426eada7863d
a4b00f23
secret: 14af946a81d6e837c1c99892a9fa2f5c829a731f56288c80e88725fbe10da1a6
key: 78a83144b32ef6a55d8e95b6cf608a69
base_nonce: b025809b6d6be90692610c2f
exporter_secret:
4aab5e9c447f32892d0f171dd168b257e0b827da0fcd53543cd1f47649762220

A.3.4.1.  Encryptions


















Barnes, et al.            Expires 26 April 2021                [Page 61]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: b025809b6d6be90692610c2f
ciphertext: 6783ff2f2aadf3bf9b98292323023a5567cc40567b8a209503a5b5968fec
bd64f47d41e5c2737bc53d2dddc51f

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: b025809b6d6be90692610c2e
ciphertext: f907d0e114baf7b49b6e8098eebcf6f3647fcd2760028075eb58d1152db8
824697092bccc2bf4a3b4cda287b19

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: b025809b6d6be90692610c2d
ciphertext: 4fc4a6529045bb7be5bcf7b4e5c56be58dbceae2f7435063388d9cca800e
6329b2182ad2a37fe3cbeaa69519b6

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: b025809b6d6be90692610c2b
ciphertext: e17b1941d52b323912a577da1663a441c0e9a82a8e3333487f85787e3e5b
9cdbfc819a2942f54332fa80d377c6

A.4.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA512, AES-128-GCM

A.4.1.  Base Setup Information




















Barnes, et al.            Expires 26 April 2021                [Page 62]


Internet-Draft                    HPKE                      October 2020


mode: 0
kem_id: 16
kdf_id: 3
aead_id: 1
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: 6a15ae6050f8f3a0aae56777f77633e81181c03f218a212691d3560a455cc5a8
pkEm: 047a1779b86e30662292221d847731c01bc152f1c3ca9816233ca43b78d9d37b1b
286e8cb0fdd6b56e5feed4643937b8054390c70c17e7db87bb5b9fd39bc3ddc1
skEm: 243c0710bfe0505bda854a3e59845c057cef975868313cac1870b7ffa5b50ab6
ikmR: 4aabd6f3276cf14e0ba493e8937306019f2af84b6c079b7cf89a81a4539d0039
pkRm: 04410fa2c036febbe2b60303b4d1eddf24ae346a1ee13fa1c40b73a05f223ee1d3
66329798d7c53d2a25662976d05742effb776df47ebc1333d36a9d3b71f35097
skRm: 70662f22846232d0133a10997d4d83310b4fd4adeca6073dc623b98855a1592e
enc: 047a1779b86e30662292221d847731c01bc152f1c3ca9816233ca43b78d9d37b1b2
86e8cb0fdd6b56e5feed4643937b8054390c70c17e7db87bb5b9fd39bc3ddc1
shared_secret:
c942447bed1dc6ab95b4e140fef92a9388915f55243af081f2a352f79b308f16
key_schedule_context: 00f86054b6a97a160a8eabaf21ac0186ad4fea8e6eb33c984f
efc264eb8f098c90368daa9c96dcc998d12330b913f6c4cdd54cec86cc624a9e8aaf94dd
3bb351b066e461a725080580fc1de13a535af76baea621a8f452cf0e9a638f1011105114
b4db515d224bada4a152dbaad88a1594e11564230c6795a333b19a32d9b5cdef
secret: d7644fbf9daf4a0f1c02c814225ab1c290b4cf4a8e40c03b873bf910060abe63
2647f4b2ae684b325a93bec27a1f36866963d94b1122d1a8dc819cedae28a20c
key: 29ca2d66bbfc6736ace0b1cc015a7669
base_nonce: e34dc7cdc34e655018ee3fca
exporter_secret: 4173b69a1acf63bd5707d66e6252662ae69bd35ba66af3bd2e8e418
2d74b81c54267db3a638020aa92734a5cb4ee654c1d39f99625b9ac2299bc0dfab64902b
8

A.4.1.1.  Encryptions





















Barnes, et al.            Expires 26 April 2021                [Page 63]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: e34dc7cdc34e655018ee3fca
ciphertext: c97691cd3eb5460c7b401327338c51a27607e10dd27943d00e4259c248dc
becf08353d0b07fd00786c33efd3d1

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: e34dc7cdc34e655018ee3fcb
ciphertext: 198266abe509e12c2a47b08bfc90de09d7da4d1566138ff654867e521197
1765e5d7bcf65ae220471abb40903f

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: e34dc7cdc34e655018ee3fc8
ciphertext: 08316cbbaba99533fbffcc287ff0ff2ed1359765f07c49eddb06c29630f3
24cfba6c3b4326f7988c3cd7914e05

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: e34dc7cdc34e655018ee3fce
ciphertext: 8a2adb299ecec60cbe46540ad84638b60cf2d5353634455e89c9d1e75c88
088b7201d042cb34a18bc1e9a55e52

A.4.2.  PSK Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 64]


Internet-Draft                    HPKE                      October 2020


mode: 1
kem_id: 16
kdf_id: 3
aead_id: 1
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: e76eb1beff6bfda05df316cdfdd206984a5647ed4ed66ea74ce66626a115418d
pkEm: 040eed8074afcc38eba0057f3d3c87dd3cb10fc0aa1e80a19cf2b5e4e65da68d1b
6f1d447e5ad4feee1a1a50bdce77c8ff76ce6706db8e798f7aa88856f919d2fb
skEm: c3662b4f5edc906af1e2fdb243d26044b73a33199b3868ecc0be3384ba49b9d1
ikmR: 883e9d3390eaff9fb8fae73953fab565498fd327a6592459763f97b5e50c1516
pkRm: 04f80d0e92e33606bedc68e4b52b2c67661029b3b191f6bb338a7ea533082c8dd7
e4f5bc26876f471759053a5fc34e72e2e9cfff32e053bd056576f4782f7f86c5
skRm: f6d6f2516816708b086b42cf3ce12a693f7abfabb090119be8f93c081dd1e40d
psk: 0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
psk_id: 456e6e796e20447572696e206172616e204d6f726961
enc: 040eed8074afcc38eba0057f3d3c87dd3cb10fc0aa1e80a19cf2b5e4e65da68d1b6
f1d447e5ad4feee1a1a50bdce77c8ff76ce6706db8e798f7aa88856f919d2fb
shared_secret:
3b2c0130c6baa380542b728f576bb8da2850f5529be40d0927be648fac9dcf56
key_schedule_context: 0175285841348a413918874e96b9703074fa763f2bee449918
c13b5bb660b8d21636f88958e593fc9b64692dd669510ca2c96a893e74eef89592b98ccf
fe182e7466e461a725080580fc1de13a535af76baea621a8f452cf0e9a638f1011105114
b4db515d224bada4a152dbaad88a1594e11564230c6795a333b19a32d9b5cdef
secret: 7c0b9aa5173a0d8a9bda91bf7c212cafa73dc47621d1e18a6ada21c9c3307f32
8d3b288802ae9c3d145af13a6587e5045c35c7a8d5c9328900176abcc2bb3df6
key: 0fe5fad216ec3cfac88273d43e537b45
base_nonce: d8bc3ea080233a9700f039cc
exporter_secret: 081e617c3369139d11873a934d7686f029f940e62ff9f6828bfce60
0dae5023e474a32b9fd0c6b0fc2ec11b34cd18d7465ee8a12278a66f953b708618103960
a

A.4.2.1.  Encryptions



















Barnes, et al.            Expires 26 April 2021                [Page 65]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: d8bc3ea080233a9700f039cc
ciphertext: ee640088fefb77872f64a161f798a592ca180f48f10b181f0ca2294aa7dd
db5be141a386f3bb3c13fedcb18957

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: d8bc3ea080233a9700f039cd
ciphertext: f6e268d392edf8185e455b8eaf0874165c27493ad07cd40b54a7a14d2b3d
ba3e763e7dd377ab2aba444c5f0958

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: d8bc3ea080233a9700f039ce
ciphertext: fcc7800b1c68663af3043e8a4a3876b0197f9dd1816d8fb385ded0d39ca0
65a9a2970a7f6879583b784784d29f

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: d8bc3ea080233a9700f039c8
ciphertext: 244506a7408acfa8afbdd3f3c95c7bfa6cc64948cddfa510e0c18a04caac
a4b062f7eba992865cecae15623e4b

A.4.3.  Auth Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 66]


Internet-Draft                    HPKE                      October 2020


mode: 2
kem_id: 16
kdf_id: 3
aead_id: 1
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: a2854b15706ff6b1c184d1134545cd7496d6633ad1bb6bf3b6bfc483be5856b6
pkEm: 04f87bc02d64743b79d6e2c5bd09d9e7ae23dd6ca38889e67977169844e0e34968
6af974bad7f23dbeb45c9c4b2252bb49d02152e9a1ea5508ec313b38c02a7bbb
skEm: cb85703053a329c978e1cb9fbaa1d7c9251e0adfc176093a6f4296d45c92ab27
ikmR: 4a59c85945993002cd16ef7ad651e46018e0db28844a6aef4f3828355b389828
pkRm: 0416358ac8e863e83c4690c690b0bb3ae1dea320446ec1c18badace8882cc08340
50ecfe6ba5da1b6bbc63b47364ebc95108f0412c2c6864f45b9aca4bf3cc28e0
skRm: deffac20a610dd2d1be848f01c6f6303ad9db43f220f331b3dc6bd52411aaa9d
ikmS: a06672f3c860ca33c54e0f8b503ec2e7442fad9cb190c58c9dfa14fd07de3edf
pkSm: 0413abf048f0e39718dd2fd36213596126c905cc0c239ac6847bf3a3b03409993b
c75dcb77c1a1778b8c6570b1a244b4d3f6fb848ceb4d054b7377a69264fccc29
skSm: c21a9dfd394b1a9b4ec3510163245548a3a2ed15c8e6cd6e0d9d39afae8e680b
enc: 04f87bc02d64743b79d6e2c5bd09d9e7ae23dd6ca38889e67977169844e0e349686
af974bad7f23dbeb45c9c4b2252bb49d02152e9a1ea5508ec313b38c02a7bbb
shared_secret:
912178dc1b35e3779a35a5ebdc307f977f999ce9b644d6902586b2857f813169
key_schedule_context: 02f86054b6a97a160a8eabaf21ac0186ad4fea8e6eb33c984f
efc264eb8f098c90368daa9c96dcc998d12330b913f6c4cdd54cec86cc624a9e8aaf94dd
3bb351b066e461a725080580fc1de13a535af76baea621a8f452cf0e9a638f1011105114
b4db515d224bada4a152dbaad88a1594e11564230c6795a333b19a32d9b5cdef
secret: 3a0745583458a11a2c3ae203f991ca7b1fb5119f9736cbb88ffda692d841bf89
77a3cc206582f8554cb971b7a37cda3c3f20f034ebac87e7b7d880aec314423c
key: 0f77225c162f9f56288288af3d59f136
base_nonce: 9b668946816a1d0d6c9d7e0a
exporter_secret: 27a55255900f52b16c21d3d30b5af4e72e12c6d798f450067c31252
eb7c53e22e5013cbe9b5fe00f559ff0f8410c53c7e8094732637f7ae350da39ee9043824
e

A.4.3.1.  Encryptions

















Barnes, et al.            Expires 26 April 2021                [Page 67]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 9b668946816a1d0d6c9d7e0a
ciphertext: e66b7307b8716dc8c140ee07301da61f27b3cc2004c732c43de4871d337f
e47e5b5275e8f60af24e4b2cb55cb6

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 9b668946816a1d0d6c9d7e0b
ciphertext: 3a2009b612a080e6d0debf621a2a0a9552843d9d09387854481a9bb656ad
6eab30662051c308e4339f8fe3ed66

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 9b668946816a1d0d6c9d7e08
ciphertext: 9334ca5ecf7f8fa1e405a562b8615a74789592af762ecbe7d0aa68ad68af
a43e39e6d4ccc5836d13259d5e90d1

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 9b668946816a1d0d6c9d7e0e
ciphertext: 97ba304c7d53dd535b0e0f3874792a0a8d75e3d3858244b965f304ba0e35
c1bf190e0475bc284d47e045796bc6

A.4.4.  AuthPSK Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 68]


Internet-Draft                    HPKE                      October 2020


mode: 3
kem_id: 16
kdf_id: 3
aead_id: 1
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: 6145eeffb6f33b85f251e569175ec958a2df0bada63280e84021b3693b6bec6e
pkEm: 0450a79483be0a777de1d5d6ca60d2a32b351ff99061d360e433ccd023b71640ff
6dd6b40de4b30634cdb22e804d12b0082c22dbba47ca4775cdbceaa78dcef3cb
skEm: 734193928a6d7dd9519f6bc1d6028ec480557e001e9cc0dd7b543bff590e7520
ikmR: 66b2e8f713bdaefae23d0bd3bcf5ac7567873d399cfc5821928e008f981be915
pkRm: 04de9e529271229501a424c3784b40aea872ad36d7b05bf5dbb76851349eadac3f
97a729b1f697f154d3e0a5a53da3ff6bc59fcb6bb543873962fda2b08238ded0
skRm: f60d52bfd936a8aed2fa5790e503bb7f8326537defe8d20978271fdb489d0349
ikmS: 247bfb9453018e7456d0fcea197bfa180f8ed21fb03c50781d4d1ea76c73b41d
pkSm: 04e8e975005ffc567698b3d6d48bf967c7306d5a480ac049589da8bda889235442
8cf88a4ac3188901b976805f34a2b9e250cf1ae0da92ba5c35cc7cdbdabeda37
skSm: 601430726eba46116c821300a638919f5404f30abbe289f08e63e164993ddcc4
psk: 0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
psk_id: 456e6e796e20447572696e206172616e204d6f726961
enc: 0450a79483be0a777de1d5d6ca60d2a32b351ff99061d360e433ccd023b71640ff6
dd6b40de4b30634cdb22e804d12b0082c22dbba47ca4775cdbceaa78dcef3cb
shared_secret:
d4fdfb21883e4ae355689f48e8fbc526e5ea54faae5e339cdd951e391f6852a0
key_schedule_context: 0375285841348a413918874e96b9703074fa763f2bee449918
c13b5bb660b8d21636f88958e593fc9b64692dd669510ca2c96a893e74eef89592b98ccf
fe182e7466e461a725080580fc1de13a535af76baea621a8f452cf0e9a638f1011105114
b4db515d224bada4a152dbaad88a1594e11564230c6795a333b19a32d9b5cdef
secret: 300eece0bb0cb0d39acbaa2d513f918325ed684e8f79213e0f961122d84c2011
20b401fcc8cc1a2f125032b9eacb9939edd1307883dd8b567815108341903932
key: f54a5adc57021b3d66c2687cc3b82fbf
base_nonce: eae87fad2b6a87f488bad689
exporter_secret: 2b8756aab46ffc1b45ebcd31bb555929cea5996181bb0d5a5426cff
af77031923db93501ceae9afedaf800cc3433650654b589634b144cddab69dbbba758f53
6

A.4.4.1.  Encryptions















Barnes, et al.            Expires 26 April 2021                [Page 69]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: eae87fad2b6a87f488bad689
ciphertext: e38dcda1e88fa449b239ff6121a536a7a426e3913a06f0db3045d1f4a9d7
40dd14df928ac643be70cfb6865c37

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: eae87fad2b6a87f488bad688
ciphertext: 8e3dc8f66d5cb3046355971df7bba3ce2ca34b31d468a36054f5ecf359b2
1c044f56d50932187ccc88b1b94802

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: eae87fad2b6a87f488bad68b
ciphertext: 5ebb15688bca07a50c773d52baa5a4ce37a72c22fe472b36fabb8195bc29
a2e96b2f9b4eb0df7a457c258b0551

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: eae87fad2b6a87f488bad68d
ciphertext: 0092f075eecc4088f1ae429d980d5270c28a38447f6a66b66c7d32527e8c
2bb7b9a31049d9a8cbefbd4ace256d

A.5.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, ChaCha20Poly1305

A.5.1.  Base Setup Information




















Barnes, et al.            Expires 26 April 2021                [Page 70]


Internet-Draft                    HPKE                      October 2020


mode: 0
kem_id: 16
kdf_id: 1
aead_id: 3
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: 9df8b42914e9fce352d49c922ddf1fdcd48f81a956ab5acd5ccfbca35f5c0beb
pkEm: 04b8c41a294b8d1da8bd64a9894abb3d579904b86f3aa4da89f4e9563189d93ce8
110c51b3b38ef23b8b9296a596c71ab48947b97d65e4ad545bb4def204ef5c88
skEm: e8b7bae455be2474a579d61eb0d012d0c548c6992a9cdced6c07c503e8fc814f
ikmR: 211e281360f0cdb9c2b5f657619628a0e2e9ef6b246949f165f5ee950f9bc7f8
pkRm: 04b8562b9b63e1ee70c11043c660b1a274a3cfe6c79ab2d53a2f3b416534a0f084
0261ef7e883b80b1a89457de1d98dbcbfde581a1c0536393e387a193e231c6dc
skRm: 7e3f0513ccf1a4b367262b0422472eb3b7675ba6f90d9e14e1f0cea9bb27762b
enc: 04b8c41a294b8d1da8bd64a9894abb3d579904b86f3aa4da89f4e9563189d93ce81
10c51b3b38ef23b8b9296a596c71ab48947b97d65e4ad545bb4def204ef5c88
shared_secret:
e820e9b5996be00574b297c31f211463df6448a5211f62e5949ee149a8a537a6
key_schedule_context: 00712f80079bf04cb297132973d915af2772f9861f8d6324ae
66125ba4ef6ab7e3136812e221b08af3c969408f8cdcda2ce9d7868aad8ef22f6cc26232
c25f331f
secret: 984ea0de48e81f4abab7f991267adba1f23174812d7c224e40f2971e2da5471f
key: e9a081bdfe019f452e5799c23351a83c7fcde509d5a3859a3557c2ffbc1fe191
base_nonce: 29636484614bd5b3f34ae257
exporter_secret:
a6fa6f2f65d731f4256386ffe35ea3c42596c48ee8c77e4f593f1d417469dda8

A.5.1.1.  Encryptions
























Barnes, et al.            Expires 26 April 2021                [Page 71]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 29636484614bd5b3f34ae257
ciphertext: e6d15f7ec405370ace66b7a69c4caa5d662f800b786bff050c5bf0de57be
c09375161f02ba9b5bfddd6d91e64d

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 29636484614bd5b3f34ae256
ciphertext: 69d3716e0a87a05bb09bebee8074301f2d689cf26a6f6937f3ec67222456
a172eff815edf3d7824ba90d3c7143

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 29636484614bd5b3f34ae255
ciphertext: 0facafca02cd1f9d07a3b8e12c5e2971b6b602eca85286a6af34c65e34cc
4a219c6c26a7dc80aa5e5ee47995cb

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 29636484614bd5b3f34ae253
ciphertext: e50bec54ad67e827fd866c86eabe36e63692bbbfb26fbc597acfc38874e9
fb1ce6c7c15189376881cb5955cabb

A.5.2.  PSK Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 72]


Internet-Draft                    HPKE                      October 2020


mode: 1
kem_id: 16
kdf_id: 1
aead_id: 3
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: 7d4bdde35e62157602b7f6647fcc5908d4c7aa568f19d26d3c7e0e6cd1c7f952
pkEm: 0418f0e825f34a05b5b5fa61bb99e2b50b9f3437bcb330e7008e80885b80d918e6
89556d104b18ea186e324044dc3a2012a36ceb6e63d3a4b2db68b8301cea3469
skEm: b55f711a89c4bf35f12a5cc36d3220ad571a928368213e07cd9875adecc56d80
ikmR: 4d8a4eacc6b0fb10dc3ba6a94057caa236f2a85f21dc8c613ff8f01fd8ac4e04
pkRm: 04807b48c94311e802aa56f7b00ae88c0b9a6ec0fc948afcd5bc6e5e0ad41aeb4e
9ef2511bb9a6b7b9e0522dd5868cdb40cc773f030ac2751cfd745cf9baa51357
skRm: 273c67b47a735b25d1bb765f138522bf3cdc6a64f3d39b968e84f2475418b65d
psk: 0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
psk_id: 456e6e796e20447572696e206172616e204d6f726961
enc: 0418f0e825f34a05b5b5fa61bb99e2b50b9f3437bcb330e7008e80885b80d918e68
9556d104b18ea186e324044dc3a2012a36ceb6e63d3a4b2db68b8301cea3469
shared_secret:
6b78677651bececd4e16e50636826de091164be7aee6704f11e7a864ccea85d7
key_schedule_context: 014676a8bd153b28d8133100b9fcdb79438c549578bda55d61
d9d3fbb4747aa127136812e221b08af3c969408f8cdcda2ce9d7868aad8ef22f6cc26232
c25f331f
secret: 12364d5dfe5af7f4bda8ec485163890911408babf0143f151cffce1b27503980
key: 62f430439c16fe9cebf9a70cbdac465531fb9cb81e55d21f7034620457e75257
base_nonce: a387d84007bcf32f061ed0fe
exporter_secret:
1642a15dc9da12df5dde65486b3e6215f3c62db433e44b10237ef1c0452c036d

A.5.2.1.  Encryptions






















Barnes, et al.            Expires 26 April 2021                [Page 73]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: a387d84007bcf32f061ed0fe
ciphertext: 7081dcf888fd5f5f206d663add83bdb12e0d07613dbc2f0bdf25469ba7c5
9955200a88df18f5bb4730b44387c7

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: a387d84007bcf32f061ed0ff
ciphertext: 1689656b247e694c9149f0ade93273e4c5b2820d8d62f6407624de54f259
07053bcda60a0c94e843fd8c8e6362

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: a387d84007bcf32f061ed0fc
ciphertext: 3298ab5522a3630daf242803e95992e7f3e1afa39ac28492351912c9cdac
3e31fdc8f2aa9aa017384fe10877c6

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: a387d84007bcf32f061ed0fa
ciphertext: 733d60bf27e61c298099aafbc0f1c9bbef08fc5ad7ba06d573a7e4ee6d17
6569efa287858bce4beed1d8504239

A.5.3.  Auth Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 74]


Internet-Draft                    HPKE                      October 2020


mode: 2
kem_id: 16
kdf_id: 1
aead_id: 3
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: d1eb88204fbb88b34b9bfd437ed0a3385676cf13e1d16885d26a9271ba9c9100
pkEm: 045626e00728b69683a548289c4ed133d5dbe70f1c9386867c136eafbce30c577c
5be756f768179a75572dc45ab5ff282e0b5d134a926933587e0dee813c06afba
skEm: 47bb319cf209f0c654fd0f8bd4115201681695df00730d11b521977d8efa8c1e
ikmR: 3c9d1ecb8e237ed1ff9338b1137112de3e0ff4e27b4874510e7e74ca4dd92daa
pkRm: 044aefaf297802c7d01062f1a2ff6648035fa70b0b4a9c77f15ef8a6fd9ce987e0
3389c6df8e84ba367cdf0746441286976adf7b49dccd4f25b5adca1d0b256b26
skRm: 6db9c6bc53ac0d62ef958dd40e9af16b202d3d91c238a5e356a4c5e0d327572d
ikmS: 11d4a3df0386a92456d5b16b49e5b74ae674c7b381925762d7a180d3b0fa8df7
pkSm: 0485bd9c999fc20de57ee036f030eca455e2f5d5dbd9271acd500cc675851fa663
e464d02bc47d45ab4656365961eff49dd8c0fd5704324db28fd3e74c761317a0
skSm: 02842413302245517bbb6fae9797092b394b4cabe618a2d1d6c06e67b856d26f
enc: 045626e00728b69683a548289c4ed133d5dbe70f1c9386867c136eafbce30c577c5
be756f768179a75572dc45ab5ff282e0b5d134a926933587e0dee813c06afba
shared_secret:
067f63ce4c4f4746ca0281b7c04fce946da9e070ccefc475d0274a59d169f2f7
key_schedule_context: 02712f80079bf04cb297132973d915af2772f9861f8d6324ae
66125ba4ef6ab7e3136812e221b08af3c969408f8cdcda2ce9d7868aad8ef22f6cc26232
c25f331f
secret: 06e4427df9b7ebc39eb5fe85913ab4130d0a9b1a38ec47c2f91a03507b0fc163
key: e3c3372fe9188723349c2fdd611266291a808b31fcb07bc858f8fbdfdce63cf0
base_nonce: 93f581802e7d3f752e0736f4
exporter_secret:
dfa30f8d46590cb9f706999ece2e76985203e2eeeaef2ac56b1bef05ace34fbb

A.5.3.1.  Encryptions




















Barnes, et al.            Expires 26 April 2021                [Page 75]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 93f581802e7d3f752e0736f4
ciphertext: b36268d0ec687407ff0539e45e1877ae61da0f254c79c14c528b69c587f5
4eedc0739febf28f48d32a822c383c

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 93f581802e7d3f752e0736f5
ciphertext: dbddea82e7da8d040fc1ac2159f55efe7dcf8b173f132055a5990073d801
dabba2971af701cf0d7fee191c7f58

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 93f581802e7d3f752e0736f6
ciphertext: af424c3453b94e5c8107d5d499d494aaa765d0184b05a6f55fe2496cf153
5d87325fb20ad705a9ac1c476a1370

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 93f581802e7d3f752e0736f0
ciphertext: bc08acb8f1a6f75e439f0689d03ac878c0eba2b56799f3fa19b7eeb39ef0
87b8baf4e0da1d854e84f66080a02b

A.5.4.  AuthPSK Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 76]


Internet-Draft                    HPKE                      October 2020


mode: 3
kem_id: 16
kdf_id: 1
aead_id: 3
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: 75422f8364da556a73f8ff16f70ab9b46b9b89089baf7c6897dcd3f040713d57
pkEm: 0413a0da6df148265544f31c634c67f3e12c323dfbc07b2d652159242371e04314
1f323958c852bc10646ca44a4e641b162432aa4193b6b8b93c06d11831568481
skEm: bd91320fd96616044246944d486f03bb44c5b2d46d587cf765654098d73cad38
ikmR: e1b8fed84588b7ecc6bab2dccf2a93508075265de18856b9f0768a3dc1b3fc2b
pkRm: 047ce9f6d438178cd79004a762d794657893fdfac7d66874688763a35299463337
bf85323da8672c3ee276b762e63853a7f3a8a6bc1b07b3a8b0edf804499c94e4
skRm: 1164c40d571ddd9a7492e903a1b0eab01c5d21233d4f0ed6ea2c0f477139a110
ikmS: 557e7fe9f5bcab34814bdc82f61502bbd35fa81595dd610f553bebe032412c93
pkSm: 04363e618990bde7ac3f127dd38289eb9efcc0af2630bcb26f064fc9c9a52686e8
f2b2adc515b26360f15d7d41f552b1ae5635ab4db5ec4aadc5243e250f1e748a
skSm: 46156d3143e7de7866b7bb6aaa098afcac3c14d179dccc77af48ed5d00f9f8be
psk: 0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
psk_id: 456e6e796e20447572696e206172616e204d6f726961
enc: 0413a0da6df148265544f31c634c67f3e12c323dfbc07b2d652159242371e043141
f323958c852bc10646ca44a4e641b162432aa4193b6b8b93c06d11831568481
shared_secret:
80a227197d8a4c87cc7db3bf2d2cce3b37c94d6a2c9222cf442209794df68ee7
key_schedule_context: 034676a8bd153b28d8133100b9fcdb79438c549578bda55d61
d9d3fbb4747aa127136812e221b08af3c969408f8cdcda2ce9d7868aad8ef22f6cc26232
c25f331f
secret: 98aa5ee99d2738c9bff2023f45f8a279be57180fccfe7fa8f820ed32464bb011
key: a0464ab1cb323356b3945c8c90afe6985b1e7eacd36292726edce5d96e17ac33
base_nonce: 8d4cd26358f105692d0ae29e
exporter_secret:
63343a898ef5717a6a127b9c64a80f1068376d6c65e6b7108f87f5804aa6c945

A.5.4.1.  Encryptions


















Barnes, et al.            Expires 26 April 2021                [Page 77]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 8d4cd26358f105692d0ae29e
ciphertext: 043118c110de11697966d1d4fb3782d4d5043c283b4fd16e4630656854fc
2cff45b0f10ce205914f79771b039f

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 8d4cd26358f105692d0ae29f
ciphertext: cfc4100ee22cffd749d01f95483a97d5671170732c36b1e7232c016566e9
349c744dd50345eeeaa57d956a2fa2

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 8d4cd26358f105692d0ae29c
ciphertext: 0cf651270751e720ac78f8d995f1a5ec96e6dc107f77a4750e484e0e2e6e
b1f7c3da4f018e3486752409389ffc

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 8d4cd26358f105692d0ae29a
ciphertext: ffbb22b9ad07e95b07b34eb07a5f82ccca90d43c3aa89ee5a23a66cf34d0
3b835a7da410505c678fe6e617c3ed

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

A.6.1.  Base Setup Information




















Barnes, et al.            Expires 26 April 2021                [Page 78]


Internet-Draft                    HPKE                      October 2020


mode: 0
kem_id: 18
kdf_id: 3
aead_id: 2
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: 3fdb7eab3a6a99de8abbcb507be5704ae6a8994008b8a8e6b63fbd97fa8619c66b
d8665c22079939f3f63f978c5806802b22ba5bb396da9cf252ee67068bf57461bf
pkEm: 0401e9b3a83397ce01151df7c6def62d04561d5876ccc57437ca01af81a8f7a1a0
77b66d054bab46b830d7cb335db6acd7c7863a8dc2ec1840e8ac2e4e74f99fea26340040
f749f3b37512472b1da3df31854dc97a21fabad42be41ee0243613230ad69ba267669354
7ddb4d3454ac9a61d6f4ae756739a0ef226809bde93bd8b19d14cb06
skEm: 01eff8f7d9947cd83b8bcdac34496ee25dce30995df80ce64458acadfc9bacf709
8a4db0a1132524708b76c46041684ce62ce0adae54ce4d54446583357badbed08e
ikmR: 2e99ac709379c7eb15ca068253bbae4dd6297c2397f47a89b8cb3ef4e83f235f83
cb1ce3d2f754c47431ff0d0d8d2c429a7b6768d9524c3be60b9fb7749c49cb816b
pkRm: 04017b4d008b6602cf87554f1ae3f97c647da3ad5f347d73124495c6817d14f75c
181c07519bf2988a37e14967ca10254364678268c6558714d8ff6d4d821bb4f523d101c5
5f6d4f9ab0d4bce925444e2219a2b0f96920051294ef36b03dd4c69bd332df0d884794d4
4f0eb2d5ad7af9396dc946d8e4a5325724a2f8f9d6b52cba7524b644
skRm: 0015a422d63f675c687ccf900778c6da65b8941f939e1a2ec04e94d03668eddb6e
26f0ace5945388a0af1788afabe4d774160a5cc77dfc4abf6e4294125f0cf6ca8c
enc: 0401e9b3a83397ce01151df7c6def62d04561d5876ccc57437ca01af81a8f7a1a07
7b66d054bab46b830d7cb335db6acd7c7863a8dc2ec1840e8ac2e4e74f99fea26340040f
749f3b37512472b1da3df31854dc97a21fabad42be41ee0243613230ad69ba2676693547
ddb4d3454ac9a61d6f4ae756739a0ef226809bde93bd8b19d14cb06
shared_secret: bfd5bd75901d8767cd5561ac0e3b75873338517015fbd4f6b3559e8c9
f940e97ac5d4971e68c94f99934927180e01738c4f284f21109a7f4e7af9b1126589208
key_schedule_context: 007037eb32f87d04083a2f21fbda9aa88523d237843169bc66
43fe41b40f434ab776efe42da9db94c9b0b07bbab6536526de944469c381fc4f9d728b99
33adbb1015143a0ef0c7be1dca97f49c6338ddf0ad6d2d8014dcdd624e461c938d103f6c
55a6f539ca17eecf653cff7e419697dbe0e24e2697e22e738bf2c8486127f358
secret: 702aa90f69fa92790c845d3121cc2620fb96b2aba3433e95491f1620dc054287
0017388be341e19cda86a0d25e2bbfead1beda9f3d16cf0abd689944b64ee352
key: 57aeffb38c9b286367fde962c7d32bbab27075fa4d03d9a7465358d9e6fc6342
base_nonce: 61b22ddd85ce1a02ca3a89e1
exporter_secret: effa5f770620d75f76deec0f400dd42009c8088d296e58484e2a8d6
1e475d5a53639b7a909ca0651ab7787912962d2ea1e9133ed96db68fbc6cc4b9d9ab8ab2
a

A.6.1.1.  Encryptions











Barnes, et al.            Expires 26 April 2021                [Page 79]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 61b22ddd85ce1a02ca3a89e1
ciphertext: 00f4bff0895c34013c8c0e153a647e8c7aaf494a61da3f88e127cadbd628
e46351f59574834a7081ebbf98536e

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 61b22ddd85ce1a02ca3a89e0
ciphertext: de0ddf5e9e229008da337d718b48096ef8f74d2332806c3cc0a9e32858ad
aad88193ee26867bd63947c19149a8

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 61b22ddd85ce1a02ca3a89e3
ciphertext: 384ae15d9a021d1b77d43657b176ea635807f29ff8bd79fd4dd05003f64c
6d8f48d281d4b1e7dea1f6e5434547

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 61b22ddd85ce1a02ca3a89e5
ciphertext: 505456abc31145bb5301d3e572465f7e8f6f20864dac6f1dd27962848c4e
eea9d553ad3dabbae88d687cfcd40b

A.6.2.  PSK Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 80]


Internet-Draft                    HPKE                      October 2020


mode: 1
kem_id: 18
kdf_id: 3
aead_id: 2
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: ae300665d34d5ab7c0508a94a741ba2cb285966106ba9cefbe1f9c24c3eb626108
d0c9ccc8291d90c50c6d04ac181ccd8efc2cc52383eb205637a84d2be5362bf247
pkEm: 0401d8e07d90353867160b4e991c5365817bcbe07fe611b9e2d51b2be2913c47a0
8352e71d8b7da2e1726a4c9acef0b2dbf7beae263f0477e5829bd1a11b674553548f01ea
bac3a36e6830582423f095c055f109f88d4df217566f4c42c6c3696b7f8236563d868115
1566473ac4a9ebb3ce92d91a31b4c20129318df6cc9c641d86ca9c90
skEm: 01ffc6d8afae89c110b7f709d7b7a42f1f14f0d25ab0e72bc6ac74b4d71414d5a3
726d45d1550d8240807683fae156ca6ff3f2f40a0f11e0e793722f52303428a452
ikmR: dbbda5e5a54ee85cfe076e4746ceb971bed338a7fe0b625d6c7c28b3c82c812825
8906a52543655ecb62889e9dbe8feec747d06e4216f88ca4adba200179e0e75276
pkRm: 040186c1b7bf3e57c5eb7443be70506d9f70a4915e63b25b9a9859953ab30d3dc7
c97792f93cc7c1371421b1473ae13482a1c57c36b79d2f29c862f307dc8d19c8d30a01cb
116e09d7222fde60863619246eebd883bec14fb4b12ef01d232b2450d654ea304f236749
3b981bbe235128b3e176b9fecd0c3e3b7736f0fe5a999abaa0dc65e5
skRm: 0129cc1a3ddf1fb2482672893bed0f2a4e496a300bf277bdc865df261ce35bb92a
c647d035ac895dc3f0644951b21034507c12fea6c1e5c232bf89517915be461432
psk: 0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
psk_id: 456e6e796e20447572696e206172616e204d6f726961
enc: 0401d8e07d90353867160b4e991c5365817bcbe07fe611b9e2d51b2be2913c47a08
352e71d8b7da2e1726a4c9acef0b2dbf7beae263f0477e5829bd1a11b674553548f01eab
ac3a36e6830582423f095c055f109f88d4df217566f4c42c6c3696b7f8236563d8681151
566473ac4a9ebb3ce92d91a31b4c20129318df6cc9c641d86ca9c90
shared_secret: 120dea3ab9b56455b80374486ae081ca65074ba5fc0e052d64eb26961
4e7f5641a2cca92f23e616a24bcb3d70fbd6092907463defa85ad19c8a5e42faca7b176
key_schedule_context: 011b6c4c7206605da6ce250983c276ee8064ddf2e60a62feb6
97a5ca87ccf078a197c945aebad60fe7ea5a7f7ff722f3f6611f6eb1d95a8696ef33ddc6
970e224d15143a0ef0c7be1dca97f49c6338ddf0ad6d2d8014dcdd624e461c938d103f6c
55a6f539ca17eecf653cff7e419697dbe0e24e2697e22e738bf2c8486127f358
secret: aecbb961a62332682f170a27661f814a8bf5514eccc9967be90f157158f6341a
368fc9feb8c3e158ad127de57f093c5a58aa44138ef8fcbca5b6faeacb4cb374
key: 420619b93c512bd517df22fc43ea0047607c74b355b17cd69aef81edc6a607f7
base_nonce: 62e63c29f06399a0c81e907e
exporter_secret: 527430fac6f9ff3839fa2e3af11b9fa74857261288d01a702d753eb
acd5b2bee52359df82dcdf637182d4d12a3c4efd3c513dac6f9fea685d10fcb5e5f87d1e
2

A.6.2.1.  Encryptions









Barnes, et al.            Expires 26 April 2021                [Page 81]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 62e63c29f06399a0c81e907e
ciphertext: 17228870d1a4a692249cdadc1807fa64b8f3397e9102d56b213c2cccaae0
11b84326cebd8a948eff2027d15219

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 62e63c29f06399a0c81e907f
ciphertext: c2043ce47420e6c40bd86aa434ea65e783aab6d28164d460946bca2bda75
649b6ceb28cb407ad1a056ef4222d9

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 62e63c29f06399a0c81e907c
ciphertext: b699b9a7eb0ef210e3fc13fa91f229de31e7daec521e4ceea13534dbf7d5
cfecff5ab8ee20a87172d0000b897c

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 62e63c29f06399a0c81e907a
ciphertext: b01d1cca369f3d8fc294297c87ec2574cb646983a805e286eb7ad3496217
5e97a0a97903392b2a5c07b12184da

A.6.3.  Auth Setup Information






















Barnes, et al.            Expires 26 April 2021                [Page 82]


Internet-Draft                    HPKE                      October 2020


mode: 2
kem_id: 18
kdf_id: 3
aead_id: 2
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: 11c0c7337b294452826e14a7f6c9e7981a03c467a08f47a8b478b37f3e9c902668
98e3c3f8e84235a6a2837269c84b355d7f5ca133085172a08f00c3857da8a1410b
pkEm: 0400a424aad6b5ec7820349705e14b82e81df8a7204c71278367ae02365789f797
e00799f3f992e976c57b639451881ce5f1617f481e933d269f98cd482777cfc1f0bf018b
76cff256c43f6c84c59de83a549f25562de0b9514b206f7c3121a87da07296e13fed69f2
9be40f8e42a02c5f2e040a2594be42d9fc9498da036e510095702710
skEm: 0171b89c464a24cd554dd256038a40afee2b84fab35be25de7379281e8d9d94f30
58eefaaf30de7677c72137a4fc7fb663c7792fa10051811d58f38fc6038b9fd322
ikmR: bb56b3452a80ad82b2d48c19ce76194a198eefdb67040959bc9e479db0682a4b5b
46d7d020df66864d374b25deb5927144e3f08f2f9eacdd5f54b8b5c65d91ee211f
pkRm: 04014e2183dd2d23116fc3b6af53d7bc384337c6c78d897a2dc2e86997dcaf6bc8
68edc3ffc369922a6579f16bc3ef22eb331f72af62ac22435a8c3be602754d4ebcab01bb
42d322ab634f723bf99f6a25fbbdbd655813a95b1833a64f831f7a20dc9fe14f31ba4769
0d57d6ea52ae9182d4af7012d568773187a52e9976268c6320940312
skRm: 01c7c4a357c1d76f44fcb9e59585251cddabbb46605f0149bcf49969982f233b82
4988647e7d1e745c588f04294f042f375f9a39bde25a62e52417b471913e8c823e
ikmS: bab663b9c05f680f401a494ae8c8714fd95cbcd56a01e9e8194b4b3da863a5e831
3d4916dc58f6d3aaa2dafe420ae81b2a6c0075223afc6b13f3734a26ca30da5e38
pkSm: 0400b9defb2405e3c15772778f9dd6db4361486d803c841c82bcdba53c38dd4876
23cf293068dfd6e6ee65ab4af2a3d57b43c9c0449592daeddd39e64af5a55e65afc0010a
27fd34ea16887043092803e0c4fd179c9ca7401da4d96ff8d5f8346960623c6c542697c9
5d1108ad6df225391510b2b105f7864e4627f81b452188961a9459b4
skSm: 01f38e7318eebab0631f6d6dd58196ad7692da9b103e93d401321fb82934c0a538
d034393bac0204bd9846f86a54cbcee50bfad34835cde2f4f559a65b380d8cec9c
enc: 0400a424aad6b5ec7820349705e14b82e81df8a7204c71278367ae02365789f797e
00799f3f992e976c57b639451881ce5f1617f481e933d269f98cd482777cfc1f0bf018b7
6cff256c43f6c84c59de83a549f25562de0b9514b206f7c3121a87da07296e13fed69f29
be40f8e42a02c5f2e040a2594be42d9fc9498da036e510095702710
shared_secret: 5a294001a51d42d798d42c0a45b94a35a83d8feeadbc3199669749d93
0416c22207c1a351cdf72588fe4cc2e1d0ec8c74bee5ab542aa03671de78e92725d967e
key_schedule_context: 027037eb32f87d04083a2f21fbda9aa88523d237843169bc66
43fe41b40f434ab776efe42da9db94c9b0b07bbab6536526de944469c381fc4f9d728b99
33adbb1015143a0ef0c7be1dca97f49c6338ddf0ad6d2d8014dcdd624e461c938d103f6c
55a6f539ca17eecf653cff7e419697dbe0e24e2697e22e738bf2c8486127f358
secret: 7c6a231447448169c1d5a63fc7b27393739904ba31236022eb681ff603e007d8
a23f479f66f04a2562ebb6ebe1ed50dfeba47f9de1c19f415712de8ab08efd3a
key: e24bb29b558daeec9941ac6af01d73ec337e0bf0d5aa6140e25b4f4f1354503d
base_nonce: b692bdbed49ebb84ad17d679
exporter_secret: 40365288e3146348d6c1da7d4fb57b1fbdae5536ac8c025dc7d9d33
89d41a97f28526cc2955db087a1b9d94e609395f81c0206f360a507a32ad52f3b6b0ebd6
7





Barnes, et al.            Expires 26 April 2021                [Page 83]


Internet-Draft                    HPKE                      October 2020


A.6.3.1.  Encryptions

sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: b692bdbed49ebb84ad17d679
ciphertext: 1ba35f7298c1fa121faa3b8e25ce0c631f59b8c73992c4dbbfcbd4b3b427
55549aa245c37329d76501d117c32d

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: b692bdbed49ebb84ad17d678
ciphertext: 4185b352ac1f15a6e84a16eda3edb48631f74aacfa8011ec9e0e0320a0f7
99a4a21a2d2c350f44b0c3fcf02ac2

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: b692bdbed49ebb84ad17d67b
ciphertext: 075144aa6db54217789f4a274b8d5e333906f83c4b2461c872c7973b05b4
9c0ec3cb185ebb1b664bebc7959ad7

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: b692bdbed49ebb84ad17d67d
ciphertext: 9908d016ca2652ed0afa4ef8ee4ee5733d20f9be933dc69ea1161825a8a9
0523ddb51ea4840e253fbdfe4df9e8

A.6.4.  AuthPSK Setup Information

mode: 3
kem_id: 18
kdf_id: 3
aead_id: 2
info: 4f6465206f6e2061204772656369616e2055726e
ikmE: 4ebb461a5c46330d6de3a40d19ac499cc206733cf1a4fb3ba922d976aa1c458486
68f04a3b5a4845a0d1c83755967d8914a9824fbb8823d161c16c93c51636e1ad89
pkEm: 04005ecbb8a44f65b079fb6a025d0ed2a7c675113836b5143f7886bcf89cfb2cf0
d26672874fb03124e0e6303cdecb139f964e78169aff79d7f57feebc66cf58747a3f010b
14f67c282b091a5aefc87672951e5ddcb9f04897320a43c5aab8b9d03f1fc00a0c2f8b5a
f41abece59b17ca0f8427df7cb1cf79d01ac4013179a8cc66e94cee7
skEm: 012850e41e3f14578099a650b470eb6226b1f757145e4ed98326888f87e5d1fef0
9a57a6596fe141bcc5fe4fff32620ba6b10ffae1c476985ed0ff1d96116207bf85
ikmR: 1ae2f1008c46c7a6e9275b1e29c906475c6bc019b1dfc38cbce68c5233de9d33ba
93fe9d7b9ea5beb04f4adc5a3b72238f6e3d904d29eb0680ea240103d3335a3c47
pkRm: 040161142294012f7f1e7af7ba86611de6d4cf7a7eb40498b7b40aee7ae2e9d8ac



Barnes, et al.            Expires 26 April 2021                [Page 84]


Internet-Draft                    HPKE                      October 2020


41b6a1615e076e0ffd0239e1e465b0b791601cfb62212732820223a2ef5f0e0ab3d7002c
283a89ac436fd2967c5975b9db046c50fab2dbcc9b17de528f2d3d6ef4e520d111f433fd
d8ee7885c89215668775bce903d73f4a0253407eeec920817fa04ae8
skRm: 0038ac202327bcb0ee9e3db84302930f2963a8a5440a172600d855c07864018ff5
1a5725c8b1d9037cebf84cb53755a5f35296b603afcfbea95530361ca40076b75c
ikmS: e0f2ada4f2a900fded767dc9868119ee3e4767afac667a780b68e5e2b4d7d363db
f02717ab314369c45f34dcec3de384a65e8453a971ad0353a507f34dc1d5d9b8f5
pkSm: 0401e965e58f927c571f468a1cfeb8eaf2c906cfa9f43f3c427dc8e5b4379c70e4
20f90f86c517ff17d1eb35aa7f071e89c07523099e14f7e033087a089984deaa73a90100
bc0ee78fa5bf8d3956c1ca9d07ccc3ad6dca951108bbf0835fa2375dd3d45760b7999444
e670b73cac2622d3fd75152217b17b88dac4935820c8c5a97550b509
skSm: 0130f8092f0b7ac4571e9425c561a7f1d610d13fa6ea2ef43ca1d5451cf9c0e799
d7c95648aa3a7714c04868e7fa9dff65afcc225f94d1fefee875b5c55dc70da587
psk: 0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
psk_id: 456e6e796e20447572696e206172616e204d6f726961
enc: 04005ecbb8a44f65b079fb6a025d0ed2a7c675113836b5143f7886bcf89cfb2cf0d
26672874fb03124e0e6303cdecb139f964e78169aff79d7f57feebc66cf58747a3f010b1
4f67c282b091a5aefc87672951e5ddcb9f04897320a43c5aab8b9d03f1fc00a0c2f8b5af
41abece59b17ca0f8427df7cb1cf79d01ac4013179a8cc66e94cee7
shared_secret: 0f5896c3a2d7323f0608291362befd1b584dae187b064a57d3fcf22a0
254c1a7c7c4baba883dca3c250747b756f8f8f051434d4d7f4b193a66f4f7b3118d39ac
key_schedule_context: 031b6c4c7206605da6ce250983c276ee8064ddf2e60a62feb6
97a5ca87ccf078a197c945aebad60fe7ea5a7f7ff722f3f6611f6eb1d95a8696ef33ddc6
970e224d15143a0ef0c7be1dca97f49c6338ddf0ad6d2d8014dcdd624e461c938d103f6c
55a6f539ca17eecf653cff7e419697dbe0e24e2697e22e738bf2c8486127f358
secret: a315a07a5a694445530ad322df119718053d7dfbaad443777bd0d30f8f62af4a
93293c9297473d1654bba218a48f476a00d3fd142ae1634d84296071e51829a9
key: ca510f3500c9050ca1b21b958464296bb16baceb4dee8fa6a3076a2430423d0a
base_nonce: 37abf56907992ad40e27ed50
exporter_secret: f83d533341fb594fa6e2c4004fd10d73c9e939c7305a7ced4b92a64
904ed0602994fd00cff4e4e06ba6e45d5d685650b24162ed4a6c31d944598649fe71cd44
e

A.6.4.1.  Encryptions

















Barnes, et al.            Expires 26 April 2021                [Page 85]


Internet-Draft                    HPKE                      October 2020


sequence number: 0
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d30
nonce: 37abf56907992ad40e27ed50
ciphertext: 08b11bb7c02b39a5d15fbd94e5f2f2441a0728a5a7ed91b13a97bd19d813
693ddfe97138b5412fff9ddc522801

sequence number: 1
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d31
nonce: 37abf56907992ad40e27ed51
ciphertext: 32436c4a18f3d2cce9d20a38f9dc0ec2865785475b83a40a75836663303a
70fcdecfd963258e00d6fccd9663e6

sequence number: 2
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d32
nonce: 37abf56907992ad40e27ed52
ciphertext: 6994cd7137222f9433bac62ad841833e7ecd0aa948db67177ed21ad5a1c5
105a38f15a883a3412c13da16aef1a

sequence number: 4
plaintext: 4265617574792069732074727574682c20747275746820626561757479
aad: 436f756e742d34
nonce: 37abf56907992ad40e27ed54
ciphertext: cf5d16f80af79584cb3333c2bc86fe2e5ef33d4abc3292c45f6481c85af8
6ddeb62ca7cb5a2dd32c59e9a6ecfa

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 26 April 2021                [Page 86]


Internet-Draft                    HPKE                      October 2020


   Christopher A. Wood
   Cloudflare

   Email: caw@heapingbits.net















































Barnes, et al.            Expires 26 April 2021                [Page 87]


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