[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-krawczyk-cfrg-opaque)  00 01 02           Informational
          03 04 05                                                      
Network Working Group                                        H. Krawczyk
Internet-Draft                                       Algorand Foundation
Intended status: Informational                                   K. Lewi
Expires: 25 August 2021                                    Novi Research
                                                               C.A. Wood
                                                              Cloudflare
                                                        21 February 2021


                  The OPAQUE Asymmetric PAKE Protocol
                       draft-irtf-cfrg-opaque-03

Abstract

   This document describes the OPAQUE protocol, a secure asymmetric
   password-authenticated key exchange (aPAKE) that supports mutual
   authentication in a client-server setting without reliance on PKI and
   with security against pre-computation attacks upon server compromise.
   In addition, the protocol provides forward secrecy and the ability to
   hide the password from the server, even during password registration.
   This document specifies the core OPAQUE protocol, along with several
   instantiations in different authenticated key exchange protocols.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/cfrg/draft-irtf-cfrg-opaque.

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 25 August 2021.





Krawczyk, et al.         Expires 25 August 2021                 [Page 1]


Internet-Draft                   OPAQUE                    February 2021


Copyright Notice

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

   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
     1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   6
     1.2.  Notation  . . . . . . . . . . . . . . . . . . . . . . . .   6
   2.  Cryptographic Protocol and Algorithm Dependencies . . . . . .   7
   3.  Offline Registration  . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Credential Storage  . . . . . . . . . . . . . . . . . . .   9
     3.2.  Registration Messages . . . . . . . . . . . . . . . . . .  11
     3.3.  Registration Functions  . . . . . . . . . . . . . . . . .  12
       3.3.1.  CreateRegistrationRequest . . . . . . . . . . . . . .  12
       3.3.2.  CreateRegistrationResponse  . . . . . . . . . . . . .  12
       3.3.3.  FinalizeRequest . . . . . . . . . . . . . . . . . . .  13
       3.3.4.  Credential File . . . . . . . . . . . . . . . . . . .  15
   4.  Online Authenticated Key Exchange . . . . . . . . . . . . . .  15
     4.1.  Credential Retrieval  . . . . . . . . . . . . . . . . . .  15
       4.1.1.  Credential Retrieval Messages . . . . . . . . . . . .  16
       4.1.2.  Credential Retrieval Functions  . . . . . . . . . . .  16
     4.2.  AKE Instantiations  . . . . . . . . . . . . . . . . . . .  18
       4.2.1.  Key Schedule Utility Functions  . . . . . . . . . . .  19
       4.2.2.  OPAQUE-3DH Instantiation  . . . . . . . . . . . . . .  20
   5.  Configurations  . . . . . . . . . . . . . . . . . . . . . . .  22
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
     6.1.  Related Analysis  . . . . . . . . . . . . . . . . . . . .  24
     6.2.  Identities  . . . . . . . . . . . . . . . . . . . . . . .  24
     6.3.  Envelope Encryption . . . . . . . . . . . . . . . . . . .  25
     6.4.  Export Key Usage  . . . . . . . . . . . . . . . . . . . .  26
     6.5.  Static Diffie-Hellman Oracles . . . . . . . . . . . . . .  26
     6.6.  Input Validation  . . . . . . . . . . . . . . . . . . . .  26
     6.7.  OPRF Hardening  . . . . . . . . . . . . . . . . . . . . .  26
     6.8.  Client Enumeration  . . . . . . . . . . . . . . . . . . .  27
     6.9.  Password Salt and Storage Implications  . . . . . . . . .  28
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  28



Krawczyk, et al.         Expires 25 August 2021                 [Page 2]


Internet-Draft                   OPAQUE                    February 2021


     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  28
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  29
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  32
   Appendix B.  Alternate AKE Instantiations . . . . . . . . . . . .  32
     B.1.  HMQV Instantiation Sketch . . . . . . . . . . . . . . . .  32
     B.2.  SIGMA-I Instantiation Sketch  . . . . . . . . . . . . . .  33
   Appendix C.  Test Vectors . . . . . . . . . . . . . . . . . . . .  34
     C.1.  OPAQUE-3DH Test Vector 1  . . . . . . . . . . . . . . . .  34
       C.1.1.  Configuration . . . . . . . . . . . . . . . . . . . .  34
       C.1.2.  Input Values  . . . . . . . . . . . . . . . . . . . .  34
       C.1.3.  Intermediate Values . . . . . . . . . . . . . . . . .  35
       C.1.4.  Output Values . . . . . . . . . . . . . . . . . . . .  36
     C.2.  OPAQUE-3DH Test Vector 2  . . . . . . . . . . . . . . . .  37
       C.2.1.  Configuration . . . . . . . . . . . . . . . . . . . .  37
       C.2.2.  Input Values  . . . . . . . . . . . . . . . . . . . .  37
       C.2.3.  Intermediate Values . . . . . . . . . . . . . . . . .  38
       C.2.4.  Output Values . . . . . . . . . . . . . . . . . . . .  39
     C.3.  OPAQUE-3DH Test Vector 3  . . . . . . . . . . . . . . . .  40
       C.3.1.  Configuration . . . . . . . . . . . . . . . . . . . .  40
       C.3.2.  Input Values  . . . . . . . . . . . . . . . . . . . .  41
       C.3.3.  Intermediate Values . . . . . . . . . . . . . . . . .  41
       C.3.4.  Output Values . . . . . . . . . . . . . . . . . . . .  42
     C.4.  OPAQUE-3DH Test Vector 4  . . . . . . . . . . . . . . . .  43
       C.4.1.  Configuration . . . . . . . . . . . . . . . . . . . .  43
       C.4.2.  Input Values  . . . . . . . . . . . . . . . . . . . .  43
       C.4.3.  Intermediate Values . . . . . . . . . . . . . . . . .  44
       C.4.4.  Output Values . . . . . . . . . . . . . . . . . . . .  44
     C.5.  OPAQUE-3DH Test Vector 5  . . . . . . . . . . . . . . . .  45
       C.5.1.  Configuration . . . . . . . . . . . . . . . . . . . .  45
       C.5.2.  Input Values  . . . . . . . . . . . . . . . . . . . .  46
       C.5.3.  Intermediate Values . . . . . . . . . . . . . . . . .  47
       C.5.4.  Output Values . . . . . . . . . . . . . . . . . . . .  48
     C.6.  OPAQUE-3DH Test Vector 6  . . . . . . . . . . . . . . . .  49
       C.6.1.  Configuration . . . . . . . . . . . . . . . . . . . .  49
       C.6.2.  Input Values  . . . . . . . . . . . . . . . . . . . .  50
       C.6.3.  Intermediate Values . . . . . . . . . . . . . . . . .  51
       C.6.4.  Output Values . . . . . . . . . . . . . . . . . . . .  51
     C.7.  OPAQUE-3DH Test Vector 7  . . . . . . . . . . . . . . . .  52
       C.7.1.  Configuration . . . . . . . . . . . . . . . . . . . .  52
       C.7.2.  Input Values  . . . . . . . . . . . . . . . . . . . .  52
       C.7.3.  Intermediate Values . . . . . . . . . . . . . . . . .  53
       C.7.4.  Output Values . . . . . . . . . . . . . . . . . . . .  54
     C.8.  OPAQUE-3DH Test Vector 8  . . . . . . . . . . . . . . . .  55
       C.8.1.  Configuration . . . . . . . . . . . . . . . . . . . .  55
       C.8.2.  Input Values  . . . . . . . . . . . . . . . . . . . .  56
       C.8.3.  Intermediate Values . . . . . . . . . . . . . . . . .  57
       C.8.4.  Output Values . . . . . . . . . . . . . . . . . . . .  57
     C.9.  OPAQUE-3DH Test Vector 9  . . . . . . . . . . . . . . . .  58



Krawczyk, et al.         Expires 25 August 2021                 [Page 3]


Internet-Draft                   OPAQUE                    February 2021


       C.9.1.  Configuration . . . . . . . . . . . . . . . . . . . .  58
       C.9.2.  Input Values  . . . . . . . . . . . . . . . . . . . .  58
       C.9.3.  Intermediate Values . . . . . . . . . . . . . . . . .  59
       C.9.4.  Output Values . . . . . . . . . . . . . . . . . . . .  60
     C.10. OPAQUE-3DH Test Vector 10 . . . . . . . . . . . . . . . .  61
       C.10.1.  Configuration  . . . . . . . . . . . . . . . . . . .  61
       C.10.2.  Input Values . . . . . . . . . . . . . . . . . . . .  62
       C.10.3.  Intermediate Values  . . . . . . . . . . . . . . . .  63
       C.10.4.  Output Values  . . . . . . . . . . . . . . . . . . .  63
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  64

1.  Introduction

   Password authentication is the prevalent form of authentication on
   the web and in many other applications.  In the most common
   implementation, a client authenticates to a server by sending its
   client ID and password to the server over a TLS connection.  This
   makes the password vulnerable to server mishandling, including
   accidentally logging the password or storing it in cleartext in a
   database.  Server compromise resulting in access to these plaintext
   passwords is not an uncommon security incident, even among security-
   conscious companies.  Moreover, plaintext password authentication
   over TLS is also vulnerable to TLS failures, including many forms of
   PKI attacks, certificate mishandling, termination outside the
   security perimeter, visibility to middleboxes, and more.

   Asymmetric (or Augmented) Password Authenticated Key Exchange (aPAKE)
   protocols are designed to provide password authentication and
   mutually authenticated key exchange in a client-server setting
   without relying on PKI (except during client/password registration)
   and without disclosing passwords to servers or other entities other
   than the client machine.  A secure aPAKE should provide the best
   possible security for a password protocol.  Namely, it should only be
   open to inevitable attacks, such as online impersonation attempts
   with guessed client passwords and offline dictionary attacks upon the
   compromise of a server and leakage of its password file.  In the
   latter case, the attacker learns a mapping of a client's password
   under a one-way function and uses such a mapping to validate
   potential guesses for the password.  Crucially important is for the
   password protocol to use an unpredictable one-way mapping.
   Otherwise, the attacker can pre-compute a deterministic list of
   mapped passwords leading to almost instantaneous leakage of passwords
   upon server compromise.

   Despite the existence of multiple designs for (PKI-free) aPAKE
   protocols, none of these protocols are secure against pre-computation
   attacks.  In particular, none of these protocols can use the standard
   technique against pre-computation that combines _secret_ random



Krawczyk, et al.         Expires 25 August 2021                 [Page 4]


Internet-Draft                   OPAQUE                    February 2021


   values ("salt") into the one-way password mappings.  Either these
   protocols do not use a salt at all or, if they do, they transmit the
   salt from server to client in the clear, hence losing the secrecy of
   the salt and its defense against pre-computation.  Furthermore,
   transmitting the salt may require additional protocol messages.

   This document describes OPAQUE, a PKI-free secure aPAKE that is
   secure against pre-computation attacks and capable of using a secret
   salt.  OPAQUE provides forward secrecy (essential for protecting past
   communications in case of password leakage) and the ability to hide
   the password from the server - even during password registration.
   Furthermore, OPAQUE enjoys good performance and an array of
   additional features including the ability to increase the difficulty
   of offline dictionary attacks via iterated hashing or other hardening
   schemes, and offloading these operations to the client (that also
   helps against online guessing attacks); extensibility of the protocol
   to support storage and retrieval of client's secrets solely based on
   a password; being amenable to a multi-server distributed
   implementation where offline dictionary attacks are not possible
   without breaking into a threshold of servers (such a distributed
   solution requires no change or awareness on the client side relative
   to a single-server implementation).

   OPAQUE is defined and proven as the composition of two
   functionalities: an oblivious pseudorandom function (OPRF) and an
   authenticated key exchange (AKE) protocol.  It can be seen as a
   "compiler" for transforming any suitable AKE protocol into a secure
   aPAKE protocol.  (See Section 6 for requirements of the OPRF and AKE
   protocols.)  This document specifies one OPAQUE instantiation based
   on 3DH [SIGNAL].  Other instantiations are possible, as discussed in
   Appendix B, but their details are out of scope for this document.  In
   general, the modularity of OPAQUE's design makes it easy to integrate
   with additional AKE protocols, e.g., IKEv2, and with future ones such
   as those based on post-quantum techniques.

   OPAQUE consists of two stages: registration and authenticated key
   exchange.  In the first stage, a client registers its password with
   the server and stores its encrypted credentials on the server.  In
   the second stage, a client obtains those credentials, recovers them
   using the client's password, and subsequently uses them as input to
   an AKE protocol.

   Currently, the most widely deployed PKI-free aPAKE is SRP [RFC2945],
   which is vulnerable to pre-computation attacks, lacks proof of
   security and is less efficient relative to OPAQUE.  Moreover, SRP
   requires a ring as it mixes addition and multiplication operations,
   and thus does not work over plain elliptic curves.  OPAQUE is
   therefore a suitable replacement for applications that use SRP.



Krawczyk, et al.         Expires 25 August 2021                 [Page 5]


Internet-Draft                   OPAQUE                    February 2021


   This draft complies with the requirements for PAKE protocols set
   forth in [RFC8125].

1.1.  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
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Notation

   The following terms are used throughout this document to describe the
   operations, roles, and behaviors of OPAQUE:

   *  Client (C): Entity that has knowledge of a password and wishes to
      authenticate.

   *  Server (S): Entity that authenticates clients using passwords.

   *  password: An opaque byte string containing the client's password.

   *  I2OSP and OS2IP: Convert a byte string to and from a non-negative
      integer as described in Section 4 of [RFC8017].  Note that these
      functions operate on byte strings in big-endian byte order.

   *  concat(x0, ..., xN): Concatenate byte strings.  For example,
      "concat(0x01, 0x0203, 0x040506) = 0x010203040506".

   *  random(n): Generate a cryptographically secure pseudorandom byte
      string of length "n" bytes.

   *  xor(a,b): Apply XOR to byte strings.  For example, "xor(0xF0F0,
      0x1234) = 0xE2C4".  It is an error to call this function with two
      arguments of unequal length.

   *  ct_equal(a, b): Return "true" if "a" is equal to "b", and false
      otherwise.  This function is constant-time in the length of "a"
      and "b", which are assumed to be of equal length, irrespective of
      the values "a" or "b".

   Except if said otherwise, random choices in this specification refer
   to drawing with uniform distribution from a given set (i.e., "random"
   is short for "uniformly random").  Random choices can be replaced
   with fresh outputs from a cryptographically strong pseudorandom
   generator, according to the requirements in [RFC4086], or
   pseudorandom function.



Krawczyk, et al.         Expires 25 August 2021                 [Page 6]


Internet-Draft                   OPAQUE                    February 2021


   The name OPAQUE is a homonym of O-PAKE where O is for Oblivious.  The
   name OPAKE was taken.

2.  Cryptographic Protocol and Algorithm Dependencies

   OPAQUE relies on the following protocols and primitives:

   *  Oblivious Pseudorandom Function (OPRF, [I-D.irtf-cfrg-voprf],
      version -06):

      -  Blind(x): Convert input "x" into an element of the OPRF group,
         randomize it by some scalar "r", producing "M", and output
         ("r", "M").

      -  GenerateKeyPair(): Generate an OPRF private and public key.
         OPAQUE only requires an OPRF private key.  We write "(oprf_key,
         _) = GenerateKeyPair()" to denote use of this function for
         generating secret key "oprf_key" (and discarding the
         corresponding public key).

      -  Evaluate(k, M): Evaluate input element "M" using private key
         "k", yielding output element "Z".

      -  Finalize(x, r, Z): Finalize the OPRF evaluation using input
         "x", random scalar "r", and evaluation output "Z", yielding
         output "y".

      -  SerializeScalar(s): Map a scalar "s" to a unique byte array
         "buf" of fixed length.

      -  DeserializeScalar(buf): Map a byte array "buf" to a scalar "s",
         or fail if the input is not a valid byte representation of a
         scalar.

      -  SerializedElement: A serialized OPRF group element, a byte
         array of fixed length.

      -  SerializedScalar: A serialized OPRF scalar, a byte array of
         fixed length.

   Note that we only need the base mode variant (as opposed to the
   verifiable mode variant) of the OPRF described in
   [I-D.irtf-cfrg-voprf].

   *  Cryptographic hash function:

      -  Hash(m): Compute the cryptographic hash of input message "m".
         The type of the hash is determined by the chosen OPRF group.



Krawczyk, et al.         Expires 25 August 2021                 [Page 7]


Internet-Draft                   OPAQUE                    February 2021


      -  Nh: The output size of the Hash function.

   *  Authenticated Key Exchange (AKE, Section 4.2):

      -  Npk: The size of the public keys used for the key exchange
         protocol.

      -  Nsk: The size of the private keys used for the key exchange
         protocol.

   *  Memory Hard Function (MHF):

      -  Harden(msg, params): Repeatedly apply a memory-hard function
         with parameters "params" to strengthen the input "msg" against
         offline dictionary attacks.  This function also needs to
         satisfy collision resistance.

3.  Offline Registration

   Registration is executed between a client C and a server S.  It is
   assumed S can identify C and the client can authenticate S during
   this registration phase.  This is the only part in OPAQUE that
   requires an authenticated channel, either physical, out-of-band, PKI-
   based, etc.  This section describes the registration flow, message
   encoding, and helper functions.  Moreover, C has a key pair
   (client_private_key, client_public_key) for an AKE protocol which is
   suitable for use with OPAQUE; See Section 4.  The private-public keys
   (client_private_key, client_public_key) may be randomly generated
   (using a cryptographically secure pseudorandom number generator) for
   the account or provided by the calling client.  Clients MUST NOT use
   the same key pair (client_private_key, client_public_key) for two
   different accounts.

   To begin, C chooses its password, and S chooses its own pair of
   private-public AKE keys (server_private_key, server_public_key) for
   use with the AKE.  S can use the same pair of keys with multiple
   clients.  These steps can happen offline, i.e., before the
   registration phase.  Once complete, the registration process proceeds
   as follows:












Krawczyk, et al.         Expires 25 August 2021                 [Page 8]


Internet-Draft                   OPAQUE                    February 2021


 Client (password, creds)            Server (server_private_key, server_public_key)
 --------------------------------------------------------------------
 (request, blind) = CreateRegistrationRequest(password)

                               request
                      ------------------------->

            (response, oprf_key) = CreateRegistrationResponse(request, server_public_key)

                               response
                      <-------------------------

 (record, export_key) = FinalizeRequest(password, creds, blind, response)

                                record
                      ------------------------->

   Section 3.3 describes details of the functions referenced above.

   Both client and server MUST validate the other party's public key
   before use.  See Section 6.6 for more details.

   Upon completion, S stores C's credentials for later use.  See
   Section 3.3.4 for a recommended storage format.

3.1.  Credential Storage

   OPAQUE makes use of a structure "Envelope" to store client
   credentials.  The "Envelope" structure embeds the following types of
   credentials:

   *  client_private_key: The encoded client private key for the AKE
      protocol.

   *  server_public_key: The encoded server public key for the AKE
      protocol.

   *  client_identity: The client identity.  This is an application-
      specific value, e.g., an e-mail address or normal account name.

   *  server_identity: The server identity.  This is typically a domain
      name, e.g., example.com.  See Section 6.2 for information about
      this identity.

   Each public and private key value is an opaque byte string, specific
   to the AKE protocol in which OPAQUE is instantiated.  For example, if
   used as raw public keys for TLS 1.3 [RFC8446], they may be RSA or
   ECDSA keys as per [RFC7250].



Krawczyk, et al.         Expires 25 August 2021                 [Page 9]


Internet-Draft                   OPAQUE                    February 2021


   These credentials are incorporated in the "SecretCredentials" and
   "CleartextCredentials" structs, depending on the mode set by the
   value of "EnvelopeMode":

   enum {
     base(1),
     custom_identifier(2),
     (255)
   } EnvelopeMode;

   The "base" mode defines "SecretCredentials" and
   "CleartextCredentials" as follows:

   struct {
     opaque client_private_key[Nsk];
   } SecretCredentials;

   struct {
     opaque server_public_key[Npk];
   } CleartextCredentials;

   The "custom_identifier" mode defines "SecretCredentials" and
   "CleartextCredentials" as follows:

   struct {
     opaque client_private_key[Nsk];
   } SecretCredentials;

   struct {
     opaque server_public_key[Npk];
     opaque client_identity<0..2^16-1>;
     opaque server_identity<0..2^16-1>;
   } CleartextCredentials;

   These credentials are embedded into the following "Envelope"
   structure with encryption and authentication.

   struct {
     EnvelopeMode mode;
     opaque nonce[32];
     opaque encrypted_creds[Nsk];
   } InnerEnvelope;

   struct {
     InnerEnvelope inner_env;
     opaque auth_tag[Nh];
   } Envelope;




Krawczyk, et al.         Expires 25 August 2021                [Page 10]


Internet-Draft                   OPAQUE                    February 2021


   mode  The "EnvelopeMode" value.  This MUST be one of "base" or
      "custom_identifier".

   nonce  A unique 32-byte nonce used to protect this Envelope.

   encrypted_creds  Encoding of encrypted and authenticated
      "SecretCredentials".

   auth_tag  Authentication tag protecting the contents of the envelope,
      covering "InnerEnvelope" and "CleartextCredentials".

   The full procedure for constructing "Envelope" and "InnerEnvelope"
   from "SecretCredentials" and "CleartextCredentials" is described in
   Section 3.3.3.  Note that only "SecretCredentials" are stored in the
   "Envelope" (in encrypted form).

   The "EnvelopeMode" value is specified as part of the configuration
   (see Section 5).

   Credential information corresponding to the configuration-specific
   mode, along with the client public key "client_public_key" and
   private key "client_private_key", are recommended to be stored in a
   "Credentials" object with the following named fields:

   *  "client_private_key", the client's private key

   *  "client_public_key", the client's public key corresponding to
      "client_private_key"

   *  "client_identity", an optional client identity (present only in
      the "custom_identifier" mode)

   *  "server_identity", an optional server identity (present only in
      the "custom_identifier" mode)

3.2.  Registration Messages

   struct {
       SerializedElement data;
   } RegistrationRequest;

   data  A serialized OPRF group element.

   struct {
       SerializedElement data;
       opaque server_public_key[Npk];
   } RegistrationResponse;




Krawczyk, et al.         Expires 25 August 2021                [Page 11]


Internet-Draft                   OPAQUE                    February 2021


   data  A serialized OPRF group element.

   server_public_key  The server's encoded public key that will be used
      for the online authenticated key exchange stage.

   struct {
       opaque client_public_key[Npk];
       Envelope envelope;
   } RegistrationUpload;

   client_public_key  The client's encoded public key, corresponding to
      the private key "client_private_key".

   envelope  The client's "Envelope" structure.

3.3.  Registration Functions

3.3.1.  CreateRegistrationRequest

   CreateRegistrationRequest(password)

   Input:
   - password, an opaque byte string containing the client's password

   Output:
   - request, a RegistrationRequest structure
   - blind, an OPRF scalar value

   Steps:
   1. (blind, M) = Blind(password)
   2. Create RegistrationRequest request with M
   3. Output (request, blind)

3.3.2.  CreateRegistrationResponse

















Krawczyk, et al.         Expires 25 August 2021                [Page 12]


Internet-Draft                   OPAQUE                    February 2021


   CreateRegistrationResponse(request, server_public_key)

   Input:
   - request, a RegistrationRequest structure
   - server_public_key, the server's public key

   Output:
   - response, a RegistrationResponse structure
   - oprf_key, the per-client OPRF key known only to the server

   Steps:
   1. (oprf_key, _) = GenerateKeyPair()
   2. Z = Evaluate(oprf_key, request.data)
   3. Create RegistrationResponse response with (Z, server_public_key)
   4. Output (response, oprf_key)

3.3.3.  FinalizeRequest


































Krawczyk, et al.         Expires 25 August 2021                [Page 13]


Internet-Draft                   OPAQUE                    February 2021


FinalizeRequest(password, creds, blind, response)

Parameters:
- params, the MHF parameters established out of band
- mode, the InnerEnvelope mode
- Nh, the output size of the Hash function

Input:
- password, an opaque byte string containing the client's password
- creds, a Credentials structure
- blind, an OPRF scalar value
- response, a RegistrationResponse structure

Output:
- record, a RegistrationUpload structure
- export_key, an additional key

Steps:
1. y = Finalize(password, blind, response.data)
2. envelope_nonce = random(32)
3. prk = HKDF-Extract(envelope_nonce, Harden(y, params))
4. Create SecretCredentials secret_creds with creds.client_private_key
5. Create CleartextCredentials cleartext_creds with response.server_public_key
   and custom identifiers creds.client_identity and creds.server_identity if
   mode is custom_identifier
6. pseudorandom_pad =
     HKDF-Expand(prk, "Pad", len(secret_creds))
7. auth_key = HKDF-Expand(prk, "AuthKey", Nh)
8. export_key = HKDF-Expand(prk, "ExportKey", Nh)
9. encrypted_creds = xor(secret_creds, pseudorandom_pad)
10. Create InnerEnvelope inner_env
      with (mode, envelope_nonce, encrypted_creds)
11. auth_tag = HMAC(auth_key, concat(inner_env, cleartext_creds))
12. Create Envelope envelope with (inner_env, auth_tag)
13. Create RegistrationUpload record with (envelope, creds.client_public_key)
14. Output (record, export_key)

   The inputs to HKDF-Extract and HKDF-Expand are as specified in
   [RFC5869].  The underlying hash function is that which is associated
   with the OPAQUE configuration (see Section 5).

   See Section 4 for details about the output export_key usage.

   Upon completion of this function, the client MUST send "record" to
   the server.






Krawczyk, et al.         Expires 25 August 2021                [Page 14]


Internet-Draft                   OPAQUE                    February 2021


3.3.4.  Credential File

   The server then constructs and stores the "credential_file" object,
   where "envelope" and "client_public_key" are obtained from "record",
   and "oprf_key" is retained from the output of
   "CreateRegistrationResponse". "oprf_key" is serialized using
   "SerializeScalar".  The below structure represents an example of how
   these values might be conveniently stored together.

   struct {
       SerializedScalar oprf_key;
       opaque client_public_key[Npk];
       Envelope envelope;
   } credential_file;

4.  Online Authenticated Key Exchange

   After registration, the client and server run the authenticated key
   exchange stage of the OPAQUE protocol.  This stage is composed of a
   concurrent OPRF and key exchange flow.  The key exchange protocol is
   authenticated using the client and server credentials established
   during registration; see Section 3.  The type of keys MUST be
   suitable for the key exchange protocol.  For example, if the key
   exchange protocol is 3DH, as described in Section 4.2.2, then the
   private and public keys must be Diffie-Hellman keys.  In the end, the
   client proves its knowledge of the password, and both client and
   server agree on a mutually authenticated shared secret key.

   OPAQUE produces two outputs: a session secret and an export key.  The
   export key may be used for additional application-specific purposes,
   as outlined in Section 6.4.  The output "export_key" MUST NOT be used
   in any way before the HMAC value in the envelope is validated.  See
   Section 6.3 for more details about this requirement.

4.1.  Credential Retrieval

   The online AKE stage of the protocol requires clients to obtain and
   decrypt their credentials from the server-stored envelope.  This
   process is similar to the offline registration stage, as shown below.












Krawczyk, et al.         Expires 25 August 2021                [Page 15]


Internet-Draft                   OPAQUE                    February 2021


 Client (password)             Server (server_private_key, server_public_key, credential_file)
 --------------------------------------------------------------------
 (request, blind) = CreateCredentialRequest(password)

                               request
                      ------------------------->

    response = CreateCredentialResponse(request, server_public_key, credential_file)

                               response
                      <-------------------------

 (client_private_key, server_public_key, export_key) =
     RecoverCredentials(password, blind, response)

   The rest of this section describes these credential retrieval
   functions in more detail.

4.1.1.  Credential Retrieval Messages

   struct {
       SerializedElement data;
   } CredentialRequest;

   data  A serialized OPRF group element.

   struct {
       SerializedElement data;
       opaque server_public_key[Npk];
       Envelope envelope;
   } CredentialResponse;

   data  A serialized OPRF group element.

   server_public_key  The server's encoded public key that will be used
      for the online authenticated key exchange stage.

   envelope  The client's "Envelope" structure.

4.1.2.  Credential Retrieval Functions

4.1.2.1.  CreateCredentialRequest









Krawczyk, et al.         Expires 25 August 2021                [Page 16]


Internet-Draft                   OPAQUE                    February 2021


   CreateCredentialRequest(password)

   Input:
   - password, an opaque byte string containing the client's password

   Output:
   - request, a CredentialRequest structure
   - blind, an OPRF scalar value

   Steps:
   1. (blind, M) = Blind(password)
   2. Create CredentialRequest request with M
   3. Output (request, blind)

4.1.2.2.  CreateCredentialResponse

CreateCredentialResponse(request, server_public_key, credential_file)

Input:
- request, a CredentialRequest structure
- server_public_key, the public key of the server
- credential_file, the server's output from registration
  (see {{credential-file}})

Output:
- response, a CredentialResponse structure

Steps:
1. Z = Evaluate(DeserializeScalar(credential_file.oprf_key), request.data)
2. Create CredentialResponse response
    with (Z, server_public_key, credential_file.envelope)
3. Output response

4.1.2.3.  RecoverCredentials

















Krawczyk, et al.         Expires 25 August 2021                [Page 17]


Internet-Draft                   OPAQUE                    February 2021


RecoverCredentials(password, blind, response)

Parameters:
- params, the MHF parameters established out of band
- Nh, the output size of the Hash function

Input:
- password, an opaque byte string containing the client's password
- blind, an OPRF scalar value
- response, a CredentialResponse structure

Output:
- client_private_key, the client's private key for the AKE protocol
- server_public_key, the public key of the server
- export_key, an additional key

Steps:
1. y = Finalize(password, blind, response.data)
2. contents = response.envelope.contents
3. envelope_nonce = contents.nonce
4. prk = HKDF-Extract(envelope_nonce, Harden(y, params))
5. pseudorandom_pad =
    HKDF-Expand(prk, "Pad", len(contents.encrypted_creds))
6. auth_key = HKDF-Expand(prk, "AuthKey", Nh)
7. export_key = HKDF-Expand(prk, "ExportKey", Nh)
8. Create CleartextCredentials cleartext_creds with response.server_public_key
   and custom identifiers creds.client_identity and creds.server_identity if mode is
   custom_identifier
9. expected_tag = HMAC(auth_key, concat(contents, cleartext_creds))
10. If !ct_equal(response.envelope.auth_tag, expected_tag),
    raise DecryptionError
11. secret_creds = xor(contents.encrypted_creds, pseudorandom_pad)
12. Output (secret_creds.client_private_key, response.server_public_key, export_key)

4.2.  AKE Instantiations

   This section describes instantiations of OPAQUE using 3-message AKEs
   which satisfies the forward secrecy and KCI properties discussed in
   Section 6.  As shown in [OPAQUE], OPAQUE cannot use less than three
   messages so the 3-message instantiations presented here are optimal
   in terms of number of messages.  On the other hand, there is no
   impediment to using OPAQUE with protocols with more than 3 messages
   as in the case of IKEv2 (or the underlying SIGMA-R protocol [SIGMA]).








Krawczyk, et al.         Expires 25 August 2021                [Page 18]


Internet-Draft                   OPAQUE                    February 2021


   The generic outline of OPAQUE with a 3-message AKE protocol includes
   three messages KE1, KE2, and KE3, where KE1 and KE2 include key
   exchange shares, e.g., DH values, sent by client and server,
   respectively, and KE3 provides explicit client authentication and
   full forward security (without it, forward secrecy is only achieved
   against eavesdroppers which is insufficient for OPAQUE security).

   The output of the authentication phase is a session secret
   "session_key" and export key "export_key".  Applications can use
   "session_key" to derive additional keying material as needed.  Key
   derivation and other details of the protocol are specified by the AKE
   scheme.  We note that by the results in [OPAQUE], KE2 and KE3 must
   authenticate credential_request and credential_response,
   respectively, for binding between the underlying OPRF protocol
   messages and the KE session.

   We use the parameters Npk and Nsk to denote the size of the public
   and private keys used in the AKE instantiation.  Npk and Nsk must
   adhere to the output size limitations of the HKDF Expand function
   from [RFC5869], which means that Npk, Nsk <= 255 * Nh.

   The rest of this section includes key schedule utility functions used
   by OPAQUE-3DH, and then provides a detailed specification for OPAQUE-
   3DH, including its wire format messages.

4.2.1.  Key Schedule Utility Functions

   The key derivation procedures for OPAQUE-3DH makes use of the
   functions below, re-purposed from TLS 1.3 [RFC8446].

   HKDF-Expand-Label(Secret, Label, Context, Length) =
     HKDF-Expand(Secret, HkdfLabel, Length)

   Where HkdfLabel is specified as:

   struct {
      uint16 length = Length;
      opaque label<8..255> = "OPAQUE " + Label;
      opaque context<0..255> = Context;
   } HkdfLabel;

   Derive-Secret(Secret, Label, Transcript-Hash) =
       HKDF-Expand-Label(Secret, Label, Transcript-Hash, Nh)

   HKDF uses Hash as its underlying hash function, which is the same as
   that which is indicated by the OPAQUE instantiation.  Note that the
   Label parameter is not a NULL-terminated string.




Krawczyk, et al.         Expires 25 August 2021                [Page 19]


Internet-Draft                   OPAQUE                    February 2021


4.2.2.  OPAQUE-3DH Instantiation

   OPAQUE-3DH is implemented using a suitable prime order group.  All
   operations in the key derivation steps in Section 4.2.2.2 are
   performed in this group and represented here using multiplicative
   notation.  The output of OPAQUE-3DH is a session secret "session_key"
   and export key "export_key".

   The parameters Npk and Nsk are set to be equal to the size of an
   element and scalar, respectively, in the associated prime order
   group.

4.2.2.1.  OPAQUE-3DH Messages

   The three messages for OPAQUE-3DH are described below.

   struct {
     CredentialRequest request;
     uint8 client_nonce[32];
     opaque client_info<0..2^16-1>;
     uint8 client_keyshare[Npk];
   } KE1;

   request  A "CredentialRequest" generated according to
      Section 4.1.2.1.

   client_nonce  A fresh 32-byte randomly generated nonce.

   client_info  Optional application-specific information to exchange
      during the protocol.

   client_keyshare  Client ephemeral key share of fixed size Npk, where
      Npk depends on the corresponding prime order group.

   struct {
     struct {
       CredentialResponse response;
       uint8 server_nonce[32];
       uint8 server_keyshare[Npk];
     } inner_ke2;
     opaque enc_server_info<0..2^16-1>;
     uint8 mac[Nh];
   } KE2;

   response  A "CredentialResponse" generated according to
      Section 4.1.2.2.

   server_nonce  A fresh 32-byte randomly generated nonce.



Krawczyk, et al.         Expires 25 August 2021                [Page 20]


Internet-Draft                   OPAQUE                    February 2021


   server_keyshare  Server ephemeral key share of fixed size Npk, where
      Npk depends on the corresponding prime order group.

   enc_server_info  Optional application-specific information to
      exchange during the protocol encrypted under key Ke2, defined
      below.

   mac  An authentication tag computed over the handshake transcript
      computed using Km2, defined below.

   struct {
     uint8 mac[Nh];
   } KE3;

   mac  An authentication tag computed over the handshake transcript
      computed using Km3, defined below.

4.2.2.2.  OPAQUE-3DH Key Schedule

   OPAQUE-3DH requires MAC keys "server_mac_key" and "client_mac_key"
   and encryption key "handshake_encrypt_key".  Additionally, OPAQUE-3DH
   also outputs "session_key".  The schedule for computing this key
   material is below.

HKDF-Extract(salt=0, IKM)
    |
    +-> Derive-Secret(., "handshake secret", Hash(preamble)) = handshake_secret
    |
    +-> Derive-Secret(., "session secret", Hash(preamble)) = session_key

   From "handshake_secret", Km2, Km3, and Ke2 are computed as follows:

   server_mac_key =
     HKDF-Expand-Label(handshake_secret, "server mac", "", Nh)
   client_mac_key =
     HKDF-Expand-Label(handshake_secret, "client mac", "", Nh)
   handshake_encrypt_key =
     HKDF-Expand-Label(handshake_secret, "handshake enc", "", Nh)

   Nh is the output length of the underlying hash function.

   The Derive-Secret parameter "preamble" is computed as:

   preamble = concat("3DH",
                     I2OSP(len(client_identity), 2), client_identity,
                     KE1,
                     I2OSP(len(server_identity), 2), server_identity,
                     KE2.inner_ke2)



Krawczyk, et al.         Expires 25 August 2021                [Page 21]


Internet-Draft                   OPAQUE                    February 2021


   See Section 6.2 for more information about identities client_identity
   and server_identity.

   Let "epkS" and "eskS" be "server_keyshare" and the corresponding
   secret key, and "epkU" and "eskU" be "client_keyshare" and the
   corresponding secret key.  The input parameter "IKM" the
   concatenation of three DH values computed by the client as follows:

   IKM = concat(epkS^eskU, pkS^eskU, epkS^skU)

   Likewise, "IKM" is computed by the server as follows:

   IKM = concat(epkU^eskS, epkU^skS, pkU^eskS)

4.2.2.3.  OPAQUE-3DH Encryption and Key Confirmation {#3dh-core}

   Clients and servers use keys Km2 and Km3 in computing KE2.mac and
   KE3.mac, respectively.  These values are computed as follows:

   *  KE2.mac = HMAC(Km2, Hash(concat(preamble, KE2.enc_server_info)),
      where preamble is as defined in Section 4.2.2.2.

   *  KE3.mac = HMAC(Km3, Hash(concat(preamble, KE2.enc_server_info,
      KE2.mac)), where preamble is as defined in Section 4.2.2.2.

   The server application info, an opaque byte string "server_info", is
   encrypted using a technique similar to that used for secret
   credential encryption.  Specifically, a one-time-pad is derived from
   Ke2 and then used as input to XOR with the plaintext.  In pseudocode,
   this is done as follows:

   info_pad = HKDF-Expand(Ke2, "encryption pad", len(server_info))
   enc_server_info = xor(info_pad, server_info)

5.  Configurations

   An OPAQUE configuration is a tuple (OPRF, Hash, MHF, EnvelopeMode,
   Group).  The OPAQUE OPRF protocol is drawn from the "base mode"
   variant of [I-D.irtf-cfrg-voprf].  The following OPRF ciphersuites
   are supported:

   *  OPRF(ristretto255, SHA-512)

   *  OPRF(decaf448, SHA-512)

   *  OPRF(P-256, SHA-256)

   *  OPRF(P-384, SHA-512)



Krawczyk, et al.         Expires 25 August 2021                [Page 22]


Internet-Draft                   OPAQUE                    February 2021


   *  OPRF(P-521, SHA-512)

   Future configurations may specify different OPRF constructions.

   The OPAQUE hash function is that which is associated with the OPRF
   ciphersuite.  For the ciphersuites specified here, only SHA-512 and
   SHA-256 are supported.

   The OPAQUE MHFs include Argon2 [I-D.irtf-cfrg-argon2], scrypt
   [RFC7914], and PBKDF2 [RFC2898] with fixed parameter choices.

   The EnvelopeMode value is defined in Section 3.1.  It MUST be one of
   "base" or "custom_identifier".  Future specifications may specify
   alternate EnvelopeMode values and their corresponding Envelope
   structure.

   The Group mode identifies the group used in the OPAQUE-3DH AKE.  This
   SHOULD match that of the OPRF.

6.  Security Considerations

   OPAQUE is defined and proven as the composition of two
   functionalities: an OPRF and an AKE protocol.  It can be seen as a
   "compiler" for transforming any AKE protocol (with KCI security and
   forward secrecy - see below) into a secure aPAKE protocol.  In
   OPAQUE, the client stores a secret private key at the server during
   password registration and retrieves this key each time it needs to
   authenticate to the server.  The OPRF security properties ensure that
   only the correct password can unlock the private key while at the
   same time avoiding potential offline guessing attacks.  This general
   composability property provides great flexibility and enables a
   variety of OPAQUE instantiations, from optimized performance to
   integration with TLS.  The latter aspect is of prime importance as
   the use of OPAQUE with TLS constitutes a major security improvement
   relative to the standard password-over-TLS practice.  At the same
   time, the combination with TLS builds OPAQUE as a fully functional
   secure communications protocol and can help provide privacy to
   account information sent by the client to the server prior to
   authentication.

   The KCI property required from AKE protocols for use with OPAQUE
   states that knowledge of a party's private key does not allow an
   attacker to impersonate others to that party.  This is an important
   security property achieved by most public-key based AKE protocols,
   including protocols that use signatures or public key encryption for
   authentication.  It is also a property of many implicitly
   authenticated protocols, e.g., HMQV, but not all of them.  We also
   note that key exchange protocols based on shared keys do not satisfy



Krawczyk, et al.         Expires 25 August 2021                [Page 23]


Internet-Draft                   OPAQUE                    February 2021


   the KCI requirement, hence they are not considered in the OPAQUE
   setting.  We note that KCI is needed to ensure a crucial property of
   OPAQUE: even upon compromise of the server, the attacker cannot
   impersonate the client to the server without first running an
   exhaustive dictionary attack.  Another essential requirement from AKE
   protocols for use in OPAQUE is to provide forward secrecy (against
   active attackers).

6.1.  Related Analysis

   Jarecki et al.  [OPAQUE] proved the security of OPAQUE in a strong
   aPAKE model that ensures security against pre-computation attacks and
   is formulated in the Universal Composability (UC) framework
   [Canetti01] under the random oracle model.  This assumes security of
   the OPRF function and of the underlying key exchange protocol.  In
   turn, the security of the OPRF protocol from [I-D.irtf-cfrg-voprf] is
   proven in the random oracle model under the One-More Diffie-Hellman
   assumption [JKKX16].

   Very few aPAKE protocols have been proven formally, and those proven
   were analyzed in a weak security model that allows for pre-
   computation attacks (e.g., [GMR06]).  This is not just a formal
   issue: these protocols are actually vulnerable to such attacks.  This
   includes protocols that have recent analyses in the UC model such as
   AuCPace [AuCPace] and SPAKE2+ [SPAKE2plus].  We note that as shown in
   [OPAQUE], these protocols, and any aPAKE in the model from [GMR06],
   can be converted into an aPAKE secure against pre-computation attacks
   at the expense of an additional OPRF execution.

   OPAQUE's design builds on a line of work initiated in the seminal
   paper of Ford and Kaliski [FK00] and is based on the HPAKE protocol
   of Xavier Boyen [Boyen09] and the (1,1)-PPSS protocol from Jarecki et
   al.  [JKKX16].  None of these papers considered security against pre-
   computation attacks or presented a proof of aPAKE security (not even
   in a weak model).

6.2.  Identities

   AKE protocols generate keys that need to be uniquely and verifiably
   bound to a pair of identities.  In the case of OPAQUE, those
   identities correspond to client_identity and server_identity.  Thus,
   it is essential for the parties to agree on such identities,
   including an agreed bit representation of these identities as needed.

   Applications may have different policies about how and when
   identities are determined.  A natural approach is to tie
   client_identity to the identity the server uses to fetch envelope
   (hence determined during password registration) and to tie



Krawczyk, et al.         Expires 25 August 2021                [Page 24]


Internet-Draft                   OPAQUE                    February 2021


   server_identity to the server identity used by the client to initiate
   an offline password registration or online authenticated key exchange
   session. server_identity and client_identity can also be part of the
   envelope or be tied to the parties' public keys.  In principle,
   identities may change across different sessions as long as there is a
   policy that can establish if the identity is acceptable or not to the
   peer.  However, we note that the public keys of both the server and
   the client must always be those defined at the time of password
   registration.

   The client identity (client_identity) and server identity
   (server_identity) are optional parameters that are left to the
   application to designate as monikers for the client and server.  If
   the application layer does not supply values for these parameters,
   then they will be omitted from the creation of the envelope during
   the registration stage.  Furthermore, they will be substituted with
   client_identity = client_public_key and server_identity =
   server_public_key during the authenticated key exchange stage.

   The advantage to supplying a custom client_identity and
   server_identity (instead of simply relying on a fallback to
   client_public_key and server_public_key) is that the client can then
   ensure that any mappings between client_identity and
   client_public_key (and server_identity and server_public_key) are
   protected by the authentication from the envelope.  Then, the client
   can verify that the client_identity and server_identity contained in
   its envelope matches the client_identity and server_identity supplied
   by the server.

   However, if this extra layer of verification is unnecessary for the
   application, then simply leaving client_identity and server_identity
   unspecified (and using client_public_key and server_public_key
   instead) is acceptable.

6.3.  Envelope Encryption

   The analysis of OPAQUE from [OPAQUE] requires the authenticated
   encryption scheme used to produce envelope to have a special property
   called random key-robustness (or key-committing).  This specification
   enforces this property by utilizing encrypt-then-HMAC in the
   construction of the envelope.  There is no option to use another
   authenticated-encryption scheme with this specification.  (Deviating
   from the key-robustness requirement may open the protocol to attacks,
   e.g., [LGR20].)  We remark that export_key for authentication or
   encryption requires no special properties from the authentication or
   encryption schemes as long as export_key is used only after the
   envelope is validated, i.e., after the HMAC in RecoverCredentials
   passes verification.



Krawczyk, et al.         Expires 25 August 2021                [Page 25]


Internet-Draft                   OPAQUE                    February 2021


6.4.  Export Key Usage

   The export key can be used (separately from the OPAQUE protocol) to
   provide confidentiality and integrity to other data which only the
   client should be able to process.  For instance, if the server is
   expected to maintain any client-side secrets which require a password
   to access, then this export key can be used to encrypt these secrets
   so that they remain hidden from the server.

6.5.  Static Diffie-Hellman Oracles

   While one can expect the practical security of the OPRF function
   (namely, the hardness of computing the function without knowing the
   key) to be in the order of computing discrete logarithms or solving
   Diffie-Hellman, Brown and Gallant [BG04] and Cheon [Cheon06] show an
   attack that slightly improves on generic attacks.  For typical
   curves, the attack requires an infeasible number of calls to the OPRF
   or results in insignificant security loss; see [I-D.irtf-cfrg-voprf]
   for more information.  For OPAQUE, these attacks are particularly
   impractical as they translate into an infeasible number of failed
   authentication attempts directed at individual users.

6.6.  Input Validation

   Both client and server MUST validate the other party's public key(s)
   used for the execution of OPAQUE.  This includes the keys shared
   during the offline registration phase, as well as any keys shared
   during the online key agreement phase.  The validation procedure
   varies depending on the type of key.  For example, for OPAQUE
   instantiations using 3DH with P-256, P-384, or P-521 as the
   underlying group, validation is as specified 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, validation MUST ensure
   the Diffie-Hellman shared secret is not the point at infinity.

6.7.  OPRF Hardening

   Hardening the output of the OPRF greatly increases the cost of an
   offline attack upon the compromise of the password file at the
   server.  Applications SHOULD select parameters that balance cost and
   complexity.









Krawczyk, et al.         Expires 25 August 2021                [Page 26]


Internet-Draft                   OPAQUE                    February 2021


6.8.  Client Enumeration

   Client enumeration refers to attacks where the attacker tries to
   learn whether a given client identity is registered with a server.
   Preventing such attacks requires the server to act with unknown
   client identities in a way that is indistinguishable from its
   behavior with existing clients.  Here we suggest a way to implement
   such defense, namely, a way for simulating a CredentialResponse for
   non-existing clients.  Note that if the same CredentialRequest is
   received twice by the server, the response needs to be the same in
   both cases (since this would be the case for real clients).  For
   protection against this attack, one would apply the encryption
   function in the construction of the envelope to all the key material
   in it.  The server S will have two keys MK, MK' for a pseudorandom
   function f. f refers to a regular pseudorandom function such as HMAC
   or CMAC.  Upon receiving a CredentialRequest for a non-existing
   client client_identity, S computes oprf_key=f(MK; client_identity)
   and oprf_key'=f(MK'; client_identity) and responds with
   CredentialResponse carrying Z=M^oprf_key and envelope, where the
   latter is computed as follows. prk is set to oprf_key' and
   secret_creds is set to the all-zero string (of the length of a
   regular envelope plaintext).  Care needs to be taken to avoid side-
   channel leakage (e.g., timing) from helping differentiate these
   operations from a regular server response.  The above requires
   changes to the server-side implementation but not to the protocol
   itself or the client-side.

   There is one form of leakage that the above allows and whose
   prevention would require a change in OPAQUE.  An attacker that
   attempts authentication with the same CredentialRequest twice and
   receives different responses can conclude that either the client
   registered with the service between these two activations or that the
   client was registered before but changed its password in between the
   activations (assuming the server changes oprf_key at the time of a
   password change).  In any case, this indicates that client_identity
   is a registered client at the time of the second activation.  To
   conceal this information, S can implement the derivation of oprf_key
   as oprf_key=f(MK; client_identity) also for registered clients.
   Hiding changes in the envelope, however, requires a change in the
   protocol.  Instead of sending envelope as is, S would send an
   encryption of envelope under a key that the client derives from the
   OPRF result (similarly to prk) and that S stores during password
   registration.  During the authenticated key exchange stage, the
   client will derive this key from the OPRF result, will use it to
   decrypt the envelope, and continue with the regular protocol.  If S
   uses a randomized encryption, the encrypted envelope will look each
   time as a fresh random string, hence S can simulate the encrypted
   envelope also for non-existing clients.



Krawczyk, et al.         Expires 25 August 2021                [Page 27]


Internet-Draft                   OPAQUE                    February 2021


   Note that the first case above does not change the protocol so its
   implementation is a server's decision (the client side is not
   changed).  The second case, requires changes on the client side so it
   changes OPAQUE itself.

   [[https://github.com/cfrg/draft-irtf-cfrg-opaque/issues/22: Should
   this variant be documented/standardized?]]

6.9.  Password Salt and Storage Implications

   In OPAQUE, the OPRF key acts as the secret salt value that ensures
   the infeasibility of pre-computation attacks.  No extra salt value is
   needed.  Also, clients never disclose their passwords to the server,
   even during registration.  Note that a corrupted server can run an
   exhaustive offline dictionary attack to validate guesses for the
   client's password; this is inevitable in any aPAKE protocol.  (OPAQUE
   enables defense against such offline dictionary attacks by
   distributing the server so that an offline attack is only possible if
   all - or a minimal number of - servers are compromised [OPAQUE].)

   Some applications may require learning the client's password for
   enforcing password rules.  Doing so invalidates this important
   security property of OPAQUE and is NOT RECOMMENDED.  Applications
   should move such checks to the client.  Note that limited checks at
   the server are possible to implement, e.g., detecting repeated
   passwords.

7.  IANA Considerations

   This document makes no IANA requests.

8.  References

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

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.

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



Krawczyk, et al.         Expires 25 August 2021                [Page 28]


Internet-Draft                   OPAQUE                    February 2021


8.2.  Informative References

   [AuCPace]  Haase, B. and B. Labrique, "AuCPace: Efficient verifier-
              based PAKE protocol tailored for the IIoT",
              http://eprint.iacr.org/2018/286 , 2018.

   [BG04]     Brown, D. and R. Galant, "The static Diffie-Hellman
              problem", http://eprint.iacr.org/2004/306 , 2004.

   [Boyen09]  Boyen, X., "HPAKE: Password Authentication Secure against
              Cross-Site User Impersonation", Cryptology and Network
              Security (CANS) , 2009.

   [Canetti01]
              Canetti, R., "Universally composable security: A new
              paradigm for cryptographic protocols", IEEE Symposium on
              Foundations of Computer Science (FOCS) , 2001.

   [Cheon06]  Cheon, J.H., "Security analysis of the strong Diffie-
              Hellman problem", Euroctypt 2006 , 2006.

   [FK00]     Ford, W. and B.S. Kaliski, Jr, "Server-assisted generation
              of a strong secret from a password", WETICE , 2000.

   [GMR06]    Gentry, C., MacKenzie, P., and . Z, Ramzan, "A method for
              making password-based key exchange resilient to server
              compromise", CRYPTO , 2006.

   [HMQV]     Krawczyk, H., "HMQV: A high-performance secure Diffie-
              Hellman protocol", CRYPTO , 2005.

   [I-D.irtf-cfrg-argon2]
              Biryukov, A., Dinu, D., Khovratovich, D., and S.
              Josefsson, "The memory-hard Argon2 password hash and
              proof-of-work function", Work in Progress, Internet-Draft,
              draft-irtf-cfrg-argon2-12, 8 September 2020,
              <http://www.ietf.org/internet-drafts/draft-irtf-cfrg-
              argon2-12.txt>.

   [I-D.irtf-cfrg-hash-to-curve]
              Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R., and
              C. Wood, "Hashing to Elliptic Curves", Work in Progress,
              Internet-Draft, draft-irtf-cfrg-hash-to-curve-10, 11
              October 2020, <http://www.ietf.org/internet-drafts/draft-
              irtf-cfrg-hash-to-curve-10.txt>.






Krawczyk, et al.         Expires 25 August 2021                [Page 29]


Internet-Draft                   OPAQUE                    February 2021


   [I-D.irtf-cfrg-voprf]
              Davidson, A., Faz-Hernandez, A., Sullivan, N., and C.
              Wood, "Oblivious Pseudorandom Functions (OPRFs) using
              Prime-Order Groups", Work in Progress, Internet-Draft,
              draft-irtf-cfrg-voprf-05, 2 November 2020,
              <http://www.ietf.org/internet-drafts/draft-irtf-cfrg-
              voprf-05.txt>.

   [I-D.sullivan-tls-opaque]
              Sullivan, N., Krawczyk, H., Friel, O., and R. Barnes,
              "Usage of OPAQUE with TLS 1.3", Work in Progress,
              Internet-Draft, draft-sullivan-tls-opaque-00, 11 March
              2019, <http://www.ietf.org/internet-drafts/draft-sullivan-
              tls-opaque-00.txt>.

   [JKKX16]   Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu,
              "Highly-efficient and composable password-protected secret
              sharing (or: how to protect your bitcoin wallet online)",
              IEEE European Symposium on Security and Privacy , 2016.

   [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", n.d.,
              <https://eprint.iacr.org/2020/1491.pdf>.

   [OPAQUE]   Jarecki, S., Krawczyk, H., and J. Xu, "OPAQUE: An
              Asymmetric PAKE Protocol Secure Against Pre-Computation
              Attacks", Eurocrypt , 2018.

   [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
              Specification Version 2.0", RFC 2898,
              DOI 10.17487/RFC2898, September 2000,
              <https://www.rfc-editor.org/info/rfc2898>.

   [RFC2945]  Wu, T., "The SRP Authentication and Key Exchange System",
              RFC 2945, DOI 10.17487/RFC2945, September 2000,
              <https://www.rfc-editor.org/info/rfc2945>.







Krawczyk, et al.         Expires 25 August 2021                [Page 30]


Internet-Draft                   OPAQUE                    February 2021


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

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <https://www.rfc-editor.org/info/rfc7250>.

   [RFC7914]  Percival, C. and S. Josefsson, "The scrypt Password-Based
              Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
              August 2016, <https://www.rfc-editor.org/info/rfc7914>.

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

   [RFC8125]  Schmidt, J., "Requirements for Password-Authenticated Key
              Agreement (PAKE) Schemes", RFC 8125, DOI 10.17487/RFC8125,
              April 2017, <https://www.rfc-editor.org/info/rfc8125>.

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

   [SIGMA]    Krawczyk, H., "SIGMA: The SIGn-and-MAc approach to
              authenticated Diffie-Hellman and its use in the IKE
              protocols", CRYPTO , 2003.

   [SIGNAL]   "Signal recommended cryptographic algorithms",
              https://signal.org/docs/specifications/
              doubleratchet/#recommended-cryptographic-algorithms ,
              2016.

   [SPAKE2plus]
              Shoup, V., "Security Analysis of SPAKE2+",
              http://eprint.iacr.org/2020/313 , 2020.











Krawczyk, et al.         Expires 25 August 2021                [Page 31]


Internet-Draft                   OPAQUE                    February 2021


Appendix A.  Acknowledgments

   The OPAQUE protocol and its analysis is joint work of the author with
   Stas Jarecki and Jiayu Xu.  We are indebted to the OPAQUE reviewers
   during CFRG's aPAKE selection process, particularly Julia Hesse and
   Bjorn Tackmann.  This draft has benefited from comments by multiple
   people.  Special thanks to Richard Barnes, Dan Brown, Eric Crockett,
   Paul Grubbs, Fredrik Kuivinen, Payman Mohassel, Jason Resch, Greg
   Rubin, and Nick Sullivan.

Appendix B.  Alternate AKE Instantiations

   It is possible to instantiate OPAQUE with other AKEs, such as HMQV
   [HMQV] and SIGMA-I.  HMQV is similar to 3DH but varies in its key
   schedule.  SIGMA-I uses digital signatures rather than static DH keys
   for authentication.  Specification of these instantiations is left to
   future documents.  A sketch of how these instantiations might change
   is included in the next subsection for posterity.

   The AKE private key size (Nsk) is limited to the output size of the
   HKDF Expand function from [RFC5869].  Future specifications which
   have keys exceeding this size should specify a mechanism by which
   private keys and their corresponding public keys can be
   deterministically derived from a fixed-length seed.

   OPAQUE may also be instantiated with any post-quantum (PQ) AKE
   protocol that has the message flow above and security properties (KCI
   resistance and forward secrecy) outlined in Section 6.  Note that
   such an instantiation is not quantum-safe unless the OPRF is quantum-
   safe.  However, an OPAQUE instantiation where the AKE is quantum-
   safe, but the OPRF is not, would still ensure the confidentiality of
   application data encrypted under session_key (or a key derived from
   it) with a quantum-safe encryption function.

B.1.  HMQV Instantiation Sketch

   An HMQV instantiation would work similar to OPAQUE-3DH, differing
   primarily in the key schedule [HMQV].  First, the key schedule
   "preamble" value would use a different constant prefix - "HMQV"
   instead of "3DH" - as shown below.

   preamble = concat("HMQV",
                     I2OSP(len(client_identity), 2), client_identity,
                     KE1,
                     I2OSP(len(server_identity), 2), server_identity,
                     KE2.inner_ke2)





Krawczyk, et al.         Expires 25 August 2021                [Page 32]


Internet-Draft                   OPAQUE                    February 2021


   Second, the IKM derivation would change.  Assuming HMQV is
   instantiated with a cyclic group of prime order p with bit length L,
   clients would compute "IKM" as follows:

   u' = (eskU + u \* skU) mod p
   IKM = (epkS \* pkS^s)^u'

   Likewise, servers would compute "IKM" as follows:

   s' = (eskS + s \* skS) mod p
   IKM = (epkU \* pkU^u)^s'

   In both cases, "u" would be computed as follows:

   hashInput = concat(I2OSP(len(epkU), 2), epkU,
                      I2OSP(len(info), 2), info,
                      I2OSP(len("client"), 2), "client")
   u = Hash(hashInput) mod L

   Likewise, "s" would be computed as follows:

   hashInput = concat(I2OSP(len(epkS), 2), epkS,
                      I2OSP(len(info), 2), info,
                      I2OSP(len("server"), 2), "server")
   s = Hash(hashInput) mod L

   Hash is the same hash function used in the main OPAQUE protocol for
   key derivation.  Its output length (in bits) must be at least L.

B.2.  SIGMA-I Instantiation Sketch

   A SIGMA-I instantiation differs more drastically from OPAQUE-3DH,
   since authentication uses digital signatures in lieu of Diffie
   Hellman.  In particular, both KE2 and KE3 would carry a digital
   signature, computed using the server and client private keys
   established during registration, respectively, as well as a MAC,
   where the MAC is computed as in OPAQUE-3DH.

   The key schedule would also change.  Specifically, the key schedule
   "preamble" value would use a different constant prefix - "SIGMA-I"
   instead of "3DH" - and the "IKM" computation would use only the
   ephemeral key shares exchanged between client and server.









Krawczyk, et al.         Expires 25 August 2021                [Page 33]


Internet-Draft                   OPAQUE                    February 2021


Appendix C.  Test Vectors

   This section contains test vectors for the OPAQUE-3DH specification.
   Each test vector specifies the configuration information, protocol
   inputs, intermediate values computed during registration and
   authentication, and protocol outputs.  All values are encoded in
   hexadecimal strings.  The configuration information includes the
   (OPRF, Hash, MHF, EnvelopeMode, Group) tuple, where the Group matches
   that which is used in the OPRF.  These test vectors were generated
   using draft-06 of [I-D.irtf-cfrg-voprf].

C.1.  OPAQUE-3DH Test Vector 1

C.1.1.  Configuration

   OPRF: 0001
   Hash: SHA512
   SlowHash: Identity
   EnvelopeMode: 01
   Group: ristretto255
   Nh: 64
   Npk: 32
   Nsk: 32

C.1.2.  Input Values


























Krawczyk, et al.         Expires 25 August 2021                [Page 34]


Internet-Draft                   OPAQUE                    February 2021


   password: 436f7272656374486f72736542617474657279537461706c65
   envelope_nonce: cc7abb200199d5071c94efa49fb62435d3e70d03cf9573a95da54
   20d3eebcd2b
   client_private_key: 8bcb0b70dac18de24eef12e737d6b28724d3e37774e0b092f
   9f70b255defaf04
   client_public_key: 360e716c676cfe4d9968d1a352ed3faf17603863e0a7aa1905
   df6ea129343b09
   server_private_key: f3a0829898a89239dce29ccc98ec8b449a34b255ba1e6f944
   829d18e0d589b0f
   server_public_key: 66e130c6eb5b41f851b235b03a0eafeaa883f64147bc62cb74
   9c22c762389c3c
   client_info: 68656c6c6f20626f62
   server_info: 6772656574696e677320616c696365
   server_nonce: 98b8081059f60ffed9336f026fd8e124737205ac73f5348ae5bebdb
   49456c70f
   client_nonce: 58dc21475ff730342f807bf031c7ae47a11f0d4dfaa63a7feb15d7e
   36427ca44
   server_keyshare: 5214e3ddc73db786480b79fa2da787f2080b82cbe922c2a9592b
   44597d9a702e
   client_keyshare: a4084c7296b1a3d5a5e4a24358750489575acfd8fcfa6e787492
   b98265a5e651
   server_private_keyshare: c4d002aa4cfcf281657cf36fe562bc60d9133e0e72a7
   4432f685b2b6a4b42a0c
   client_private_keyshare: de2e98f422bf7b99be19f7da7cac62f1599d35a225ec
   6340149a0aaff3102003
   blind_registration: 7e5bcbf82a46109ee0d24e9bcab41fc830a6ce8b82fc1e921
   3a043b743b95800
   blind_login: c4d5a15f0d5ffc354e340454ec779f575e4573a3886ab5e57e4da298
   4bdd5306
   oprf_key: 080d0a4d352de92672ab709b1ae1888cb48dfabc2d6ca5b914b335512fe
   70508

C.1.3.  Intermediate Values


















Krawczyk, et al.         Expires 25 August 2021                [Page 35]


Internet-Draft                   OPAQUE                    February 2021


   auth_key: 7bb7f2b831ee30d3e5cc4012c8f721a4d8f9dd494932d53776e043df9bd
   2aa284025b8b006fd8449536446ff50698f46c73fccb53f20d80898f185307d1d39e5
   prk: b0aefddbb21d1b97bc40c07b172e0bf172ec740de4f6274f69d46350a447e9b1
   b3fb1e4cefc7d8e393ff58a5c45c74d0615ee0eecde116f3d4e744142eb2ee89
   pseudorandom_pad: 36a828b3b57bf242c4c47ccd9cb84e5b3cefaffe09629c6b94d
   eba0ccec5fa39
   envelope: 01cc7abb200199d5071c94efa49fb62435d3e70d03cf9573a95da5420d3
   eebcd2bbd6323c36fba7fa08a2b6e2aab6efcdc183c4c897d822cf96d29b129932a55
   3d469ffa9999fcbd37a1e8b6c1e579bcf83fed355c9ff413e6158d72d16f3ccd8699e
   906027842694b6293b6303bbb7f324e0fccb4ae0f01edb60ee1d32992696e
   handshake_secret: 2b041dcf12ac9b75dded88f891c25d76746ce9e2c1a43118ac4
   aa5721cdc1bc2f0691e6c012a1ea9eb95ab4899b3e7058d37fe9546c46b0511877e40
   f55aac6c
   handshake_encrypt_key: ceef10f15d869a4cea8174fa98d0d96c7aaf8602d006fe
   0c5274a40173db76cac820138c5890bb63fb974d1e3e925850cc2464e2c10f0a9a776
   9a45e80889b1e
   server_mac_key: f8fd7fdc349b5ae1339515e05912c89a795f561a117cdc84d8d8b
   5f05b05751abfb87fa01c799c5d367244d1e32eab67ff926833c6025c556acffa4af1
   f3871a
   client_mac_key: 92a30cc82c374c06895aa07e81f0cf5f25309a24b595faefcd225
   1f9219b47e47d17da4fe8b572dedefa350ed365f87b217973e90d0b647a2ccf1d796a
   8970f6

C.1.4.  Output Values



























Krawczyk, et al.         Expires 25 August 2021                [Page 36]


Internet-Draft                   OPAQUE                    February 2021


   registration_request: ec9027daa5e9a901d641286a7ded51364142936ac7636e1
   42e3f4368b4bd8124
   registration_response: 8867d7c8c2c576a6322d49d46078ea32f479aed917c70a
   636d3ada4397ea1c0e66e130c6eb5b41f851b235b03a0eafeaa883f64147bc62cb749
   c22c762389c3c
   registration_upload: 360e716c676cfe4d9968d1a352ed3faf17603863e0a7aa19
   05df6ea129343b0901cc7abb200199d5071c94efa49fb62435d3e70d03cf9573a95da
   5420d3eebcd2bbd6323c36fba7fa08a2b6e2aab6efcdc183c4c897d822cf96d29b129
   932a553d469ffa9999fcbd37a1e8b6c1e579bcf83fed355c9ff413e6158d72d16f3cc
   d8699e906027842694b6293b6303bbb7f324e0fccb4ae0f01edb60ee1d32992696e
   KE1: e06a32011e1b1704eb686b263e5d132fff4e9f6429cd93b98db107485006792c
   58dc21475ff730342f807bf031c7ae47a11f0d4dfaa63a7feb15d7e36427ca4400096
   8656c6c6f20626f62a4084c7296b1a3d5a5e4a24358750489575acfd8fcfa6e787492
   b98265a5e651
   KE2: 66f6b5fa1a4eb6bd7a0c93ed2639a31cba0d02e2df744003641d5a30a4a12364
   66e130c6eb5b41f851b235b03a0eafeaa883f64147bc62cb749c22c762389c3c01cc7
   abb200199d5071c94efa49fb62435d3e70d03cf9573a95da5420d3eebcd2bbd6323c3
   6fba7fa08a2b6e2aab6efcdc183c4c897d822cf96d29b129932a553d469ffa9999fcb
   d37a1e8b6c1e579bcf83fed355c9ff413e6158d72d16f3ccd8699e906027842694b62
   93b6303bbb7f324e0fccb4ae0f01edb60ee1d32992696e98b8081059f60ffed9336f0
   26fd8e124737205ac73f5348ae5bebdb49456c70f5214e3ddc73db786480b79fa2da7
   87f2080b82cbe922c2a9592b44597d9a702e000f72f38a0945819089c44c86820c51d
   89cc35f77df03d330101bbed3b2f69066112f32529bdda0998657350fc9f8da4cde73
   408ad931f4c2ea6237ccae4696483388b174f50cf96d439139b0f8680c3b
   KE3: 9f0e4f73455ca9fe06bb52ad02670b09be5a03db11a73be4422f19963be082b0
   eb55871022e8d1d87adc3ab50de7c738058eb659866d091648f2fed12e23fd53
   export_key: 66c0b72aa829f13a166fb1a1168f1e26023921f0eed1126def4f81ba0
   4924ad6012e42b63656ec199ba27670d1e7f23dc0a927714edc140134dde5a5d2063d
   fc
   session_key: 951c2bb1b876725fa7d3829db791dddd406a688507b47e24101bd0cc
   5d071760b6fba59e8758a6ea6d7e5f51a715b49a47c50fee9a7c8a0451243c3ee837f
   d30

C.2.  OPAQUE-3DH Test Vector 2

C.2.1.  Configuration

   OPRF: 0002
   Hash: SHA512
   SlowHash: Identity
   EnvelopeMode: 01
   Group: decaf448
   Nh: 64
   Npk: 56
   Nsk: 56

C.2.2.  Input Values




Krawczyk, et al.         Expires 25 August 2021                [Page 37]


Internet-Draft                   OPAQUE                    February 2021


   password: 436f7272656374486f72736542617474657279537461706c65
   envelope_nonce: a3810457d65c1f14524f6a9fc0ad0d43c17732ae2f159e64aeeaf
   c56dd63a49c
   client_private_key: 614bb578f29cc677ea9e7aea3e4839413997e020f9377b63c
   13584156a09a46dd2a425c41eac0e313a47e99d05df72c6e1d58e6592577a0d
   client_public_key: a8f6d7dad9ec587964d6dffb1b63f951dc30a934137eb42057
   f390d593dfafb6a687ec5c3ad3c35bb6a71338dc8106bd53b3a4fcec6110a1
   server_private_key: 4c115060bca87db7d73e00cbb8559f84cb7a221b235b0950a
   0ab553f03f10e1386abe954011b7da62bb6599418ef90b5d4ea98cc28aff517
   server_public_key: bc66494bf44cdfed66f6b4c482a18e00a3d16a09d11775064f
   963cc7bae3b6592a6b03fb982f5b5676972005a29d1dcfd46b6986088ca9d4
   client_info: 68656c6c6f20626f62
   server_info: 6772656574696e677320616c696365
   server_nonce: f1b33f774f5166cde92f150e2bebf58bbd5f194a7e48ceb6078b235
   e185af474
   client_nonce: b7b96900d3092b9547505710da9762561ed69da9dd1a5444c6215de
   6fa2a40f8
   server_keyshare: 5472ca0fc98d652ded1ba4edc7d876a791b2c2a61c1201ffe354
   8e0f3a1d479e1629a35a7f910ef27f46c93ade70ee4cbdf9a2183f6d0754
   client_keyshare: 46770873fdab1e43177a9f1b2d127a44e0b4c2becf3ac4545248
   ef410d143cce32f76df27f47cf19347b42e3cd1f9432cda204701e188c32
   server_private_keyshare: 0676f161ab555182908dbd7947b1c988956fa73b17b3
   73b72fd4e3c0264a26aa4cab20fd864de6ceab345e8d755997956ddd1f265e8be105
   client_private_keyshare: d0f08ac99ef2ab5b26fa7b2a6d920c76cf03fb57bdea
   cc2ec39330fd6e7f9e5dbdfcb571168f337dd52851d4bc07947c858dc735bab8ca2b
   blind_registration: a614f1894bcf6a1c7cef33909b794fe6e69a642b20f4c9118
   febffaf6b6a31471fe7794aa77ced123f07e56cc27de60b0ab106c0b8eab127
   blind_login: 668b3aab5207735beb86c5379228da260159dc24f7c5c2483a81aff8
   d9ff676ebd81db28eb1e147561c478a3f84cbf77037f01025c7fd42a
   oprf_key: 93dd2d051e90efe4e2e093bc1e82b80e8cce6afa798ac214abffabac2a2
   58015d93e9faf0f2009d16c797646097d761e2b84e0df971d7b39

C.2.3.  Intermediate Values


















Krawczyk, et al.         Expires 25 August 2021                [Page 38]


Internet-Draft                   OPAQUE                    February 2021


   auth_key: 79ba15aa7db6b18f4d737be4dee7d5f186c235e4f8ec865513af292c056
   b86e93bb8ebe2915fe0f43187e7cbd4bb94661ceb6496cbc877d598d001296defd7a3
   prk: 67292e51a7da30331f94411e51ad6c03cdd2e0c5fce4c6a125cdf8cff688b9f5
   100a5def2c0ef959db505ea09e81c43afc1450ed767de9d2cbc9f93fb7a306a9
   pseudorandom_pad: 4b1221753544450748eda40790e4712480e36c451db367025d6
   6843df9d916bf2c94696c60b951bf984f71d2b8d70d5980aacb9602a12af7
   envelope: 01a3810457d65c1f14524f6a9fc0ad0d43c17732ae2f159e64aeeafc56d
   d63a49c2a59940dc7d88370a273deedaeac4865b9748c65e4841c619c53002893d0b2
   d2fe304ca87e155f8ea208984fbd087f9f617f45f390f650fac6b3a40c7e6b1d4b8c5
   5b0575eac0f323c99337c232fad2dc07538eacebd947516a97ac420aa1f1851a20552
   4e5dda112d0d949f3003777c47ff0724e8b0aed6
   handshake_secret: 830f54c125468f05d8403f455ab1440885602e3dacab1e0a69b
   0c6664eac71991e65049e215a5abda52d8960d4c68c58b5003afda0cd59e2487bfa60
   5e42f209
   handshake_encrypt_key: e29949872e78acfc53c7eda5d0bb30364c128ef5f69d02
   efa3d18d08f7b1ca79fda1da3ed12ee796585845d804a961e29451755a8e7cb43c28f
   bcc028903be05
   server_mac_key: b12f274b224ff2bc1413ac87d52d4059da2af57375514cc43eeb4
   e9ef602eddc149f7c8ca8afbe403e0997b859034bd304efd3d51750b1c38eccacfe78
   5b17f0
   client_mac_key: 9216883df807ee47d405443aaf990d2712b30ed400079ae54375a
   51d1ced956c4153853e50bda1f1cf8e5323df3d9418b9d91e9be9cd4eb0b5efdc76e5
   ad1c01

C.2.4.  Output Values


























Krawczyk, et al.         Expires 25 August 2021                [Page 39]


Internet-Draft                   OPAQUE                    February 2021


   registration_request: d21b318acf1b255d0f009bf3cb24b7b2f88cb58880775b8
   dff43a81ab49fe73f0356b70ff3e5c251bc9810767c98491d8187d2cf11dff618
   registration_response: c023432da8f17d6e5e740d9d1a0fb55dbc8e1830bd72ec
   2e1f59da065858170b05c1f711ca085d8cf5a52ae1ea5198196bd9907dca045c6fbc6
   6494bf44cdfed66f6b4c482a18e00a3d16a09d11775064f963cc7bae3b6592a6b03fb
   982f5b5676972005a29d1dcfd46b6986088ca9d4
   registration_upload: a8f6d7dad9ec587964d6dffb1b63f951dc30a934137eb420
   57f390d593dfafb6a687ec5c3ad3c35bb6a71338dc8106bd53b3a4fcec6110a101a38
   10457d65c1f14524f6a9fc0ad0d43c17732ae2f159e64aeeafc56dd63a49c2a59940d
   c7d88370a273deedaeac4865b9748c65e4841c619c53002893d0b2d2fe304ca87e155
   f8ea208984fbd087f9f617f45f390f650fac6b3a40c7e6b1d4b8c55b0575eac0f323c
   99337c232fad2dc07538eacebd947516a97ac420aa1f1851a205524e5dda112d0d949
   f3003777c47ff0724e8b0aed6
   KE1: 30a31f471b8adc9e3fcb796a6ee1ee97edabf6a77468c58621a0cfaecee3c1ac
   1a1dbe16a0fbf6fc4d2f882d8431303bded7a16d207f840cb7b96900d3092b9547505
   710da9762561ed69da9dd1a5444c6215de6fa2a40f8000968656c6c6f20626f624677
   0873fdab1e43177a9f1b2d127a44e0b4c2becf3ac4545248ef410d143cce32f76df27
   f47cf19347b42e3cd1f9432cda204701e188c32
   KE2: 2453710eb7a3226bfedb501efe06772d9450aa9ba9eed8adddd931964364e3d3
   d5d2a22822f0d85569fa396b8e9c6657ff5115dbd4c0a218bc66494bf44cdfed66f6b
   4c482a18e00a3d16a09d11775064f963cc7bae3b6592a6b03fb982f5b5676972005a2
   9d1dcfd46b6986088ca9d401a3810457d65c1f14524f6a9fc0ad0d43c17732ae2f159
   e64aeeafc56dd63a49c2a59940dc7d88370a273deedaeac4865b9748c65e4841c619c
   53002893d0b2d2fe304ca87e155f8ea208984fbd087f9f617f45f390f650fac6b3a40
   c7e6b1d4b8c55b0575eac0f323c99337c232fad2dc07538eacebd947516a97ac420aa
   1f1851a205524e5dda112d0d949f3003777c47ff0724e8b0aed6f1b33f774f5166cde
   92f150e2bebf58bbd5f194a7e48ceb6078b235e185af4745472ca0fc98d652ded1ba4
   edc7d876a791b2c2a61c1201ffe3548e0f3a1d479e1629a35a7f910ef27f46c93ade7
   0ee4cbdf9a2183f6d0754000f33baf0c6e2bcaa8a7155309d0b41d29d94469ac63cb5
   9f2d54c81f8c445303d666eabe6a505aa7f5cab2d133c0bd40a951a56c9f2cb4f04e3
   3ebae80858691b3799ecd1caf1be781f6f6e4c212661f
   KE3: ae29171538fb3a9b3e643ec4812218f6e17038314b9a62e87ef2c72e82ed69a8
   86c6f89ee2646dbb742905d88ed481894dd52f6acc3b31c0dbd46ba58bf0841d
   export_key: 095d3246344474969774de1d7e21ea4835975c7dde152e446cf989a10
   d9c8444e432fb65504dd80c2d4c2fa31203764c0fa4a15128541a8474f7c45119673e
   16
   session_key: 354a951281611e3b2ec14bf9b19325be441dc3395f4cc99838330071
   5fdbacd282be642cb97f1e88f640c80b85452680aac8938970c1db61e398e87d9f0e9
   2c5

C.3.  OPAQUE-3DH Test Vector 3

C.3.1.  Configuration








Krawczyk, et al.         Expires 25 August 2021                [Page 40]


Internet-Draft                   OPAQUE                    February 2021


   OPRF: 0003
   Hash: SHA256
   SlowHash: Identity
   EnvelopeMode: 01
   Group: P256_XMD:SHA-256_SSWU_RO_
   Nh: 32
   Npk: 33
   Nsk: 32

C.3.2.  Input Values

   password: 436f7272656374486f72736542617474657279537461706c65
   envelope_nonce: d07d294b6e901c4d5b76c7097a56dd893c47a236c7e0a275b5819
   48f77f28abb
   client_private_key: 67b5bcebad6393e2d0b7db3d2b4597a670a5204b2b606f5a2
   8328916e1e5ea5b
   client_public_key: 030e2b9005157dfd740a13c9525a2132512a463927174d9728
   0f80f962d1a650e3
   server_private_key: fc2e715b2db1e7a3ad4ff8af1b24daa1922d13757ac9df4ad
   c7e4e0b6b399433
   server_public_key: 03ca5ebe2c9b87ff1e76e2e72f8a59273fe5c9688fee7dd2f2
   8964187a0940c397
   client_info: 68656c6c6f20626f62
   server_info: 6772656574696e677320616c696365
   server_nonce: dc70522e4b7fb4c433ca014299328213a829cbf89e12fb3bfa08bc6
   53fa3cbc9
   client_nonce: 06eaf939cc8064e7d2c454faf5342f43c59b0974b55a965cf5b8ce3
   52551d137
   server_keyshare: 03a716d72106b7ad668ae097e553a46f4dd96961816fbe8e2243
   43a7f0ab95a05a
   client_keyshare: 037086638b1beb10b9a6a44ea0ee5b369081004df36cba0c16c8
   d485482de57ff6
   server_private_keyshare: a6532c99c1ea3f03d05f6e78dc1edabd3b9631be9f8b
   274d9aaf671bfb6a7753
   client_private_keyshare: 29bf435021b89c683259773bc686956af0c7822ba317
   fb5e86028c44b92bd3af
   blind_registration: 3e7c5057e09e220065ea8c257c0dd6055c4b401063eff0bf2
   42b4cd534a79bad
   blind_login: dcf6744d388ca013ef33edd369304ed96fc56c7c6c0bd369f8e926ff
   e4854a59
   oprf_key: f6b3e908bdb38e3c626a939e19daca653b9217801b5d51cef66d9fdbd94
   a5354

C.3.3.  Intermediate Values







Krawczyk, et al.         Expires 25 August 2021                [Page 41]


Internet-Draft                   OPAQUE                    February 2021


   auth_key: 226ffbc20f19c9d956d1f172bd5c9b1bb475716b6438aedfdcc559756ee
   236f7
   prk: 4d00010592e76a29c3173d883e94b55af3802c85983bb1374407a226a374cff4
   pseudorandom_pad: 0123cec727a51fecb61d447f04fac3591299cd50bf55cf55334
   2f1f7fc0b1e07
   envelope: 01d07d294b6e901c4d5b76c7097a56dd893c47a236c7e0a275b581948f7
   7f28abb6696722c8ac68c0e66aa9f422fbf54ff623ced1b9435a00f1b7078e11deef4
   5cd47baf68df4d4eb20b76f04f8dbaba219bf0f4e5c6d47bf2b4bf5fe23e724bff
   handshake_secret: 4d80ee40c7a11a9c4b27ca9ee6e38797322a9e3c904b3e35c8a
   00bbad403029d
   handshake_encrypt_key: 244d132b27991dafff260364681ff473472249ea2ae625
   c223144b97ca754c44
   server_mac_key: 99f2a9e5af84a221b3efeda5a5bb5372a587462a5585f33ea0c85
   67aedcf03ea
   client_mac_key: f86379af46726649af600c69dacaa96ed967eac0f91225ae00c68
   1d86884408a

C.3.4.  Output Values

   registration_request: 0295067c743d15a0a9d4c6c15511b67e3858e9e22f8c44a
   0c1de6e33cda494024b
   registration_response: 02465cd175b404fc1426b3b9518a79ee219007679909f4
   59f92cfc89929c89458e03ca5ebe2c9b87ff1e76e2e72f8a59273fe5c9688fee7dd2f
   28964187a0940c397
   registration_upload: 030e2b9005157dfd740a13c9525a2132512a463927174d97
   280f80f962d1a650e301d07d294b6e901c4d5b76c7097a56dd893c47a236c7e0a275b
   581948f77f28abb6696722c8ac68c0e66aa9f422fbf54ff623ced1b9435a00f1b7078
   e11deef45cd47baf68df4d4eb20b76f04f8dbaba219bf0f4e5c6d47bf2b4bf5fe23e7
   24bff
   KE1: 0230e8f9b3689b65b952bf044702673c4d5278119b25d3833a3de655b9289f89
   e106eaf939cc8064e7d2c454faf5342f43c59b0974b55a965cf5b8ce352551d137000
   968656c6c6f20626f62037086638b1beb10b9a6a44ea0ee5b369081004df36cba0c16
   c8d485482de57ff6
   KE2: 025c6387cee347fa24a57c7021890ee13f435ea5e92b20fb488c3984e060ad4d
   6f03ca5ebe2c9b87ff1e76e2e72f8a59273fe5c9688fee7dd2f28964187a0940c3970
   1d07d294b6e901c4d5b76c7097a56dd893c47a236c7e0a275b581948f77f28abb6696
   722c8ac68c0e66aa9f422fbf54ff623ced1b9435a00f1b7078e11deef45cd47baf68d
   f4d4eb20b76f04f8dbaba219bf0f4e5c6d47bf2b4bf5fe23e724bffdc70522e4b7fb4
   c433ca014299328213a829cbf89e12fb3bfa08bc653fa3cbc903a716d72106b7ad668
   ae097e553a46f4dd96961816fbe8e224343a7f0ab95a05a000f2519167d418dc3c7ea
   cd8cae6a55c483bef6d2f7a67d48ce30701d858da6caec7cdf7cac7990777eb410591
   612736e
   KE3: 5ef3c7290d3af42afdfc6b87af044c00ec8177e34d9a9464b8eb4c033424ad82
   export_key: a5d8bb0d880b6b5bdfda31d2f01b695435bccbb57a5f8efd5dae1e46b
   2a959c4
   session_key: b6bece8471d280561dc969b22607b29c2836d1ca9a49e81a15ddb85c
   467662e7




Krawczyk, et al.         Expires 25 August 2021                [Page 42]


Internet-Draft                   OPAQUE                    February 2021


C.4.  OPAQUE-3DH Test Vector 4

C.4.1.  Configuration

   OPRF: 0004
   Hash: SHA512
   SlowHash: Identity
   EnvelopeMode: 01
   Group: P384_XMD:SHA-512_SSWU_RO_
   Nh: 64
   Npk: 49
   Nsk: 48

C.4.2.  Input Values

   password: 436f7272656374486f72736542617474657279537461706c65
   envelope_nonce: 22bc649eec25874f87e625008d252fceffbb8b434327914db6c09
   d07b7f3bf19
   client_private_key: f3cfa0420080cbff2e3431bcc25f80b409c533dd21924d77b
   cbd10873989b7e58306b863276ae74049615162a416d508
   client_public_key: 02c86369d6eae0978bdd4030b43e0619ce46ea9d91fa6e0e75
   75bb12aa4857db98b952d8af9d92f75899c49d0d18793c1e
   server_private_key: 2902c13bdc9993d3717bda68fc080b9802ae4effd5dc972d9
   f9fb3bbbf106add174393effaf0a175fa8e85f898568620
   server_public_key: 0251f78cbd5c7a3fbf4cdaeb755eb8cc4159edb0ef38baebb5
   03dbefed5c89c14f7c2b99ed242b3d1de890f7515bad94bd
   client_info: 68656c6c6f20626f62
   server_info: 6772656574696e677320616c696365
   server_nonce: 7e4c5d3a4f779d5966cc8ca367e47e0716ad0f33aa100fe68507920
   a1a6e3578
   client_nonce: af0eb9b48c985e2ba859ce089fc342c648ddadfca4735f5b2e631ee
   a7fdf967b
   server_keyshare: 035684e8cdae6ce360c2d3f41e4b059f34f986e92dd50c8255f7
   d7dc0c16252ef9b8c9fb9e0c2846053355e7fcfa46781f
   client_keyshare: 027044d31354b5b98587d7d144526f6c8528317cc3e9675c90a1
   952f4bc2725a6a154f59aed10e4ff7ec68d4917d74122b
   server_private_keyshare: 3e3869237f74106241777f230582e849076f08753056
   c186437ded8ee22f96e44bd5b6ec07cb131d51cf1324c1238699
   client_private_keyshare: 59b596174a682828f3934d510217ce7890f67cafc0ff
   aa7a1e1d1ced3c477fea691e696032c8709c86cbcda2b184ad01
   blind_registration: 3382c7ec9bdd6e75898e4877d8e2bc16359073c015b92d154
   50f7fb395bf52c6ea98384c491fe4e4d423b59de7b0df39
   blind_login: 29d29abeabede9788d11782429bff296102f6338df84c9602bfa9e7d
   690b1f7a173d07e6d54a419db4a6308f8b09589f
   oprf_key: 4283efb9cd1ee4061c6bf884e60a877321ece4f9b6ffd01ce8208254541
   3bd9bb5e8f3c63b86ae88d9ce0530b01cb1c3





Krawczyk, et al.         Expires 25 August 2021                [Page 43]


Internet-Draft                   OPAQUE                    February 2021


C.4.3.  Intermediate Values

   auth_key: 8683467532811d66f0425a128b09444e65039a9117b1a6576f92dadf808
   c2f4452bbf8d6a06ab2402252aa373417d428c1be2be215f92ea540c17374f23de7f0
   prk: 44d67b8c3f03ca205a51628bcbf41998a9fe4b4f97a3d29d5bd8bcbda03dbe5a
   303d536583d7d6c960d57f9d7c311b61a948916f85d8f69a4068755418608c79
   pseudorandom_pad: 9f64c761fc6a52010cab3598d1a0427300942c600646ef48214
   bb0742003dd9ac788b5bf931edcf813ee2706fcc9d97b
   envelope: 0122bc649eec25874f87e625008d252fceffbb8b434327914db6c09d07b
   7f3bf196cab6723fcea99fe229f042413ffc2c709511fbd27d4a23f9df6a0f3198a6a
   7f448e0ddcb4743bb85a8f766458df0c73f415cbb11c8336491fa796488c4df057449
   b8b2ce1f05a32ec00168d5a0c9eaa049e2b70fac847a2f4b48006c98f662bf97e5900
   edee521388deea91dc57a877
   handshake_secret: 1c668baa9ed83178a0cef4c16dcc7e0e86932607f0c913af336
   2c639c2532ffadcda40c94f94efa66fdac4cfb59185c17557dae088d344b616834c89
   c5d700bb
   handshake_encrypt_key: 3df8e9afb60fd6915bf2ef9cf909e7164acb9113d327fd
   d024392a1ca45a0b8e7d25ec4255b8e870caaa5673b60905feceadd897519934772b6
   577bfc415359a
   server_mac_key: 1fee1495e257b9f4369874cd6a58c9f6eb902dbef8469b82b398a
   b3c0f0b5d70101704a71a1087e4ac3e8d19b92d111db2fdde95b20ee46971d8b91d8a
   b042c2
   client_mac_key: 22cc03b0a2f2cda7112afb5714af9e3b84924237855a23cc64bc2
   2c00e401bb29e507d7824ed0640c6c05b295c93172284a266aec2aeb01a1c05941f28
   e28daf

C.4.4.  Output Values
























Krawczyk, et al.         Expires 25 August 2021                [Page 44]


Internet-Draft                   OPAQUE                    February 2021


   registration_request: 02fc4b3addc3978fba0bdfacc4fc662bc8af59e00392b0b
   6b5fad9a5d6a60a015b4a0e2d1c8e2f95e229fdbdf50ab93a7f
   registration_response: 02ba75a6a537e88c57e67208566dfa0193387002d3028c
   a8cb0a2c08c2880f1ed91335a6c289d1620feea05b6243b181280251f78cbd5c7a3fb
   f4cdaeb755eb8cc4159edb0ef38baebb503dbefed5c89c14f7c2b99ed242b3d1de890
   f7515bad94bd
   registration_upload: 02c86369d6eae0978bdd4030b43e0619ce46ea9d91fa6e0e
   7575bb12aa4857db98b952d8af9d92f75899c49d0d18793c1e0122bc649eec25874f8
   7e625008d252fceffbb8b434327914db6c09d07b7f3bf196cab6723fcea99fe229f04
   2413ffc2c709511fbd27d4a23f9df6a0f3198a6a7f448e0ddcb4743bb85a8f766458d
   f0c73f415cbb11c8336491fa796488c4df057449b8b2ce1f05a32ec00168d5a0c9eaa
   049e2b70fac847a2f4b48006c98f662bf97e5900edee521388deea91dc57a877
   KE1: 02778d77bae1e5e05311469840b632fc724f55070922598457dcb06b22f8fa87
   d6ba7886fe34283d8727a1e1d30251a5c9af0eb9b48c985e2ba859ce089fc342c648d
   dadfca4735f5b2e631eea7fdf967b000968656c6c6f20626f62027044d31354b5b985
   87d7d144526f6c8528317cc3e9675c90a1952f4bc2725a6a154f59aed10e4ff7ec68d
   4917d74122b
   KE2: 03ad08056e57dc6424c6210d7e12801ec7de62e2de9decc6f034d000dca821ab
   aca9d733e8807d072bb8c211c477d27fc20251f78cbd5c7a3fbf4cdaeb755eb8cc415
   9edb0ef38baebb503dbefed5c89c14f7c2b99ed242b3d1de890f7515bad94bd0122bc
   649eec25874f87e625008d252fceffbb8b434327914db6c09d07b7f3bf196cab6723f
   cea99fe229f042413ffc2c709511fbd27d4a23f9df6a0f3198a6a7f448e0ddcb4743b
   b85a8f766458df0c73f415cbb11c8336491fa796488c4df057449b8b2ce1f05a32ec0
   0168d5a0c9eaa049e2b70fac847a2f4b48006c98f662bf97e5900edee521388deea91
   dc57a8777e4c5d3a4f779d5966cc8ca367e47e0716ad0f33aa100fe68507920a1a6e3
   578035684e8cdae6ce360c2d3f41e4b059f34f986e92dd50c8255f7d7dc0c16252ef9
   b8c9fb9e0c2846053355e7fcfa46781f000f51b16b11ae1a74e076f8ceaac5a7ec5bf
   578645dbf57581437cd48dfe01f36e169053188d159bd9e23ec7af8d31be741472b40
   6d7618c9012d37d8a33fe02b91aacbbab0b19d5b78955e5d3c76e5ae
   KE3: a33a58dc32f246eb495e5645688b51662bd2615a254089f535a3262b6a4073f5
   3c79c7e08de7e551f8d5555e15e2aa72472b07fe6f1899712e34c60ecc36141b
   export_key: 1a9cd58039b5c8dd9c17c9477c6bfa45ce5a92a097edf99cc760ee71b
   6766c01b7f96e53d95fd13f0374e066c4fb5b3b08cc49e3db408ae5926cbe43c391fe
   0c
   session_key: 868df74aa4b3e5d4bcb6a5ef85ebfb1070a5644b0fb3b6450cfcb425
   d759df9d210071d5b2cc407379935fee1e4a014b555fe4fdf92e553d415354188df8d
   6ff

C.5.  OPAQUE-3DH Test Vector 5

C.5.1.  Configuration










Krawczyk, et al.         Expires 25 August 2021                [Page 45]


Internet-Draft                   OPAQUE                    February 2021


   OPRF: 0005
   Hash: SHA512
   SlowHash: Identity
   EnvelopeMode: 01
   Group: P521_XMD:SHA-512_SSWU_RO_
   Nh: 64
   Npk: 67
   Nsk: 66

C.5.2.  Input Values









































Krawczyk, et al.         Expires 25 August 2021                [Page 46]


Internet-Draft                   OPAQUE                    February 2021


   password: 436f7272656374486f72736542617474657279537461706c65
   envelope_nonce: ccb5f7f7e31e8295587ef5f9f90fa475de567165cf6482e1f5579
   583d0d7c54f
   client_private_key: 004274252f29a6e19915f81b0c7dcea93ce6580e089ede31c
   1b6b5b33494581b48678aec1d0c3d16afd032da7ba961449a56cec6fb918e932b06d5
   778ac7f67becfc
   client_public_key: 02000202cbe2dcdfe616ffe600cbe24768cdba3066d53d2b58
   feffa43e199c833f85963a612b79a2fbfb065f34e2edf51e39ba3db9cbdec0fffcce0
   113a5c05b2c28b1
   server_private_key: 000739878b22e5c4833d34c486a8510e7cca4c1b81ece04f4
   7e8d2554a5ebd83679b4c1e67ed82f2891751aa7094602be672c324929abb1876a7f7
   165ac7ec79bfd6
   server_public_key: 0300159aed22eed3a1ca9e7a8b063b1b62c3a48b00b7b83edf
   6047defdb1b05e14b14faa77afb5f08ffaa04cc8c5df59983e42677f7b6c8d63c0348
   15367374543ed1c
   client_info: 68656c6c6f20626f62
   server_info: 6772656574696e677320616c696365
   server_nonce: b18ed353e7c876de386bfab5f549f6c8e8dc8ba0f63cb32fe4d67a6
   eb3556b8e
   client_nonce: 6303dc1f00a19ea8ce857f9c2156702c56303a53d5ecbaa35f5a3d5
   47e85b924
   server_keyshare: 02003fe52f2e417b5c448309d4a54363aa84725feff99da4639f
   caa9d60e5b1bea54a7f5661b05bd4d3a662d6688a76f177c63d1f1a548ff00d5d6c6f
   b331b56e1b890
   client_keyshare: 0201a487b80b1f7927e7e44eb0cea2498ce462ab21fcb4b8e987
   27aac9e91dd8f8e22338953560a0e088934084f2a27b85b31a3ba55b73ff9a0d17333
   4667996078929
   server_private_keyshare: 0134471b1e6eb4b043b9644c8539857abe3a2022e9c9
   fd6a1695bbabe8add48bcd149ff3b840dc8a5d2483705fcc9a39607288b935b0797ac
   6b3c4b2e848823ac9af
   client_private_keyshare: 002d816be03432370deb7c3c17d9fc7cb4e0ce646e04
   e42d638e0fa7a434ed340772a8b5d6253d35895f4cff282d86b2358d89a82ee6523ef
   f8db014d9b8b53ad7b1
   blind_registration: 003f281099ef2625644aee0b6c5f5e6e01a2b052b3bd4caf5
   39a41fabd4722d92472d858051ce9ad1a533176a862c697b2c392aff2aeb77eb20c2a
   e6ba52fe31e13f
   blind_login: 01c28b45f65717a40c38f671d326e196e8a21bf6cfd40327a95f1ccf
   c82a9f83a75dae86286729214a1ba9a359ab01833477b8cb91932d0c81667a0e3244b
   896ac15
   oprf_key: 00363749be19e92df82df1acd3f606cc9faa9dc7ab251997738a3a232f3
   52c2059c25684e6ccea420f8d0c793f9f51171628f1d28bb7402ca4aea6465e267b7f
   977b

C.5.3.  Intermediate Values







Krawczyk, et al.         Expires 25 August 2021                [Page 47]


Internet-Draft                   OPAQUE                    February 2021


   auth_key: 5beea85089b8a18c21ac2e4be507a181faf3dbf07624b1e4180c67b1639
   932d477388c9a6254c1f8eea4e6594aa0719a824add4d474472d5c9a2931f95b7d647
   prk: 935f5cbf45cd48d365b20a1ab637fe31b9fc771b70af288bbe890e0b015b2225
   7380360eaf8a5a126f055fa0f68246877f18bcf5269e41746cf671b3c2a254ca
   pseudorandom_pad: fd878bcecd07a5b599b07502d12c1386728e81576c5351b96f0
   36919b8edb84f7c7f3251575735b329af90a72d2ddc3c544e5b9cf1812cef6040a9fb
   7bbcf9e70e2a
   envelope: 01ccb5f7f7e31e8295587ef5f9f90fa475de567165cf6482e1f5579583d
   0d7c54ffdc5ffebe22e035400a58d19dd51dd2f4e68d95964cd8f88aeb5dcaa8c79e0
   543418b8bd4a5b08a5867fa27d5684bd78ce18955a0a10a27c4b467c8cf17b0f9ce2d
   6d11f62e0de7801c4adbd6963b5a2bf64c9d157139f97c7556f68e1942a98ddc92adf
   b5a1b26607504d1614b0c864ec61c3b80d7659c91a7cb68eae3516294053
   handshake_secret: ba997ccbf434ae93cee1dcde4df3a8302db1e650ba4375acbb7
   6715e63e91acca5d9c215425946e90004194832ba1078b50873f73b23af779d4ede26
   9ecb491b
   handshake_encrypt_key: c4324223326aa611bd0eb147f16e47ea8dccb2f4360a53
   d332a5e3bd95a6812b0fa8e6e15997447b08b094a22856e44e23d0c1536b1a5824a70
   f0bcc1ff4e752
   server_mac_key: b782fc84b81fd9434f4e5339b33bddbf23ad0220d6dd42f2980f4
   7ce31f59b5127a023591741e8074eda2175fbc298f1f5138d9e06789e7d179190178a
   04f901
   client_mac_key: 786e739a91fd527e24d2fabaebf862c7d8d4ca067bc365526b152
   cf5de9a7aafea44e5f223c0e5a73cf9c551e19e05356f606fa2d10acd46a2a1239d73
   9ebd49

C.5.4.  Output Values

























Krawczyk, et al.         Expires 25 August 2021                [Page 48]


Internet-Draft                   OPAQUE                    February 2021


   registration_request: 03016af598df5549c18c7f904ff395006449477bd594663
   b2948142db6d2aac90d204900d669b5e73cfefdc91d7bee857d9522eb996601d2c3f8
   25221ed46f51c89ec7
   registration_response: 0201b7e055f71ebc3020873cd002596dfce243891fc7f2
   278ab1c5bf768886067e779ce4d922dfaa87e3dae9ed4d1ba2bd19ee24c2f33f3f19f
   89d5b0eb6865880659c0300159aed22eed3a1ca9e7a8b063b1b62c3a48b00b7b83edf
   6047defdb1b05e14b14faa77afb5f08ffaa04cc8c5df59983e42677f7b6c8d63c0348
   15367374543ed1c
   registration_upload: 02000202cbe2dcdfe616ffe600cbe24768cdba3066d53d2b
   58feffa43e199c833f85963a612b79a2fbfb065f34e2edf51e39ba3db9cbdec0fffcc
   e0113a5c05b2c28b101ccb5f7f7e31e8295587ef5f9f90fa475de567165cf6482e1f5
   579583d0d7c54ffdc5ffebe22e035400a58d19dd51dd2f4e68d95964cd8f88aeb5dca
   a8c79e0543418b8bd4a5b08a5867fa27d5684bd78ce18955a0a10a27c4b467c8cf17b
   0f9ce2d6d11f62e0de7801c4adbd6963b5a2bf64c9d157139f97c7556f68e1942a98d
   dc92adfb5a1b26607504d1614b0c864ec61c3b80d7659c91a7cb68eae3516294053
   KE1: 020142931e5e870e35226b46f8a9692babfabede9ca86ffded305ba079274920
   aa78f9a45341b6693765e601237d6a6bce8ddf194f6161144e9a2a1bcaa5860e6637c
   d6303dc1f00a19ea8ce857f9c2156702c56303a53d5ecbaa35f5a3d547e85b9240009
   68656c6c6f20626f620201a487b80b1f7927e7e44eb0cea2498ce462ab21fcb4b8e98
   727aac9e91dd8f8e22338953560a0e088934084f2a27b85b31a3ba55b73ff9a0d1733
   34667996078929
   KE2: 02000c9ca900d4b470d043136562cd7d9debe13d6595a274e46a1bd9a7a2e3d6
   19f6a7cc0324f30fc8fa10f8eefcb7e968c6f2e50cf0e2ee3487d9a80cbe24255600e
   b0300159aed22eed3a1ca9e7a8b063b1b62c3a48b00b7b83edf6047defdb1b05e14b1
   4faa77afb5f08ffaa04cc8c5df59983e42677f7b6c8d63c034815367374543ed1c01c
   cb5f7f7e31e8295587ef5f9f90fa475de567165cf6482e1f5579583d0d7c54ffdc5ff
   ebe22e035400a58d19dd51dd2f4e68d95964cd8f88aeb5dcaa8c79e0543418b8bd4a5
   b08a5867fa27d5684bd78ce18955a0a10a27c4b467c8cf17b0f9ce2d6d11f62e0de78
   01c4adbd6963b5a2bf64c9d157139f97c7556f68e1942a98ddc92adfb5a1b26607504
   d1614b0c864ec61c3b80d7659c91a7cb68eae3516294053b18ed353e7c876de386bfa
   b5f549f6c8e8dc8ba0f63cb32fe4d67a6eb3556b8e02003fe52f2e417b5c448309d4a
   54363aa84725feff99da4639fcaa9d60e5b1bea54a7f5661b05bd4d3a662d6688a76f
   177c63d1f1a548ff00d5d6c6fb331b56e1b890000fb9963a4ef0da2bd75360ae592d5
   f4bc54b8cf32d0748333345ed7f75ca2045eb413c7a9b844ca9f5ecb23c0385108623
   211a8b89c613912a54d48854c0b4832829bd718a890cc72334ddaf2f18e87e
   KE3: a1765707136891b2d76da4c47e8c883729fcba6786b91b3a11d682c98a9cc50b
   b7ea8fbd8304c030d414506818b315ad8a990f0363ce7c1f5e8af5aaa66571c9
   export_key: e80808e17d470f24478de9471e06fc0c7a1aa1e98af711d2f8424fba9
   fcd8ed30dc2a5894813e4c2f9a650ab07bedb9516b4c87a995afe3387bcb8a6a7499c
   76
   session_key: 61933b6a3227a5fc10ac30b2186d91fa6095e42768426b74663b75f9
   21b19556e24ce7253510a204a7f86aa0ba3e37c0b4dea2fd422bcb4a6b385416ff364
   15e

C.6.  OPAQUE-3DH Test Vector 6

C.6.1.  Configuration




Krawczyk, et al.         Expires 25 August 2021                [Page 49]


Internet-Draft                   OPAQUE                    February 2021


   OPRF: 0001
   Hash: SHA512
   SlowHash: Identity
   EnvelopeMode: 02
   Group: ristretto255
   Nh: 64
   Npk: 32
   Nsk: 32

C.6.2.  Input Values

   client_identity: 20fa92f2e4b7ea5b5e677ac4930ff3b93b0043481ab70bc613b2
   e16a6dde6b05
   server_identity: eae9dfa6b8348d34418c32d385e1eac99efbce1af320901f7c8e
   de8d6d272c65
   password: 436f7272656374486f72736542617474657279537461706c65
   envelope_nonce: f41e8b3c5a999aa946f9b562a150e5c5e36748a31a79feb241809
   0438877888c
   client_private_key: dc70a99bbabf1ebe98b192e93cedceb9c0164e95b891bd8bc
   81721b83d66b00b
   client_public_key: 20fa92f2e4b7ea5b5e677ac4930ff3b93b0043481ab70bc613
   b2e16a6dde6b05
   server_private_key: 709687a36c94592ab76579f42ce1be6961f0700496e71df80
   6ebd5320554720d
   server_public_key: eae9dfa6b8348d34418c32d385e1eac99efbce1af320901f7c
   8ede8d6d272c65
   client_info: 68656c6c6f20626f62
   server_info: 6772656574696e677320616c696365
   server_nonce: ef49d83cef5f1411ea30abb82b08bd85423aadb86e2c19df5930b3c
   8498b9f97
   client_nonce: 4ab1227db632bc079f79c0f5279df2dfa75cfbd4434ab40dcf844d6
   77165cd3b
   server_keyshare: 96a9587e233e67f2397f10fec6355b68102534f1f1b115b4ddf7
   485840efcd7c
   client_keyshare: 54f35db3a52fb0cf2a97918a6987993231d227e28711eaef19a3
   e5033632611a
   server_private_keyshare: 6650d64df70618a878504ce73dcca27b1af125c67e48
   1e7bd49d0b24709b200f
   client_private_keyshare: ebb01c59f99bc955df622548e247f7ef180732909ff3
   c5f87ff8c7867b8be704
   blind_registration: 308f1d3fa1fea402f3c90b04601274050a3c6f467387c2f48
   878823949b0e109
   blind_login: 141e21373228a44b09d4c00da9a6bbaf9a5e54a1687c07f327833643
   4245510b
   oprf_key: b7126967aa0cb69c311b71343843ea041bae30e2bde41b548b8fbd8bced
   97604





Krawczyk, et al.         Expires 25 August 2021                [Page 50]


Internet-Draft                   OPAQUE                    February 2021


C.6.3.  Intermediate Values

   auth_key: 9f761a5a56a74269b382403aeba47c1d24b9e200e1839efcb616fb280da
   1b6ba7bd71d6455dd3cd979c545608cfbfc1c4e9ba677e1d40848054a00696c4b2589
   prk: 30bc3f37a757890ac17ce46043f3c5ed30c96fb8743205e77e84dc167d98e114
   6093150ff7b4d002f793bfe717e88d174ed2669abdd9e96af473a7ac82973b0a
   pseudorandom_pad: b909f990c94b9c5949a2b8d0874d602f846b7981b331fd79978
   b530cc46c8670
   envelope: 02f41e8b3c5a999aa946f9b562a150e5c5e36748a31a79feb2418090438
   877888c6579500b73f482e7d1132a39bba0ae96447d37140ba040f25f9c72b4f90a36
   7bdb425fa1dd4c49e17780f33b821e1e019668fe7f45520e26996ac8cb08e3d2566cc
   439c83030464effecb8350e7b1ca31087d87f6a45ed3910c185a24a89d282
   handshake_secret: ff89f264f8c3974238f4c8d736af7b0a55f2e4edc487cbf3e5c
   7b4bbf21acd7c1d28354c2c8555fba57c4d4b1fbb4b772bfdf909881f67dd517cc9f4
   f6ebaeac
   handshake_encrypt_key: 3071b181f639062cf70b74d0ffe5ec8fa695da13cd2f00
   e74b8b7ef348ae7a5df9c3a32c9f7aeaad5a28379712cf849b9707e221dce124abfad
   d0225a8e8e045
   server_mac_key: 7c37b344d189cbbeff80bbb4b78e2703d1a80dc28239923094287
   62f7ce2a93b11f6e85dd45c02809afe8583d4aad6377e72788773af92eef33c690692
   20ae76
   client_mac_key: 2c4aff12ba7aa911a51f9e5b7a7c01439d854c97e4b8ec842a9db
   d78345760328fd5a72424e49e25ec8fe1b6d9d42f774516f400948bd5a105d995d000
   2fc83b

C.6.4.  Output Values

























Krawczyk, et al.         Expires 25 August 2021                [Page 51]


Internet-Draft                   OPAQUE                    February 2021


   registration_request: 3c8b89966e261a5aaf7aeb6dcdd94c87ce311bf197221b8
   7ef44632d58f18a05
   registration_response: caf9243d7ef3e267815632bf79c85a27a23f218a438815
   2a523f6a310949807beae9dfa6b8348d34418c32d385e1eac99efbce1af320901f7c8
   ede8d6d272c65
   registration_upload: 20fa92f2e4b7ea5b5e677ac4930ff3b93b0043481ab70bc6
   13b2e16a6dde6b0502f41e8b3c5a999aa946f9b562a150e5c5e36748a31a79feb2418
   090438877888c6579500b73f482e7d1132a39bba0ae96447d37140ba040f25f9c72b4
   f90a367bdb425fa1dd4c49e17780f33b821e1e019668fe7f45520e26996ac8cb08e3d
   2566cc439c83030464effecb8350e7b1ca31087d87f6a45ed3910c185a24a89d282
   KE1: 8261a1efd78bea73faf256a23c200d729259886530fa43b875c1ca124b09bc7e
   4ab1227db632bc079f79c0f5279df2dfa75cfbd4434ab40dcf844d677165cd3b00096
   8656c6c6f20626f6254f35db3a52fb0cf2a97918a6987993231d227e28711eaef19a3
   e5033632611a
   KE2: fa1f33a43a03123ebe35345ef93aa23b57ea8bfbee7022b05a179d60768ba02e
   eae9dfa6b8348d34418c32d385e1eac99efbce1af320901f7c8ede8d6d272c6502f41
   e8b3c5a999aa946f9b562a150e5c5e36748a31a79feb2418090438877888c6579500b
   73f482e7d1132a39bba0ae96447d37140ba040f25f9c72b4f90a367bdb425fa1dd4c4
   9e17780f33b821e1e019668fe7f45520e26996ac8cb08e3d2566cc439c83030464eff
   ecb8350e7b1ca31087d87f6a45ed3910c185a24a89d282ef49d83cef5f1411ea30abb
   82b08bd85423aadb86e2c19df5930b3c8498b9f9796a9587e233e67f2397f10fec635
   5b68102534f1f1b115b4ddf7485840efcd7c000f7ebe71d4ab326006a3aeca802435d
   c995a38ac6662221f974cb920992d82b8ef8d147c77e29b628a82b5ccb01ea2f7bb60
   af94cd1860e1bd974a11a1c9bd827789f663c4758eb71058c244138de0c2
   KE3: d81f93397cdba85a43993d4d9afbdc67f147adfa2b223213b19692cb820eef48
   5073eda4c8236b2f47702404ad60d9a875d189626fc7b7cc861825385470ae54
   export_key: 03192555940b5b42e64e6200bf55cc701f1bace3d402a2f8d83977843
   51a1e3fa1f07a471b783b208acb1d92be47903b6fa3a0df9f4d4b7956ee4f431e2950
   f6
   session_key: 58a7fa98bf3b7b52da21406abfb11d98734354edd47d7b32462c0513
   f0617c89824ea6031d4147a86fc9f6c6837ce640c12fb937d764f296d1a9421ad1b2a
   5d5

C.7.  OPAQUE-3DH Test Vector 7

C.7.1.  Configuration

   OPRF: 0002
   Hash: SHA512
   SlowHash: Identity
   EnvelopeMode: 02
   Group: decaf448
   Nh: 64
   Npk: 56
   Nsk: 56

C.7.2.  Input Values




Krawczyk, et al.         Expires 25 August 2021                [Page 52]


Internet-Draft                   OPAQUE                    February 2021


   client_identity: e0f6146168d32f4b68e042ed5d5608d1108e84a08b6688798ead
   0810b4f10d7a91f0767e197e946ebfc487bf62a5ed5684e7ab9137ee1862
   server_identity: d49500848e7c06c8a5dd5bda74930ffd20fbef9a2de24a0068e5
   bf3dc356852b10327be9803983271450bc6a8c683abcdd73883ee63543e9
   password: 436f7272656374486f72736542617474657279537461706c65
   envelope_nonce: 4c0ccd88c12f90364570c5ce356f457a762bbe590e27d6208ebc1
   9332d37605d
   client_private_key: 0a45c82e38a6ab6fb99ec1df7423e25a7851f9558e7a05166
   03c9d0201b409c3fd0f0fe78bd37bf60927fafeca73ed8093538a9992c62235
   client_public_key: e0f6146168d32f4b68e042ed5d5608d1108e84a08b6688798e
   ad0810b4f10d7a91f0767e197e946ebfc487bf62a5ed5684e7ab9137ee1862
   server_private_key: 64666faa068e5ff9e00d588446b7d6cdc09ae8df069b30987
   a2cdd39286e0481a2eb899f4e0db672264527a8115f176c53709a4f6534f328
   server_public_key: d49500848e7c06c8a5dd5bda74930ffd20fbef9a2de24a0068
   e5bf3dc356852b10327be9803983271450bc6a8c683abcdd73883ee63543e9
   client_info: 68656c6c6f20626f62
   server_info: 6772656574696e677320616c696365
   server_nonce: 975a2b5d6318131b85d7f2f47ea0b7edef8f33a1be69f09307604c1
   3b7afdabd
   client_nonce: df3b22899746ff552d61851fe5c2b5ff1e004fd95dfbcba1906ade5
   fd38a70be
   server_keyshare: 720df48b9e395c40448cf06a80bc9c1d90ae1a3080e4ba3368ca
   056ba92921f79d67073fb91b7c94c3f3d33cc01613d7221f54fecd80bcbb
   client_keyshare: e6f2ab22efb569a19f48355c7d5d4f728faf3a9142d45c20c098
   bcbcb6c12fd92480bfb4e532923e64b9620b6bc84ac5f2d8f84ad466fd18
   server_private_keyshare: e5d7202d6ed8cc45c4502850974076d720343b566089
   1b5ab5655c3defb4b39b35b27ea20eb0bff035e9b9cbae6cfca36aa4827c32abd905
   client_private_keyshare: a54c0d7bf4ee396a0e4a3f023b35698aaa93a2be8bb6
   32747671b3edeaedff07116afbb5e73cbc273e2e0d0876780343578338425ed81d3b
   blind_registration: 9d557ee103479baef585ba8017f7659cdd0b804c093852519
   9d88853b52ccfc7802d09cf38ba35e36db24404602da8a616e7ad8f1c05cb36
   blind_login: eaadba538bf67207633a956ea71fbd02ea2dbfe7e195dbd26ea562c6
   f2406fe1df1367f98f6707dee9b2e3ebd9842b0442e25d086e099231
   oprf_key: 98a5689edb98ed3424fa5c8584423c6b047121fc36fcec934c8ad24a98c
   86d00e1e1d6d3d923a46519065977331abaa1e3c0d86591458b25

C.7.3.  Intermediate Values














Krawczyk, et al.         Expires 25 August 2021                [Page 53]


Internet-Draft                   OPAQUE                    February 2021


   auth_key: 7115d4b507621a9885dea1c09034a0bf258d9a04bb57e11d450a5d9956c
   9810ef8f243225ad387c8c6d2511be920ee5cd66c79079509e6d132fc6fc8f4238f6c
   prk: 296432fda62b3ca77c10e38952b4c18e9e12164f883e9fcc4f2723c37fa3b8f3
   6c4f4a4ca009aefd1391e3a0a36fc05580c98c55a17623dc593b9d18e3babc25
   pseudorandom_pad: d59012fd3a30fe215ede1b55ba2106c28f4a5f87dfc29b6525a
   b3f41b4ffe552051bca9553b9b3149b06e3723d4d862ce4d6ede1e4b77ecb
   envelope: 024c0ccd88c12f90364570c5ce356f457a762bbe590e27d6208ebc19332
   d37605ddfd5dad30296554ee740da8ace02e498f71ba6d251b89e734597a243b54bec
   91f814c572d86ac8e29221198cf73e6bac7785677876715cfe105031ce6b536b86424
   6d9b2a03acbdbe1a013b0c153e3e5ab18d601c10475f6d137d950f50b1a716bd41d16
   81932e6ae211451b7759b22d46487c707508ce7c
   handshake_secret: cf4fc0c1cb9fc5b4f97ae047dfc5269d3b9013146f5a5e5ee93
   1826a1e94465bb5079c4d65da5187c6b89be8bc276d54dc0968ef2bd9c33d4e06e485
   5a571529
   handshake_encrypt_key: fdafb8a372b21fbcc478a3986dca5f1eb24060b6e63cec
   96d48edda13e54b9cdf7730f49fd16c67bfe90ccb89621414c030049b22214dfdf093
   69c7b96f6757a
   server_mac_key: f54ed72de90635c20994822097039b2a4e7349c806738b716105a
   80abdba51a4d8d36ea015713b461402e1ff6f7fc26f8bb0a4b889111ba08da2b7cbc9
   55effd
   client_mac_key: 841b179f9f3bad87574cc8181008f61905d5f1924f40468aac081
   5f7592216c0450a657ddb160f5d3484d77c186b9e9948fbe9e98bd0634b432a39b733
   d19461

C.7.4.  Output Values


























Krawczyk, et al.         Expires 25 August 2021                [Page 54]


Internet-Draft                   OPAQUE                    February 2021


   registration_request: 90cca9013769f28f3992f77a043084edbfe6c89b7e2305e
   4a6765e50df565fa8e18aba470238c6ed7992af20e962a641bc6bd678ceba640a
   registration_response: e45f47bc6f41bb6de778775aa3f746b31cd17969183beb
   e8b3757ba8dd546534996ccc686709c1a0fd6ecb4313936940a470333d1ae3c70ed49
   500848e7c06c8a5dd5bda74930ffd20fbef9a2de24a0068e5bf3dc356852b10327be9
   803983271450bc6a8c683abcdd73883ee63543e9
   registration_upload: e0f6146168d32f4b68e042ed5d5608d1108e84a08b668879
   8ead0810b4f10d7a91f0767e197e946ebfc487bf62a5ed5684e7ab9137ee1862024c0
   ccd88c12f90364570c5ce356f457a762bbe590e27d6208ebc19332d37605ddfd5dad3
   0296554ee740da8ace02e498f71ba6d251b89e734597a243b54bec91f814c572d86ac
   8e29221198cf73e6bac7785677876715cfe105031ce6b536b864246d9b2a03acbdbe1
   a013b0c153e3e5ab18d601c10475f6d137d950f50b1a716bd41d1681932e6ae211451
   b7759b22d46487c707508ce7c
   KE1: a8f3c6290c4a31a2f696ac5c4f933c85dc3a8fde4247e8733fae3502b9f895ed
   40a43c53547891e0a6305a12f7bbbed8696a774f2f352b1fdf3b22899746ff552d618
   51fe5c2b5ff1e004fd95dfbcba1906ade5fd38a70be000968656c6c6f20626f62e6f2
   ab22efb569a19f48355c7d5d4f728faf3a9142d45c20c098bcbcb6c12fd92480bfb4e
   532923e64b9620b6bc84ac5f2d8f84ad466fd18
   KE2: 3c86de1f2ef35f9044b08421334c2ea2020300a3c5259bab2fd525dd4e68e03a
   90d3460479849e12847a3600cf2428a4c424741b96f76aa9d49500848e7c06c8a5dd5
   bda74930ffd20fbef9a2de24a0068e5bf3dc356852b10327be9803983271450bc6a8c
   683abcdd73883ee63543e9024c0ccd88c12f90364570c5ce356f457a762bbe590e27d
   6208ebc19332d37605ddfd5dad30296554ee740da8ace02e498f71ba6d251b89e7345
   97a243b54bec91f814c572d86ac8e29221198cf73e6bac7785677876715cfe105031c
   e6b536b864246d9b2a03acbdbe1a013b0c153e3e5ab18d601c10475f6d137d950f50b
   1a716bd41d1681932e6ae211451b7759b22d46487c707508ce7c975a2b5d6318131b8
   5d7f2f47ea0b7edef8f33a1be69f09307604c13b7afdabd720df48b9e395c40448cf0
   6a80bc9c1d90ae1a3080e4ba3368ca056ba92921f79d67073fb91b7c94c3f3d33cc01
   613d7221f54fecd80bcbb000fd48223a7b4d19871dfe19b5c5be686edbce5cec2fdb2
   c4aa9bbace6eebedbdee52e0ebee8f1053dc59dd66c11b34fbcfd7e681afe5f27ebdf
   683b6af777105fa8e57936da294f2d9e1ce090418608a
   KE3: 964f3993d57498ceb543937735462b830a559d4efdaa47e26411acb71a173428
   0f15cbbdbd4da4b6567086aaa7c3983dfc0eb711b7d8b7a877fd3f18d2d28a37
   export_key: 6bbf975f133ea322e181c98ecdbf1837bfa9c7d69d226675e0af8bae8
   96eb911beab703858bdd790c9e1b423bddbd35fa9eebe6aed8418223737060bac0985
   5b
   session_key: 5bfe0bb35b1c430f294cf847f34f0c9f9e777f2888b667ed3711d9cc
   db0bd5505d715d8371fda04598f1cb06c00ae5aeed5ed1145a86df58513c9fd104460
   c09

C.8.  OPAQUE-3DH Test Vector 8

C.8.1.  Configuration








Krawczyk, et al.         Expires 25 August 2021                [Page 55]


Internet-Draft                   OPAQUE                    February 2021


   OPRF: 0003
   Hash: SHA256
   SlowHash: Identity
   EnvelopeMode: 02
   Group: P256_XMD:SHA-256_SSWU_RO_
   Nh: 32
   Npk: 33
   Nsk: 32

C.8.2.  Input Values

   client_identity: 0227aa37ade0cd6231bd385333cc8ccdf3872e75d9f6506192ed
   7bcc6e5819f5d7
   server_identity: 039178fd762b694fc67cc2df224079dd59ccd00d22621929a0a7
   e5ecac96814260
   password: 436f7272656374486f72736542617474657279537461706c65
   envelope_nonce: 96bd3e8e5a8110e4c57508b0d47d20509639b30b3726264a0f957
   937f33f5fa4
   client_private_key: dc970d63acb5ab74318e54223c759e9747f59c0d4ecbc0873
   02667fabefa647c
   client_public_key: 0227aa37ade0cd6231bd385333cc8ccdf3872e75d9f6506192
   ed7bcc6e5819f5d7
   server_private_key: fcd9a655f77ff0b2ebcfe21e1a1ca4a84361e9f1b18e24c9a
   40ed5eec262bf52
   server_public_key: 039178fd762b694fc67cc2df224079dd59ccd00d22621929a0
   a7e5ecac96814260
   client_info: 68656c6c6f20626f62
   server_info: 6772656574696e677320616c696365
   server_nonce: 3575160dbf02cbaddb376c3512c35e83e46b224d7d289fcd67d401e
   730b3ec58
   client_nonce: 24f0d0e0b3e2f8c0d5d561ffba8c87c88a085623fb61e9581b45069
   b4ec032c6
   server_keyshare: 0233c66a7b8735e362aa803f2e5677f48f4cab048edd74381667
   82858e46381fd8
   client_keyshare: 021ed435f437b88157c9af824de01811f5afc20de9dfdb49f0b4
   454ec1df60af60
   server_private_keyshare: 4fb9234e93a8bd048ad9f44b428026396a810328c405
   a354e666f086fa0ea476
   client_private_keyshare: 4fb56527be010296ea880e1c6a4dbbc9ede543a2ad0f
   83fd60fdacb59801a9d9
   blind_registration: a54f137dbe5f5eb4a34dcb73609c6693f28cd3d57ed77bf66
   e0ab7d86c6990f1
   blind_login: 3b5d1c0fc0812c10e18f146b14d7eb94755a918bac1ef8d69d21a7c1
   3f95c9b2
   oprf_key: 334d8af16ae1e69f5adc24e5aa89ebb63637c835fd39b17a1a4453eb5d9
   63d23





Krawczyk, et al.         Expires 25 August 2021                [Page 56]


Internet-Draft                   OPAQUE                    February 2021


C.8.3.  Intermediate Values

   auth_key: 598c8679dfc4693f8777d9ea209dffdbc3e8a6fd55fb11e42f197b2b606
   3752c
   prk: a60920b28eb24d0f12d996c42de3e94f6c79ab2532b1a633da85065037e57e5c
   pseudorandom_pad: 9e2987091f68f908bc9e7eb0030b01d1e5498d47cde3f0ece37
   88a673e6f9927
   envelope: 0296bd3e8e5a8110e4c57508b0d47d20509639b30b3726264a0f957937f
   33f5fa442be8a6ab3dd527c8d102a923f7e9f46a2bc114a8328306bd35eed9d8095fd
   5b2499abde5be91da24191482677267a9833c0adf6731f04c589d3b305b2530bea
   handshake_secret: c14fb3f53f5a518bd37a3bf670cc38455e26b7bd1e44d7567b5
   747ef10f1a5b5
   handshake_encrypt_key: 1912daa7086e5e0dd610058d30877d907b6f4888664bf4
   74d84e561afaadb127
   server_mac_key: baf03e219ba8cee27b26a5a0f12cc15ec809f8e23e8ccef0862b1
   1d515bcc4be
   client_mac_key: 08acb367302b3c2b5aa405954a8985f84f1a5b491daa77f58c20b
   81e97e73bac

C.8.4.  Output Values































Krawczyk, et al.         Expires 25 August 2021                [Page 57]


Internet-Draft                   OPAQUE                    February 2021


   registration_request: 02327e93445af116df70f57d18ab2a0ef9f492aa3d76c94
   6d98260fa1edfa5b832
   registration_response: 03480ac383e647d1f78b19bd902c7126024ccc76da605d
   cc416581a32e4202d62a039178fd762b694fc67cc2df224079dd59ccd00d22621929a
   0a7e5ecac96814260
   registration_upload: 0227aa37ade0cd6231bd385333cc8ccdf3872e75d9f65061
   92ed7bcc6e5819f5d70296bd3e8e5a8110e4c57508b0d47d20509639b30b3726264a0
   f957937f33f5fa442be8a6ab3dd527c8d102a923f7e9f46a2bc114a8328306bd35eed
   9d8095fd5b2499abde5be91da24191482677267a9833c0adf6731f04c589d3b305b25
   30bea
   KE1: 02dad65138d90eb5fffdd93d1ad84b7e86e5b3f1964756d092e154d6a135c6e4
   ce24f0d0e0b3e2f8c0d5d561ffba8c87c88a085623fb61e9581b45069b4ec032c6000
   968656c6c6f20626f62021ed435f437b88157c9af824de01811f5afc20de9dfdb49f0
   b4454ec1df60af60
   KE2: 038782ee7c0ca885bd49d7105f9f43f89d34b2ad39b98e02a1a4ceed9e7de3f6
   6a039178fd762b694fc67cc2df224079dd59ccd00d22621929a0a7e5ecac968142600
   296bd3e8e5a8110e4c57508b0d47d20509639b30b3726264a0f957937f33f5fa442be
   8a6ab3dd527c8d102a923f7e9f46a2bc114a8328306bd35eed9d8095fd5b2499abde5
   be91da24191482677267a9833c0adf6731f04c589d3b305b2530bea3575160dbf02cb
   addb376c3512c35e83e46b224d7d289fcd67d401e730b3ec580233c66a7b8735e362a
   a803f2e5677f48f4cab048edd7438166782858e46381fd8000f7dee7c8d4df469aec8
   69d6443711489cd6de819ad1ed162f6813c220f9171c66a0b3695b2c43e20c0fee072
   1fbad32
   KE3: 731075af5acd0195c6f0faa7608845a51aeb1d7da7f1feca8cf2b6665d17f8ad
   export_key: 0b157ff3684cb28f35eda2b0495c0bf945d41977d25380ec662b38034
   c3a8ddf
   session_key: 3d2e068949a1d940528f3e46f435bb1950347c3e924b6332fc4a729b
   34eac1ca

C.9.  OPAQUE-3DH Test Vector 9

C.9.1.  Configuration

   OPRF: 0004
   Hash: SHA512
   SlowHash: Identity
   EnvelopeMode: 02
   Group: P384_XMD:SHA-512_SSWU_RO_
   Nh: 64
   Npk: 49
   Nsk: 48

C.9.2.  Input Values








Krawczyk, et al.         Expires 25 August 2021                [Page 58]


Internet-Draft                   OPAQUE                    February 2021


   client_identity: 0368f5bbaaa438e2e87de012dec549a4a89a6d4deb262b133834
   d1d90ed3eeceb12a2c5cfd5702077bfb47b0e36e48904d
   server_identity: 024ecf37a198ab5431962c820df129c60356bc801d3584da5ce1
   19c15554d0183a3b9a6b833cd2a019a882c620020c8a3a
   password: 436f7272656374486f72736542617474657279537461706c65
   envelope_nonce: 54fdac1c3677cbf0c388eed24e5a425c1b616f035bb29aa445cda
   d356151e700
   client_private_key: 26fec54d4567adabd7951ad51ea3741feab175ac5cf7fa02f
   3ad744eb5baf418275e45ab31ade30669dbae98fb087953
   client_public_key: 0368f5bbaaa438e2e87de012dec549a4a89a6d4deb262b1338
   34d1d90ed3eeceb12a2c5cfd5702077bfb47b0e36e48904d
   server_private_key: 8588213957ea3a5dfd0f1fe3cda63dff3137c959747ec1d27
   852fce42d79fc710159f349e7da18455479e27473269d2a
   server_public_key: 024ecf37a198ab5431962c820df129c60356bc801d3584da5c
   e119c15554d0183a3b9a6b833cd2a019a882c620020c8a3a
   client_info: 68656c6c6f20626f62
   server_info: 6772656574696e677320616c696365
   server_nonce: b109f9b77755f74bbea8cda67e8e2d4829a8f684272a10758525705
   190d06a72
   client_nonce: 33bf1ddb42dd00682e5cce6c558b387c5f11d8ba41c819d1152612c
   33184838a
   server_keyshare: 036b981c4a2265b4376e2edc3186a45c2e2f820b1092784f6448
   354779578b442b0369640e2f10a856cf8dfd60b28c68c9
   client_keyshare: 03526fe798e9ab52137d8c3408b131430eadae49f6e93a4fa228
   c0338081e6090f75c2b3d55da4b2abfa4f2e2a52bd3330
   server_private_keyshare: eb81ae8c1af769a56d4fc42aef54a703503046d8272e
   aea47cfa963b696f07af04cbc6545ca16de56540574e2bc92535
   client_private_keyshare: ac475d6a3649f3e9cdf20a7e882066be571714f5db07
   3555bc1bfebe1d50a04fd6656a439cf465109653bf8e484c01c6
   blind_registration: c044df390ab5683964fc7aabf9e066cf04a050c4fd762bff1
   0c1b9bd5d37afc6f3644f8545b9a09a6d7a3073b3c9b3d8
   blind_login: f8516f98f3159b3fed13a409f5685928c72d9dab8ddfe45de734ce0d
   4ff5823d2e40c4fcf880e9a8272b46eea593b10a
   oprf_key: 5e7d38ba6ff37c42b3c4859761247a74d0c62c98ddff1365bb9b82b279e
   775b7220c673c782e351691bea8206a6b6857

C.9.3.  Intermediate Values














Krawczyk, et al.         Expires 25 August 2021                [Page 59]


Internet-Draft                   OPAQUE                    February 2021


   auth_key: f8070223ed2f8742430d213ffbefc4f314d2d919e7833e7894ac37bf3db
   3fbebb66a88c0d188822e532f2db6db9002979659e14076a019613cd19af38f24607a
   prk: 1a7fbae01371f1c2d60dde37b8c337075c60b9fe7ea56a529a8db3e6926aa83c
   e729ffd7ad288a2a3d0a3798b5b349370a185e79a11f86145051ceac83f6af71
   pseudorandom_pad: f8d7518c0f3dc7f4d0564a3de14e91b945bef48abd1bea93cab
   cfc1345f9461c6bea2ea07cedc27ec8717044b66b90da
   envelope: 0254fdac1c3677cbf0c388eed24e5a425c1b616f035bb29aa445cdad356
   151e700de2994c14a5a6a5f07c350e8ffede5a6af0f8126e1ec10913911885df043b2
   044cb46b0b4d402178a1aadedc4d63e989d239d0900f507a8964186f827ea18d23f0d
   859974e62913c95780c548a262c125fe8841fdd11453abbd79407dfa3a6ec4aa4da4e
   40c4dae1ab44569cfafe7331
   handshake_secret: b137c7cfd5e865c88803d041fa45250837242b6548e9cc31751
   dcd1f8fecee25708dad91348f106176deee35937681c8bf42bb86403baebdfb4d936e
   e0d96219
   handshake_encrypt_key: 8efd3f58bd9fe13172dda8ab106d427dc58dae0bf9da04
   51f4aef08d051cfa0cbbc42332d4ef506a0442d26c13eb1316969b6c81ba0c764efde
   659c099d15262
   server_mac_key: 8e6773f21a7bf460c2e4dadfd47fc10357f9fdbfb6a13413167b6
   4876489464a157ea128c7c9d8c4fcb81ec50113030a69b88d49698a473584e23423e3
   4ed296
   client_mac_key: fa75a3be1ae907f18a96d11aa2c96bd5dc2c2332f7f9a7ce086ba
   c0983952a96866596a7860ca65b5371bd80eabedaf34b7b54e8977a9c2fb46ffbe1b8
   ade1b2

C.9.4.  Output Values


























Krawczyk, et al.         Expires 25 August 2021                [Page 60]


Internet-Draft                   OPAQUE                    February 2021


   registration_request: 029674b50d9bec795e53084cb5d6e0f4813804ea378a672
   e5e0514f79e98055b79eafa67deed65b040dc1368a7216c8071
   registration_response: 02da545d424e985f21cfcac7dd74ceca2177e513ebf484
   3659160649ab4a0e5a9caeeba5e79c1fe86ebb5776e8bd4873db024ecf37a198ab543
   1962c820df129c60356bc801d3584da5ce119c15554d0183a3b9a6b833cd2a019a882
   c620020c8a3a
   registration_upload: 0368f5bbaaa438e2e87de012dec549a4a89a6d4deb262b13
   3834d1d90ed3eeceb12a2c5cfd5702077bfb47b0e36e48904d0254fdac1c3677cbf0c
   388eed24e5a425c1b616f035bb29aa445cdad356151e700de2994c14a5a6a5f07c350
   e8ffede5a6af0f8126e1ec10913911885df043b2044cb46b0b4d402178a1aadedc4d6
   3e989d239d0900f507a8964186f827ea18d23f0d859974e62913c95780c548a262c12
   5fe8841fdd11453abbd79407dfa3a6ec4aa4da4e40c4dae1ab44569cfafe7331
   KE1: 02ab0cdb1bf7038717c03d583e311f14c6004c73f78383d4cc6248751aa68ca9
   29d717dc6f003de949a17732875bd1aa6733bf1ddb42dd00682e5cce6c558b387c5f1
   1d8ba41c819d1152612c33184838a000968656c6c6f20626f6203526fe798e9ab5213
   7d8c3408b131430eadae49f6e93a4fa228c0338081e6090f75c2b3d55da4b2abfa4f2
   e2a52bd3330
   KE2: 03ed6cdbc3a3b78a9504aeaa0df8a3ff996ab5b8dbd2d74cfeec3c976c434a85
   860d6367df02c62989c8ee9b88a354ea30024ecf37a198ab5431962c820df129c6035
   6bc801d3584da5ce119c15554d0183a3b9a6b833cd2a019a882c620020c8a3a0254fd
   ac1c3677cbf0c388eed24e5a425c1b616f035bb29aa445cdad356151e700de2994c14
   a5a6a5f07c350e8ffede5a6af0f8126e1ec10913911885df043b2044cb46b0b4d4021
   78a1aadedc4d63e989d239d0900f507a8964186f827ea18d23f0d859974e62913c957
   80c548a262c125fe8841fdd11453abbd79407dfa3a6ec4aa4da4e40c4dae1ab44569c
   fafe7331b109f9b77755f74bbea8cda67e8e2d4829a8f684272a10758525705190d06
   a72036b981c4a2265b4376e2edc3186a45c2e2f820b1092784f6448354779578b442b
   0369640e2f10a856cf8dfd60b28c68c9000facff8adb93d0189b9de280f03ca36d3a4
   cafbf277c5773052ab51810ee6ff734f9e7ca0132d9194fc481035ee9df57636e17cb
   38c2fdac3d1f7cae42cf1de1c14b72b5fd1b494432b0dcac9ca2327b
   KE3: c01e2d5935d02e71c7b6832990dca8f596bee17ff07e85fc2215739f74ca6d01
   9f07ed514da397708e2b23fba02a72b673587f5e38917dfa442c9d7d52d40109
   export_key: dee3533f00de02168ad7cf6e419352005eecfe78c43d272d942f43d6f
   37bc97ac79f9cdb0c3310e75ab81248681ac73fff280d879c978435bb1f67a3abaad0
   c4
   session_key: 4a7535981fc126050dcf41a182fecf5773be561f0dd321a5f86ae008
   3a5fb4c603efa3f0b4dbc9c87af2a07e5c9093f9ace2d18ee2cdddb884cfd94f64197
   b12

C.10.  OPAQUE-3DH Test Vector 10

C.10.1.  Configuration










Krawczyk, et al.         Expires 25 August 2021                [Page 61]


Internet-Draft                   OPAQUE                    February 2021


   OPRF: 0005
   Hash: SHA512
   SlowHash: Identity
   EnvelopeMode: 02
   Group: P521_XMD:SHA-512_SSWU_RO_
   Nh: 64
   Npk: 67
   Nsk: 66

C.10.2.  Input Values

   client_identity: 0300ec0addd1ade650f8c2be98b2d7b5b5eb7e1eab56823f9413
   327e056e1413055ede83bd893a26f61094a87d108431dc4f95366741da7ec6465208b
   9080d17ed304a
   server_identity: 0300d1df68b2171f58ffc6a2cdf6cd47f4a672e0c06660ad5ec9
   cccbd8fafd4593dc847b3a3a7aedd1baf2d03dad24f1da95e884f3554c0d4915b0d47
   172f33eab7f0e
   password: 436f7272656374486f72736542617474657279537461706c65
   envelope_nonce: 9ac2de6c1f7b8a32dfb4e365b2610797cc5b76e9d5a1e0d016c08
   c33285785a9
   client_private_key: 0077881aa5fd937ec7932e725ac43a07cb3ea0e90b40e0501
   e6bdc3c97510cdd9475ad6d9e630235ff21b634bc650bf837aaa273530dc66aa53bb9
   adb4f0ed499872
   client_public_key: 0300ec0addd1ade650f8c2be98b2d7b5b5eb7e1eab56823f94
   13327e056e1413055ede83bd893a26f61094a87d108431dc4f95366741da7ec646520
   8b9080d17ed304a
   server_private_key: 002e485cccf5018abbf875b8e81c5ade0def4fe6fa8dfc153
   88367a60f23616cd1468dae601875f7dd570624d0ae9d7be2e6196708f773cf65852b
   da777210337d8c
   server_public_key: 0300d1df68b2171f58ffc6a2cdf6cd47f4a672e0c06660ad5e
   c9cccbd8fafd4593dc847b3a3a7aedd1baf2d03dad24f1da95e884f3554c0d4915b0d
   47172f33eab7f0e
   client_info: 68656c6c6f20626f62
   server_info: 6772656574696e677320616c696365
   server_nonce: 5f07f6b2c9a546f77d2e58ae23af2960f3f723fa00bc8c6c9c53768
   3dc372091
   client_nonce: aff297d07060f891faa127a937e7e7995d76ec727abf796dc80c315
   95bf8e201
   server_keyshare: 03009af99de97de5c0b5bb5299c406e53294dc48a78ba4933df0
   e01bf8e1c5e46fe1de6e82060a08a9110c435fd784b9ae31ecb639eabd464a1681912
   6be3b865b05e9
   client_keyshare: 030035c078a34aacc22e0e759115b9c7c45192d97e4970f40376
   76039e7bc2d270c3964e81a9009a788b022eac506ac16c9704efe50ff6041bd3c9422
   9673d2073d8bc
   server_private_keyshare: 00708286c5fb629de5cfea56c0532dd8254a5a6e7fcc
   9e51e20a1cf4f254335ca57ce603ae7cf03fc00b7a2d495298d84c8c83b686b67e825
   69cb56d97e9c20e5932
   client_private_keyshare: 0037735d573abb787b251879b77de4df554c91e25e11



Krawczyk, et al.         Expires 25 August 2021                [Page 62]


Internet-Draft                   OPAQUE                    February 2021


   7919a9db2af19b32ce0d501c9572d3a8a106f875023c9722b2de94efaa02c8e46a9e4
   8f3e2ee00241f9a75f4
   blind_registration: 0071a04b0f2180dda3c36e3d43c3a8f127158d010944b0d53
   a6f8da29c3cf4f8695135d645424c747bec642bc91375ff142da4687426b0b4f35c14
   eb2477c52e1fff
   blind_login: 01eea8a605644334de4987fb60d9aaec15b54fc65ef1e10520556b43
   938fbf81d4fbc8c36d787161fa4f1e6cf4f842989634f76f3320fdd24777894218769
   fc19651
   oprf_key: 0066b06b578fe36ef23a5b9872ade82b9261cc447670debcf78318add68
   2f6055089b0a2484abc37f110b36f4c2a140b7a3c53dd8efb6171d3bb4d73591be848
   3a1b

C.10.3.  Intermediate Values

   auth_key: 23a8d4aaf7686ae00f4a84defb8ebcf4a3d3ab1c1d7f00dcc8230a274e8
   f4119b3bdeae33a94b20638345f22bd5cf93364b9608eead0986996b22be509e393b5
   prk: 58200faa8a67d9c9a1ee140ae033e85709352b695d3763e2762212b682f28643
   c959615781e6609c945a24bd472de4e2a1f22eae10a243a79a6a0012b28285b0
   pseudorandom_pad: be47ed58f882053a44e0e21fd150a183873c4b9e9eb322ff42c
   0fd0540e6581eba71b4e573f4b17426a7e30bb284bf92f27a26c84efb47736acbf69d
   41094b4a1e9f
   envelope: 029ac2de6c1f7b8a32dfb4e365b2610797cc5b76e9d5a1e0d016c08c332
   85785a9be3065425d7f96448373cc6d8b949b844c02eb7795f3c2af5cab2139d7b754
   c32e041988ed97b341d986553f0ee1b46ac5d084bb1df68119cff04f30f5f9a60386e
   dd50851bfa6ebc2ac5bb71b2fdff06030d4b0c94c48edbf14d8027a21c4bfc85f2d85
   796ecfdadeb002b0016188916fbdb56a428f9832fd79dc25d2e8e9b32c83
   handshake_secret: 06ea9f5f3f553146bafeab9bb6bc590a2419ebbceae34266cb3
   3717649c3f65dc8f993ebbe0e0c59068e58ecc4b5353fbd461588b5d9e8767b778d6c
   099fdb83
   handshake_encrypt_key: a3df7662b4d47d0b6133723e79a81ff74fc3413a0f2c09
   cca44cbd4bba92d13335483ef31ef5cce3722df00bb8ac14dcb3b547a83415a5e4d0e
   47a41f37864ef
   server_mac_key: 9d355b34e8a737eb8306345fb9a58e613fb04d67f6035d47ff5df
   6dbebb9d5875ed8fa0ec09d99f97efca1ba448781659de9092976b9ccdbb5f4c78a71
   d739e3
   client_mac_key: a90767cfd8eebccfd4b7edee797a0a6416d75014524b11f0fc7c0
   508395cb03bcc2489358a44d6451ae52952b61bf9891f4599aaaf2b7f7ac0a563aad0
   c9bee9

C.10.4.  Output Values











Krawczyk, et al.         Expires 25 August 2021                [Page 63]


Internet-Draft                   OPAQUE                    February 2021


   registration_request: 020197d8111818258667ffbc0d377602f74350b7a54e684
   1fb15ba96ac07095bcfc961a2c21e2e0061ba28cd4ea0ed93fa0404f1383b777483c3
   31537c8e6e69af85b0
   registration_response: 020013e275bf8d4c305cd3793a5be014f9b338b12c6f97
   7aef5d523cff2c753b5e6d0f2602fa8359918eaf2fb4ccfb0ae79c383f698ee0fff3a
   05d6ce9e5b28e762b0b0300d1df68b2171f58ffc6a2cdf6cd47f4a672e0c06660ad5e
   c9cccbd8fafd4593dc847b3a3a7aedd1baf2d03dad24f1da95e884f3554c0d4915b0d
   47172f33eab7f0e
   registration_upload: 0300ec0addd1ade650f8c2be98b2d7b5b5eb7e1eab56823f
   9413327e056e1413055ede83bd893a26f61094a87d108431dc4f95366741da7ec6465
   208b9080d17ed304a029ac2de6c1f7b8a32dfb4e365b2610797cc5b76e9d5a1e0d016
   c08c33285785a9be3065425d7f96448373cc6d8b949b844c02eb7795f3c2af5cab213
   9d7b754c32e041988ed97b341d986553f0ee1b46ac5d084bb1df68119cff04f30f5f9
   a60386edd50851bfa6ebc2ac5bb71b2fdff06030d4b0c94c48edbf14d8027a21c4bfc
   85f2d85796ecfdadeb002b0016188916fbdb56a428f9832fd79dc25d2e8e9b32c83
   KE1: 02013ffd159c4d44f7fe2441c05614ef421e7fc7285432d5dd3b67ada061f3e3
   a230d1ab200864a9a716cd001d2a6abea298d58fded61f7d9ce02fc1bb037a1bbf9c7
   caff297d07060f891faa127a937e7e7995d76ec727abf796dc80c31595bf8e2010009
   68656c6c6f20626f62030035c078a34aacc22e0e759115b9c7c45192d97e4970f4037
   676039e7bc2d270c3964e81a9009a788b022eac506ac16c9704efe50ff6041bd3c942
   29673d2073d8bc
   KE2: 0200e302a5573d3625a0f9d0f63398f4c5053d4f816c743ab77bb365a36c3cdd
   00fe21ae2a7e56c01f0857ecdb4d129480c189cbe61f78a2aaaa4687126b76a6cf0ce
   20300d1df68b2171f58ffc6a2cdf6cd47f4a672e0c06660ad5ec9cccbd8fafd4593dc
   847b3a3a7aedd1baf2d03dad24f1da95e884f3554c0d4915b0d47172f33eab7f0e029
   ac2de6c1f7b8a32dfb4e365b2610797cc5b76e9d5a1e0d016c08c33285785a9be3065
   425d7f96448373cc6d8b949b844c02eb7795f3c2af5cab2139d7b754c32e041988ed9
   7b341d986553f0ee1b46ac5d084bb1df68119cff04f30f5f9a60386edd50851bfa6eb
   c2ac5bb71b2fdff06030d4b0c94c48edbf14d8027a21c4bfc85f2d85796ecfdadeb00
   2b0016188916fbdb56a428f9832fd79dc25d2e8e9b32c835f07f6b2c9a546f77d2e58
   ae23af2960f3f723fa00bc8c6c9c537683dc37209103009af99de97de5c0b5bb5299c
   406e53294dc48a78ba4933df0e01bf8e1c5e46fe1de6e82060a08a9110c435fd784b9
   ae31ecb639eabd464a16819126be3b865b05e9000fe366a1b3fae5ebfbe29ace6edfd
   cca85428f071a2a410205f3792aa810a0b69107ee1c97c3588e4a798072e69b2555e3
   3928a38b81b90daf4cb0d80b2a3fee7d81bd3a67de7620c11927684533f2c7
   KE3: b825f4735127be2e5870088690ceb1d107122f9febe6ff95cf5d2c2ccee473a9
   1db656b5d47824a7dd2e1d4180cdf01482461eb341627d70b18ee61c63b6c534
   export_key: a1e47a5e5d13c00290f0207542cf3db49c76c57dddc1eb6f8e35e17fd
   f04e32ef769ee58605783e4e6c86c5823596d5fab79f42c1f992137554ca4281c3038
   d2
   session_key: 11396799cfb47fe2379020b8f706c520115858f0c59c4fdb1db2a5c4
   49e6c08f53f75e77b2712d2ba977c5ba85e07d98cbdf8dc7a98700eb61b50d2cda4b8
   a08

Authors' Addresses






Krawczyk, et al.         Expires 25 August 2021                [Page 64]


Internet-Draft                   OPAQUE                    February 2021


   Hugo Krawczyk
   Algorand Foundation

   Email: hugokraw@gmail.com


   Kevin Lewi
   Novi Research

   Email: lewi.kevin.k@gmail.com


   Christopher A. Wood
   Cloudflare

   Email: caw@heapingbits.net



































Krawczyk, et al.         Expires 25 August 2021                [Page 65]