]>

d@bytema.re

AWS

hugokraw@gmail.com

Meta

lewi.kevin.k@gmail.com

Cloudflare, Inc.

caw@heapingbits.net

Internet-Draft This document describes the OPAQUE protocol, an augmented (or 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 and one instantiation based on 3DH. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction Password authentication is ubiquitous in many applications. In a common implementation, a client authenticates to a server by sending its client ID and password to the server over a secure connection. This makes the password vulnerable to server mishandling, including accidentally logging the password or storing it in plaintext in a database. Server compromise resulting in access to these plaintext passwords is not an uncommon security incident, even among security-conscious organizations. Moreover, plaintext password authentication over secure channels such as TLS is also vulnerable to cases where TLS may fail, including PKI attacks, certificate mishandling, termination outside the security perimeter, visibility to TLS-terminating intermediaries, and more. Augmented (or Asymmetric) 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 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. Indeed, some attacks are inevitable, such as online impersonation attempts with guessed client passwords and offline dictionary attacks upon the compromise of a server and leakage of its credential 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. This document describes OPAQUE, an aPAKE that is secure against pre-computation attacks (as defined in ). OPAQUE provides forward secrecy with respect to password leakage while also hiding the password from the server, even during password registration. OPAQUE allows applications to increase the difficulty of offline dictionary attacks via iterated hashing or other key-stretching schemes. OPAQUE is also extensible, allowing clients to safely store and retrieve arbitrary application data on servers using only their password. OPAQUE is defined and proven as the composition of three functionalities: an oblivious pseudorandom function (OPRF), a key recovery mechanism, 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 for requirements of the OPRF and AKE protocols.) This document specifies one OPAQUE instantiation based on . Other instantiations are possible, as discussed in , 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., TLS or HMQV, 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 information used to recover authentication credentials on the server. Recovering these credentials can only be done with knowledge of the client password. In the second stage, a client uses its password to recover those credentials and subsequently uses them as input to an AKE protocol. This stage has additional mechanisms to prevent an active attacker from interacting with the server to guess or confirm clients registered via the first phase. Servers can use this mechanism to safeguard registered clients against this type of enumeration attack; see for more discussion. The name OPAQUE is a homonym of O-PAKE where O is for Oblivious. The name OPAKE was taken. This draft complies with the requirements for PAKE protocols set forth in . This document represents the consensus of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard.

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 when, and only when, they appear in all capitals, as shown here.

Notation The following functions are used throughout this document:

• I2OSP and OS2IP: Convert a byte string to and from a non-negative integer as described in Section 4 of . 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.
• zeroes(n): Generate a string of n bytes all equal to 0 (zero).
• xor(a,b): Apply XOR to byte strings. For example, xor(0xF0F0, 0x1234) = 0xE2C4. It is an error to call this function with arguments of unequal length.
• ct_equal(a, b): Return true if a is equal to b, and false otherwise. The implementation of this function must be 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 , or pseudorandom function. For convenience, we define nil as a lack of value. All protocol messages and structures defined in this document use the syntax from Section 3 of .

Cryptographic Dependencies OPAQUE depends on the following cryptographic protocols and primitives:

• Oblivious Pseudorandom Function (OPRF);
• Key Derivation Function (KDF);
• Message Authentication Code (MAC);
• Cryptographic Hash Function;
• Key Stretching Function (KSF);

This section describes these protocols and primitives in more detail. Unless said otherwise, all random nonces and seeds used in these dependencies and the rest of the OPAQUE protocol are of length Nn and Nseed bytes, respectively, where Nn = Nseed = 32.

Oblivious Pseudorandom Function An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between client and server for computing a PRF, where the PRF key is held by the server and the input to the function is provided by the client. The client does not learn anything about the PRF other than the obtained output and the server learns nothing about the client's input or the function output. This specification depends on the prime-order OPRF construction specified as modeOPRF (0x00) from Section 3.1 of . The following OPRF client APIs are used:

• Blind(element): Create and output (blind, blinded_element), consisting of a blinded representation of input element, denoted blinded_element, along with a value to revert the blinding process, denoted blind.
• Finalize(element, blind, evaluated_element): Finalize the OPRF evaluation using input element, random inverter blind, and evaluation output evaluated_element, yielding output oprf_output.

Moreover, the following OPRF server APIs are used:

• BlindEvaluate(k, blinded_element): Evaluate blinded input element blinded_element using input key k, yielding output element evaluated_element. This is equivalent to the BlindEvaluate function described in Section 3.3.1 of , where k is the private key parameter.
• DeriveKeyPair(seed, info): Create and output (sk, pk), consisting of a private and public key derived deterministically from a seed and info parameter, as described in Section 3.2 of .

Finally, this specification makes use of the following shared APIs and parameters:

• SerializeElement(element): Map input element to a fixed-length byte array.
• DeserializeElement(buf): Attempt to map input byte array buf to an OPRF group element. This function can raise a DeserializeError upon failure; see Section 2.1 of for more details.
• Noe: The size of a serialized OPRF group element output from SerializeElement.
• Nok: The size of an OPRF private key as output from DeriveKeyPair.

Key Derivation Function and Message Authentication Code A Key Derivation Function (KDF) is a function that takes some source of initial keying material and uses it to derive one or more cryptographically strong keys. This specification uses a KDF with the following API and parameters:

• Extract(salt, ikm): Extract a pseudorandom key of fixed length Nx bytes from input keying material ikm and an optional byte string salt.
• Expand(prk, info, L): Expand a pseudorandom key prk, using the string info, into L bytes of output keying material.
• Nx: The output size of the Extract() function in bytes.

This specification also makes use of a random-key robust Message Authentication Code (MAC). See for more details on this property. The API and parameters for the random-key robust MAC are as follows:

• MAC(key, msg): Compute a message authentication code over input msg with key key, producing a fixed-length output of Nm bytes.
• Nm: The output size of the MAC() function in bytes.

Hash Functions This specification makes use of a collision-resistant hash function with the following API and parameters:

• Hash(msg): Apply a cryptographic hash function to input msg, producing a fixed-length digest of size Nh bytes.
• Nh: The output size of the Hash() function in bytes.

This specification makes use of a Key Stretching Function (KSF), which is a slow and expensive cryptographic hash function with the following API:

• Stretch(msg): Apply a key stretching function to stretch the input msg and harden it against offline dictionary attacks. This function also needs to satisfy collision resistance.

Protocol Overview OPAQUE consists of two stages: registration and authenticated key exchange (AKE). In the first stage, a client registers its password with the server and stores its credential file on the server. In the second stage (also called the "login" or "online" stage), the client recovers its authentication material and uses it to perform a mutually authenticated key exchange.

Setup Prior to both stages, the client and server agree on a configuration that fully specifies the cryptographic algorithm dependencies necessary to run the protocol; see for details. The server chooses a pair of keys (server_private_key and server_public_key) for the AKE, and chooses a seed (oprf_seed) of Nh bytes for the OPRF. The server can use server_private_key and server_public_key with multiple clients. The server can also opt to use a different seed for each client (i.e. each client can be assigned a single seed), so long as they are maintained across the registration and online AKE stages, and kept consistent for each client (since an inconsistent mapping of clients to seeds could leak information as described in ).

Registration Registration is the only stage in OPAQUE that requires a server-authenticated channel with confidentiality and integrity: either physical, out-of-band, PKI-based, etc. The client inputs its credentials, which include its password and user identifier, and the server inputs its parameters, which include its private key and other information. The client output of this stage is a single value export_key that the client may use for application-specific purposes, e.g., as a symmetric key used to encrypt additional information for storage on the server. The server does not have access to this export_key. The server output of this stage is a record corresponding to the client's registration that it stores in a credential file alongside other clients registrations as needed. The registration flow is shown below, and the process is described in more detail in : registration response <------------------------- record -------------------------> ------------------------------------------------ | | v v export_key record ]]> These messages are named RegistrationRequest, RegistrationResponse, and RegistrationRecord, respectively. Their contents and wire format are defined in .

Online Authenticated Key Exchange In this second stage, a client obtains credentials previously registered with the server, recovers private key material using the password, and subsequently uses them as input to the AKE protocol. As in the registration phase, the client inputs its credentials, including its password and user identifier, and the server inputs its parameters and the credential file record corresponding to the client. The client outputs two values, an export_key (matching that from registration) and a session_key, the latter of which is the primary AKE output. The server outputs a single value session_key that matches that of the client. Upon completion, clients and servers can use these values as needed. The authenticated key exchange flow is shown below: AKE message 2 <------------------------- AKE message 3 -------------------------> ------------------------------------------------ | | v v (export_key, session_key) session_key ]]> These messages are named KE1, KE2, and KE3, respectively. They carry the messages of the concurrent execution of the key recovery process (OPRF) and the authenticated key exchange (AKE), and their corresponding wire formats are specified in . The rest of this document describes the specifics of these stages in detail. describes how client credential information is generated, encoded, and stored on the server during registration, and recovered during login. describes the first registration stage of the protocol, and describes the second authentication stage of the protocol. describes how to instantiate OPAQUE using different cryptographic dependencies and parameters.

Client Credential Storage and Key Recovery OPAQUE makes use of a structure called Envelope to manage client credentials. The client creates its Envelope on registration and sends it to the server for storage. On every login, the server sends this Envelope to the client so it can recover its key material for use in the AKE. Applications may pin key material to identities if desired. If no identity is given for a party, its value MUST default to its public key. The following types of application credential information are considered:

• client_private_key: The encoded client private key for the AKE protocol.
• client_public_key: The encoded client public 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 an account name. If not specified, it defaults to the client's public key.
• server_identity: The server identity. This is typically a domain name, e.g., example.com. If not specified, it defaults to the server's public key. See for information about this identity.

A subset of these credential values are used in the CleartextCredentials structure as follows: ; uint8 client_identity<1..2^16-1>; } CleartextCredentials; ]]> The function CreateCleartextCredentials constructs a CleartextCredentials structure given application credential information.

Key Recovery This specification defines a key recovery mechanism that uses the stretched OPRF output as a seed to directly derive the private and public keys using the DeriveDiffieHellmanKeyPair() function defined in .

Envelope Structure The key recovery mechanism defines its Envelope as follows: envelope_nonce: A randomly-sampled nonce of length Nn, used to protect this Envelope. auth_tag: An authentication tag protecting the contents of the envelope, covering envelope_nonce and CleartextCredentials.

Envelope Creation Clients create an Envelope at registration with the function Store defined below. Note that DeriveDiffieHellmanKeyPair in this function can fail with negligible probability. If this occurs, servers should re-run the function, sampling a new envelope_nonce, to completion.

Envelope Recovery Clients recover their Envelope during login with the Recover function defined below. In the case of EnvelopeRecoveryError being raised, all previously-computed intermediary values in this function MUST be deleted.

Registration The registration process proceeds as follows. The client inputs the following values:

• password: The client's password.
• creds: The client credentials, as described in .

The server inputs the following values:

• server_public_key: The server public key for the AKE protocol.
• credential_identifier: A unique identifier for the client's credential, generated by the server.
• client_identity: The optional client identity as described in .
• oprf_seed: A seed used to derive per-client OPRF keys.

The registration protocol then runs as shown below: response = CreateRegistrationResponse(request, server_public_key, credential_identifier, oprf_seed) response <------------------------- (record, export_key) = FinalizeRegistrationRequest(password, blind, response, server_identity, client_identity) record -------------------------> ]]> describes the formats for the above messages, and describes details of the functions and the corresponding parameters referenced above. At the end of this interaction, the server stores the record object as the credential file for each client along with the associated credential_identifier and client_identity (if different). Note that the values oprf_seed and server_private_key from the server's setup phase must also be persisted. The oprf_seed value SHOULD be used for all clients; see for the justification behind this, along with a description of the exception in which applications may choose to avoid the use of a global oprf_seed value across clients and instead sample OPRF keys uniquely for each client. The server_private_key may be unique for each client. Both client and server MUST validate the other party's public key before use. See for more details. Upon completion, the server stores the client's credentials for later use. Moreover, the client MAY use the output export_key for further application-specific purposes; see .

Registration Messages This section contains definitions of the RegistrationRequest, RegistrationResponse, and RegistrationRecord messages exchanged between client and server during registration. blinded_message: A serialized OPRF group element. evaluated_message: A serialized OPRF group element. server_public_key: The server's encoded public key that will be used for the online AKE stage. client_public_key: The client's encoded public key, corresponding to the private key client_private_key. masking_key: An encryption key used by the server with the sole purpose of defending against client enumeration attacks. envelope: The client's Envelope structure.

Registration Functions This section contains definitions of the functions used by client and server during registration, including CreateRegistrationRequest, CreateRegistrationResponse, and FinalizeRegistrationRequest.

CreateRegistrationRequest To begin the registration flow, the client executes the following function. This function can fail with an InvalidInputError error with negligible probability. A different input password is necessary in the event of this error.

CreateRegistrationResponse To process the client's registration request, the server executes the following function. This function can fail with a DeriveKeyPairError error with negligible probability. In this case, applications can choose a new credential_identifier for this registration record and re-run this function.

FinalizeRegistrationRequest To create the user record used for subsequent authentication and complete the registration flow, the client executes the following function. See for details about the output export_key usage.

Online Authenticated Key Exchange 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 the 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). This section describes the online authenticated key exchange protocol flow, message encoding, and helper functions. 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 . In the end, the client proves its knowledge of the password, and both client and server agree on (1) a mutually authenticated shared secret key and (2) any optional application information exchange during the handshake. In this stage, the client inputs the following values:

• password: The client's password.
• client_identity: The client identity, as described in .

The server inputs the following values:

• server_private_key: The server's private key for the AKE protocol.
• server_public_key: The server's public key for the AKE protocol.
• server_identity: The server identity, as described in .
• record: The RegistrationRecord object corresponding to the client's registration.
• credential_identifier: An identifier that uniquely represents the credential.
• oprf_seed: The seed used to derive per-client OPRF keys.

The client receives two outputs: a session secret and an export key. The export key is only available to the client and may be used for additional application-specific purposes, as outlined in . Clients MUST NOT use the output export_key before authenticating the peer in the authenticated key exchange protocol. See for more details about this requirement. The server receives a single output: a session secret matching the client's. The protocol runs as shown below: ke2 = GenerateKE2(server_identity, server_private_key, server_public_key, record, credential_identifier, oprf_seed, ke1) ke2 <------------------------- (ke3, session_key, export_key) = GenerateKE3(client_identity, server_identity, ke2) ke3 -------------------------> session_key = ServerFinish(ke3) ]]> Both client and server may use implicit internal state objects to keep necessary material for the OPRF and AKE, client_state and server_state, respectively. The client state ClientState may have the following fields:

• password: The client's password.
• blind: The random blinding inverter returned by Blind().
• client_ake_state: The ClientAkeState defined in .

The server state ServerState may have the following fields:

• server_ake_state: The ServerAkeState defined in .

Both of these states are ephemeral and should be erased after the protocol completes. The rest of this section describes these authenticated key exchange messages and their parameters in more detail. defines the structure of the messages passed between client and server in the above setup. describes details of the functions and corresponding parameters mentioned above. discusses internal functions used for retrieving client credentials, and discusses how these functions are used to execute the authenticated key exchange protocol.

AKE Messages In this section, we define the KE1, KE2, and KE3 structs that make up the AKE messages used in the protocol. KE1 is composed of a CredentialRequest and AuthRequest, and KE2 is composed of a CredentialResponse and AuthResponse. client_nonce: A fresh randomly generated nonce of length Nn. client_public_keyshare: A serialized client ephemeral public key of fixed size Npk. credential_request: A CredentialRequest structure. auth_request: An AuthRequest structure. server_nonce: A fresh randomly generated nonce of length Nn. server_public_keyshare: A server ephemeral public key of fixed size Npk, where Npk depends on the corresponding prime order group. server_mac: An authentication tag computed over the handshake transcript computed using Km2, defined below. credential_response: A CredentialResponse structure. auth_response: An AuthResponse structure. client_mac: An authentication tag computed over the handshake transcript of fixed size Nm, computed using Km2, defined below.

AKE Functions In this section, we define the main functions used to produce the AKE messages in the protocol. Note that this section relies on definitions of subroutines defined in later sections:

• CreateCredentialRequest, CreateCredentialResponse, RecoverCredentials defined in
• AuthClientStart, AuthServerRespond, AuthClientFinalize, and AuthServerFinalize defined in and

GenerateKE1 The GenerateKE1 function begins the AKE protocol and produces the client's KE1 output for the server.

GenerateKE2 The GenerateKE2 function continues the AKE protocol by processing the client's KE1 message and producing the server's KE2 output.

GenerateKE3 The GenerateKE3 function completes the AKE protocol for the client and produces the client's KE3 output for the server, as well as the session_key and export_key outputs from the AKE.

ServerFinish The ServerFinish function completes the AKE protocol for the server, yielding the session_key. Since the OPRF is a two-message protocol, KE3 has no element of the OPRF, and it, therefore, invokes the AKE's AuthServerFinalize directly. The AuthServerFinalize function takes KE3 as input and MUST verify the client authentication material it contains before the session_key value can be used. This verification is necessary to ensure forward secrecy against active attackers. This function MUST NOT return the session_key value if the client authentication material is invalid, and may instead return an appropriate error message such as ClientAuthenticationError, invoked from AuthServerFinalize.

Credential Retrieval This section describes the sub-protocol run during authentication to retrieve and recover the client credentials.

Credential Retrieval Messages This section describes the CredentialRequest and CredentialResponse messages exchanged between client and server to perform credential retrieval. blinded_message: A serialized OPRF group element. evaluated_message: A serialized OPRF group element. masking_nonce: A nonce used for the confidentiality of the masked_response field. masked_response: An encrypted form of the server's public key and the client's Envelope structure.

Credential Retrieval Functions This section describes the CreateCredentialRequest, CreateCredentialResponse, and RecoverCredentials functions used for credential retrieval.

CreateCredentialRequest The CreateCredentialRequest is used by the client to initiate the credential retrieval process, and it produces a CredentialRequest message and OPRF state. Like CreateRegistrationRequest, this function can fail with an InvalidInputError error with negligible probability. However, this should not occur since registration (via CreateRegistrationRequest) will fail when provided the same password input.

CreateCredentialResponse The CreateCredentialResponse function is used by the server to process the client's CredentialRequest message and complete the credential retrieval process, producing a CredentialResponse. There are two scenarios to handle for the construction of a CredentialResponse object: either the record for the client exists (corresponding to a properly registered client), or it was never created (corresponding to an unregistered client identity, possibly the result of an enumeration attack attempt). In the case of an existing record with the corresponding identifier credential_identifier, the server invokes the following function to produce a CredentialResponse: In the case of a record that does not exist and if client enumeration prevention is desired, the server MUST respond to the credential request to fake the existence of the record. The server SHOULD invoke the CreateCredentialResponse function with a fake client record argument that is configured so that:

• record.client_public_key is set to a randomly generated public key of length Npk
• record.masking_key is set to a random byte string of length Nh
• record.envelope is set to the byte string consisting only of zeros of length Nn + Nm

It is RECOMMENDED that a fake client record is created once (e.g. as the first user record of the application) and stored alongside legitimate client records. This allows servers to retrieve the record in a time comparable to that of a legitimate client record. Note that the responses output by either scenario are indistinguishable to an adversary that is unable to guess the registered password for the client corresponding to credential_identifier.

RecoverCredentials The RecoverCredentials function is used by the client to process the server's CredentialResponse message and produce the client's private key, server public key, and the export_key.

3DH Protocol This section describes the authenticated key exchange protocol for OPAQUE using 3DH, a 3-message AKE which satisfies the forward secrecy and KCI properties discussed in . The client AKE state ClientAkeState mentioned in has the following fields:

• client_secret: An opaque byte string of length Nsk.
• ke1: A value of type KE1.

The server AKE state ServerAkeState mentioned in has the following fields:

• expected_client_mac: An opaque byte string of length Nm.
• session_key: An opaque byte string of length Nx.

and specify the inner workings of client and server functions, respectively.

3DH Key Exchange Functions We assume the following functions to exist for all Diffie-Hellman key exchange variants:

• DeriveDiffieHellmanKeyPair(seed): Derive a private and public Diffie-Hellman key pair deterministically from the input seed. The type of the private key depends on the implementation, whereas the type of the public key is a byte string of Npk bytes.
• DiffieHellman(k, B): A function that performs the Diffie-Hellman operation between the private input k and public input B. The output of this function is a unique, fixed-length byte string.

It is RECOMMENDED to use Elliptic Curve Diffie-Hellman for this key exchange protocol. Implementations for recommended groups in , as well as groups covered by test vectors in , are described in the following sections.

3DH ristretto255 This section describes the implementation of the Diffie-Hellman key exchange functions based on ristretto255, as defined in .

• DeriveDiffieHellmanKeyPair(seed): This function is implemented as DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where DeriveKeyPair is as specified in Section 3.2 of . The public value from DeriveKeyPair is encoded using SerializeElement from Section 2.1 of .
• DiffieHellman(k, B): Implemented as scalar multiplication as described in Section 4 of after decoding B from its encoded input using the Decode function in Section 4.3.1 of . The output is then encoded using the SerializeElement function of the OPRF group described in Section 2.1 of .

3DH P-256 This section describes the implementation of the Diffie-Hellman key exchange functions based on NIST P-256, as defined in .

• DeriveDiffieHellmanKeyPair(seed): This function is implemented as DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where DeriveKeyPair is as specified in Section 3.2 of . The public value from DeriveKeyPair is encoded using SerializeElement from Section 2.1 of .
• DiffieHellman(k, B): Implemented as scalar multiplication as described in , after decoding B from its encoded input using the compressed Octet-String-to-Elliptic-Curve-Point method according to . The output is then encoded using the SerializeElement function of the OPRF group described in Section 2.1 of .

3DH Curve25519 This section describes the implementation of the Diffie-Hellman key exchange functions based on Curve25519, as defined in .

• DeriveDiffieHellmanKeyPair(seed): This function is implemented by returning the private key k based on seed (of length Nseed = 32 bytes), as described in Section 5 of , as well as the result of DiffieHellman(k, B), where B is the base point of Curve25519.
• DiffieHellman(k, B): Implemented using the X25519 function in Section 5 of . The output is then used raw, with no processing.

Key Schedule Functions This section contains functions used for the AKE key schedule.

Transcript Functions The OPAQUE-3DH key derivation procedures make use of the functions below, re-purposed from TLS 1.3 . Where CustomLabel is specified as: = "OPAQUE-" + Label; uint8 context<0..255> = Context; } CustomLabel; Derive-Secret(Secret, Label, Transcript-Hash) = Expand-Label(Secret, Label, Transcript-Hash, Nx) ]]> Note that the Label parameter is not a NULL-terminated string. OPAQUE-3DH can optionally include application-specific, shared context information in the transcript, such as configuration parameters or application-specific info, e.g. "appXYZ-v1.2.3". The OPAQUE-3DH key schedule requires a preamble, which is computed as follows.

Shared Secret Derivation The OPAQUE-3DH shared secret derived during the key exchange protocol is computed using the following helper function.

3DH Client Functions The AuthClientStart function is used by the client to create a KE1 structure. The AuthClientFinalize function is used by the client to create a KE3 message and output session_key using the server's KE2 message and recovered credential information.

3DH Server Functions The AuthServerRespond function is used by the server to process the client's KE1 message and public credential information to create a KE2 message. The AuthServerFinalize function is used by the server to process the client's KE3 message and output the final session_key.

Configurations An OPAQUE-3DH configuration is a tuple (OPRF, KDF, MAC, Hash, KSF, Group, Context) such that the following conditions are met:

• The OPRF protocol uses the modeOPRF configuration of Section 3.1 of and implements the interface in . Examples include ristretto255-SHA512 and P256-SHA256.
• The KDF, MAC, and Hash functions implement the interfaces in . Examples include HKDF for the KDF, HMAC for the MAC, and SHA-256 and SHA-512 for the Hash functions. If an extensible output function such as SHAKE128 is used then the output length Nh MUST be chosen to align with the target security level of the OPAQUE configuration. For example, if the target security parameter for the configuration is 128 bits, then Nh SHOULD be at least 32 bytes.
• The KSF is determined by the application and implements the interface in . As noted, collision resistance is required. Examples for KSF include Argon2id , scrypt , and PBKDF2 with fixed parameter choices. See for more information about this choice of function.
• The Group mode identifies the group used in the OPAQUE-3DH AKE. This SHOULD match that of the OPRF. For example, if the OPRF is ristretto255-SHA512, then Group SHOULD be ristretto255.

Context is the shared parameter used to construct the preamble in . This parameter SHOULD include any application-specific configuration information or parameters that are needed to prevent cross-protocol or downgrade attacks. Absent an application-specific profile, the following configurations are RECOMMENDED:

• ristretto255-SHA512, HKDF-SHA-512, HMAC-SHA-512, SHA-512, Argon2id(S = zeroes(16), p = 4, T = Nh, m = 2^21, t = 1, v = 0x13, K = nil, X = nil, y = 2), ristretto255
• P256-SHA256, HKDF-SHA-256, HMAC-SHA-256, SHA-256, Argon2id(S = zeroes(16), p = 4, T = Nh, m = 2^21, t = 1, v = 0x13, K = nil, X = nil, y = 2), P-256
• P256-SHA256, HKDF-SHA-256, HMAC-SHA-256, SHA-256, scrypt(N = 32768, r = 8, p = 1), P-256

The above recommended configurations target 128-bit security. Future configurations may specify different combinations of dependent algorithms, with the following considerations:

1. The size of AKE public and private keys -- Npk and Nsk, respectively -- must adhere to the output length limitations of the KDF Expand function. If HKDF is used, this means Npk, Nsk <= 255 * Nx, where Nx is the output size of the underlying hash function. See for details.
2. The output size of the Hash function SHOULD be long enough to produce a key for MAC of suitable length. For example, if MAC is HMAC-SHA256, then Nh could be 32 bytes.

Application Considerations Beyond choosing an appropriate configuration, there are several parameters which applications can use to control OPAQUE:

• Credential identifier: As described in , this is a unique handle to the client's credential being stored. In applications where there are alternate client identities that accompany an account, such as a username or email address, this identifier can be set to those alternate values. For simplicity, applications may choose to set credential_identifier to be equal to client_identity. Applications MUST NOT use the same credential identifier for multiple clients.
• Context information: As described in , applications may include a shared context string that is authenticated as part of the handshake. This parameter SHOULD include any configuration information or parameters that are needed to prevent cross-protocol or downgrade attacks. This context information is not sent over the wire in any key exchange messages. However, applications may choose to send it alongside key exchange messages if needed for their use case.
• Client and server identities: As described in , clients and servers are identified with their public keys by default. However, applications may choose alternate identities that are pinned to these public keys. For example, servers may use a domain name instead of a public key as their identifier. Absent alternate notions of identity, applications SHOULD set these identities to nil and rely solely on public key information.
• Configuration and envelope updates: Applications may wish to update or change their configuration or other parameters that affect the client's RegistrationRecord over time. Some reasons for changing these are to use different cryptographic algorithms, e.g., a different KSF with improved parameters, or to update key material that is cryptographically bound to the RegistrationRecord, such as the server's public key (server_public_key). Any such change will require users to re-register to create a new RegistrationRecord. Supporting these types of updates can be helpful for applications that anticipate such changes in their deployment setting.
• Password hardening parameters: Key stretching is done to help prevent password disclosure in the event of server compromise; see . There is no ideal or default set of parameters, though relevant specifications for KSFs give some reasonable defaults.
• Enumeration prevention: As described in , if servers receive a credential request for a non-existent client, they SHOULD respond with a "fake" response to prevent active client enumeration attacks. Servers that implement this mitigation SHOULD use the same configuration information (such as the oprf_seed) for all clients; see . In settings where this attack is not a concern, servers may choose to not support this functionality.
• Handling password changes: In the event of a password change, the client and server can run the registration phase using the new password as a fresh instance (ensuring to resample all random values). The resulting registration record can then replace the previous record corresponding to the client's old password registration.

Implementation Considerations This section documents considerations for OPAQUE implementations. This includes implementation safeguards and error handling considerations.

Implementation Safeguards Certain information created, exchanged, and processed in OPAQUE is sensitive. Specifically, all private key material and intermediate values, along with the outputs of the key exchange phase, are all secret. Implementations should not retain these values in memory when no longer needed. Moreover, all operations, particularly the cryptographic and group arithmetic operations, should be constant-time and independent of the bits of any secrets. This includes any conditional branching during the creation of the credential response, as needed to mitigate client enumeration attacks. As specified in and , OPAQUE only requires the client password as input to the OPRF for registration and authentication. However, if client_identity can be bound to the client's registration record (in that the identity will not change during the lifetime of the record), then an implementation SHOULD incorporate client_identity alongside the password as input to the OPRF. Furthermore, it is RECOMMENDED to incorporate server_identity alongside the password as input to the OPRF. These additions provide domain separation for clients and servers; see .

Handling Online Guessing Attacks Online guessing attacks (against any aPAKE) can be done from both the client side and the server side. In particular, a malicious server can attempt to simulate honest responses to learn the client's password. While this constitutes an exhaustive online attack, hence as expensive as an online guessing attack from the client side, it can be mitigated when the channel between client and server is authenticated, e.g., using server-authenticated TLS. In such cases, these online attacks are limited to clients and the authenticated server itself. Moreover, such a channel provides privacy of user information, including identity and envelope values. Additionally, note that a client participating in the online login stage will learn whether or not authentication is successful after receiving the KE2 message. This means that the server should treat any client which fails to send a subsequent KE3 message as an authentication failure. This can be handled in applications that wish to track authentication failures by, for example, assuming by default that any client authentication attempt is a failure unless a KE3 message is received by the server and passes ServerFinish without error.

Error Considerations Some functions included in this specification are fallible. For example, the authenticated key exchange protocol may fail because the client's password was incorrect or the authentication check failed, yielding an error. The explicit errors generated throughout this specification, along with conditions that lead to each error, are as follows:

• EnvelopeRecoveryError: The envelope Recover function failed to produce any authentication key material; .
• ServerAuthenticationError: The client failed to complete the authenticated key exchange protocol with the server; .
• ClientAuthenticationError: The server failed to complete the authenticated key exchange protocol with the client; .

Beyond these explicit errors, OPAQUE implementations can produce implicit errors. For example, if protocol messages sent between client and server do not match their expected size, an implementation should produce an error. More generally, if any protocol message received from the peer is invalid, perhaps because the message contains an invalid public key (indicated by the AKE DeserializeElement function failing) or an invalid OPRF element (indicated by the OPRF DeserializeElement), then an implementation should produce an error. The errors in this document are meant as a guide for implementors. They are not an exhaustive list of all the errors an implementation might emit. For example, an implementation might run out of memory.

Security Considerations OPAQUE is defined 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 derives a private key 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 existing authenticated key exchange protocols such as TLS.

Notable Design Differences The specification as written here differs from the original cryptographic design in and the corresponding CFRG document , both of which were used as input to the CFRG PAKE competition. This section describes these differences, including their motivation and explanation as to why they preserve the provable security of OPAQUE based on . The following list enumerates important functional differences that were made as part of the protocol specification process to address application or implementation considerations.

• Clients construct envelope contents without revealing the password to the server, as described in , whereas the servers construct envelopes in . This change adds to the security of the protocol. considered the case where the envelope was constructed by the server for reasons of compatibility with previous UC modeling. analyzes the registration phase as specified in this document. This change was made to support registration flows where the client chooses the password and wishes to keep it secret from the server, and it is compatible with the variant in that was originally analyzed.
• Envelopes do not contain encrypted credentials. Instead, envelopes contain information used to derive client private key material for the AKE. This change improves the assumption behind the protocol by getting rid of equivocality and random key robustness for the encryption function. The random-key robustness property defined in is only needed for the MAC function. This change was made for two reasons. First, it reduces the number of bytes stored in envelopes, which is a helpful improvement for large applications of OPAQUE with many registered users. Second, it removes the need for client applications to generate private keys during registration. Instead, this responsibility is handled by OPAQUE, thereby simplifying the client interface to the protocol.
• Envelopes are masked with a per-user masking key as a way of preventing client enumeration attacks. See for more details. This extension is not needed for the security of OPAQUE as an aPAKE but only used to provide a defense against enumeration attacks. In the analysis, the masking key can be simulated as a (pseudo) random key. This change was made to support real-world use cases where client or user enumeration is a security (or privacy) risk.
• Per-user OPRF keys are derived from a client identity and cross-user PRF seed as a mitigation against client enumeration attacks. See for more details. The analysis of OPAQUE assumes OPRF keys of different users are independently random or pseudorandom. Deriving these keys via a single PRF (i.e., with a single cross-user key) applied to users' identities satisfies this assumption. This change was made to support real-world use cases where client or user enumeration is a security (or privacy) risk. Note that the derivation of the OPRF key via a PRF keyed by oprf_seed and applied to the unique credential_identifier ensures the critical requirement of the per-user OPRF keys being unique per client.
• The protocol outputs an export key for the client in addition to a shared session key that can be used for application-specific purposes. This key is a pseudorandom value derived from the client password (among other values) and has no influence on the security analysis (it can be simulated with a random output). This change was made to support more application use cases for OPAQUE, such as the use of OPAQUE for end-to-end encrypted backups; see .
• The AKE describes a 3-message protocol where the third message includes client authentication material that the server is required to verify. This change (from the original 2-message protocol) was made to provide explicit client authentication and full forward security. The 3-message protocol is analyzed in .
• The protocol admits optional application-layer client and server identities. In the absence of these identities, the client and server are authenticated against their public keys. Binding authentication to identities is part of the AKE part of OPAQUE. The type of identities and their semantics are application-dependent and independent of the protocol analysis. This change was made to simplify client and server interfaces to the protocol by removing the need to specify additional identities alongside their corresponding public authentication keys when not needed.
• The protocol admits application-specific context information configured out-of-band in the AKE transcript. This allows domain separation between different application uses of OPAQUE. This is a mechanism for the AKE component and is best practice for domain separation between different applications of the protocol. This change was made to allow different applications to use OPAQUE without the risk of cross-protocol attacks.
• Servers use a separate identifier for computing OPRF evaluations and indexing into the registration record storage, called the credential_identifier. This allows clients to change their application-layer identity (client_identity) without inducing server-side changes, e.g., by changing an email address associated with a given account. This mechanism is part of the derivation of OPRF keys via a single PRF. As long as the derivation of different OPRF keys from a single PRF has different PRF inputs, the protocol is secure. The choice of such inputs is up to the application.
• comments on a defense against offline dictionary attacks upon server compromise or honest-but-curious servers. The authors suggest implementing the OPRF phase as a threshold OPRF , effectively forcing an attacker to act online or to control at least t key shares (among the total n), where t is the threshold number of shares necessary to recombine the secret OPRF key, and only then be able to run an offline dictionary attack. This implementation only affects the server and changes nothing for the client. Furthermore, if the threshold OPRF servers holding these keys are separate from the authentication server, then recovering all n shares would still not suffice to run an offline dictionary attack without access to the client record database. However, this mechanism is out of scope for this document.

The following list enumerates notable differences and refinements from the original cryptographic design in and the corresponding CFRG document that were made to make this specification suitable for interoperable implementations.

• used a generic prime-order group for the DH-OPRF and HMQV operations, and includes necessary prime-order subgroup checks when receiving attacker-controlled values over the wire. This specification instantiates the prime-order group used for 3DH using prime-order groups based on elliptic curves, as described in Section 2.1 of . This specification also delegates OPRF group choice and operations to Section 4 of . As such, the prime-order group as used in the OPRF and 3DH as specified in this document both adhere to the requirements as .
• specified DH-OPRF (see Appendix B) to instantiate the OPRF functionality in the protocol. A critical part of DH-OPRF is the hash-to-group operation, which was not instantiated in the original analysis. However, the requirements for this operation were included. This specification instantiates the OPRF functionality based on Section 3.3.1 of , which is identical to the DH-OPRF functionality in and, concretely, uses the hash-to-curve functions in . All hash-to-curve methods in are compliant with the requirement in , namely, that the output be a member of the prime-order group.
• and both used HMQV as the AKE for the protocol. However, this document fully specifies 3DH instead of HMQV (though a sketch for how to instantiate OPAQUE using HMQV is included in ). Since 3DH satisfies the essential requirements for the AKE as described in and , as recalled in , this change preserves the overall security of the protocol. 3DH was chosen for its simplicity and ease of implementation.
• The DH-OPRF and HMQV instantiation of OPAQUE in , Figure 12 uses a different transcript than that which is described in this specification. In particular, the key exchange transcript specified in is a superset of the transcript as defined in . This was done to align with best practices, such as is done for key exchange protocols like TLS 1.3 .
• Neither nor included wire format details for the protocol, which is essential for interoperability. This specification fills this gap by including such wire format details and corresponding test vectors; see .

Security Analysis Jarecki et al. proved the security of OPAQUE (modulo the design differences outlined in ) in a strong aPAKE model that ensures security against pre-computation attacks and is formulated in the Universal Composability (UC) framework under the random oracle model. This assumes security of the OPRF function and the underlying key exchange protocol. OPAQUE's design builds on a line of work initiated in the seminal paper of Ford and Kaliski and is based on the HPAKE protocol of Xavier Boyen and the (1,1)-PPSS protocol from Jarecki et al. . None of these papers considered security against pre-computation attacks or presented a proof of aPAKE security (not even in a weak model). 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 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). In , security is proven for one instance (i.e., one key) of the OPAQUE protocol, and without batching. There is currently no security analysis available for the OPAQUE protocol described in this document in a setting with multiple server keys or batching. As stated in , incorporating client_identity adds domain separation, in particular against servers that choose the same OPRF key for multiple clients. The client_identity as input to the OPRF also acts as a key identifier that would be required for a proof of the protocol in the multi-key setting; the OPAQUE analysis in assumes single server-key instances. Adding server_identity to the OPRF input provides domain separation for clients that reuse the same client_identity across different server instantiations.

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. Note that the method of transmission of client_identity from client to server is outside the scope of this protocol, and it is up to an application to choose how this identity should be delivered (for instance, alongside the first OPAQUE message, or perhaps agreed upon before the OPAQUE protocol begins). 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 the envelope (hence determined during password registration) and to tie 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 aliases 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 of 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 match 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.

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 client wishes to store secrets with a third party, then this export key can be used by the client to encrypt these secrets so that they remain hidden from a passive adversary that does not have access to the server's secret keys or the client's password.

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 and Cheon 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 Section 7.2.3 of 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.

Random-Key Robust MACs The random-key robustness property for a MAC states that, given two random keys k1 and k2, it is infeasible to find a message m such that MAC(k1, m) = MAC(k2, m). Note that in general, not every MAC function is key-robust. In particular, GMAC (which underlies GCM) does not satisfy key-robustness, whereas HMAC with a collision-resistant hash function does satisfy key-robustness. An application can choose to use a non-key-robust MAC within the AKE portion of the protocol described in , but it MUST use a key-robust MAC for the creation of the auth_tag parameter in .

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

OPRF Key Stretching Applying a key stretching function to the output of the OPRF greatly increases the cost of an offline attack upon the compromise of the credential file on the server. Applications SHOULD select parameters for the KSF that balance cost and complexity across different client implementations and deployments. Note that in OPAQUE, the key stretching function is executed by the client, as opposed to the server in traditional password hashing scenarios. This means that applications must consider a tradeoff between the performance of the protocol on clients (specifically low-end devices) and protection against offline attacks after a server compromise.

Client Enumeration Client enumeration refers to attacks where the attacker tries to learn whether a given user identity is registered with a server or whether a re-registration or change of password was performed for that user. OPAQUE counters these attacks by requiring servers to act with unregistered client identities in a way that is indistinguishable from their behavior with existing registered clients. Servers do this by simulating a fake CredentialResponse as specified in for unregistered users, and also encrypting CredentialResponse using a masking key. In this way, real and fake CredentialResponse messages are indistinguishable from one another. Implementations must also take care to avoid side-channel leakage (e.g., timing attacks) from helping differentiate these operations from a regular server response. Note that this may introduce possible abuse vectors since the server's cost of generating a CredentialResponse is less than that of the client's cost of generating a CredentialRequest. Server implementations may choose to forego the construction of a simulated credential response message for an unregistered client if these client enumeration attacks can be mitigated through other application-specific means or are otherwise not applicable for their threat model. OPAQUE does not prevent this type of attack during the registration flow. Servers necessarily react differently during the registration flow between registered and unregistered clients. This allows an attacker to use the server's response during registration as an oracle for whether a given client identity is registered. Applications should mitigate against this type of attack by rate limiting or otherwise restricting the registration flow. Finally, applications that do not require protection against client enumeration attacks can choose to derive independent OPRF keys for different clients. The advantage to using independently-derived OPRF keys is that the server avoids keeping the oprf_seed value across different clients, which if leaked would compromise the security for all clients reliant on oprf_seed, as noted in .

Protecting the Registration Masking Key The user enumeration prevention method described in this document uses a symmetric encryption key, masking_key, generated and sent to the server by the client during registration. This requires a confidential channel between client and server during registration, e.g., using TLS . If the channel is only authenticated (this is a requirement for correct identification of the parties), a confidential channel can be established using public-key encryption, e.g., with HPKE . However, the details of this mechanism are out of scope for this document.

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 (single-server) aPAKE protocol. It can be avoided in the case of OPAQUE by resorting to a multi-server threshold OPRF implementation, e.g., . Furthermore, if the server does not sample the PRF seed with sufficiently high entropy, or if it is not kept hidden from an adversary, then any derivatives from the client's password may also be susceptible to an offline dictionary attack to recover the original password. Some applications may require learning the client's password to enforce password rules. Doing so invalidates this important security property of OPAQUE and is NOT RECOMMENDED, unless it is not possible for applications to move such checks to the client. Note that limited checks at the server are possible to implement, e.g., detecting repeated passwords upon re-registrations or password change. In general, passwords should be selected with sufficient entropy to avoid being susceptible to recovery through dictionary attacks, both online and offline.

AKE Private Key Storage Server implementations of OPAQUE do not need access to the raw AKE private key. They only require the ability to compute shared secrets as specified in . Thus, applications may store the server AKE private key in a Hardware Security Module (HSM) or similar. Upon compromise of the OPRF seed and client envelopes, this would prevent an attacker from using this data to mount a server spoofing attack. Supporting implementations need to consider allowing separate AKE and OPRF algorithms in cases where the HSM is incompatible with the OPRF algorithm.

Client Authentication Using Credentials For scenarios in which the client has access to private state that can be persisted across registration and login, the client can back up the randomized_password variable (as computed in ) so that upon a future login attempt, the client can authenticate to the server using randomized_password instead of the original password. This can be achieved by supplying an arbitrary password as input to CreateCredentialRequest in the login phase, and then using randomized_password from the backup in RecoverCredentials (invoked by GenerateKE3) rather than computing it from the password. This provides an advantage over the regular authentication flow for login in that if randomized_password is compromised, an adversary cannot use this value to successfully impersonate the server to the client during login. The drawback is that it is only applicable to settings where randomized_password can be treated as a credential which can be stored securely after registration and retrieved upon login.

IANA Considerations This document makes no IANA requests.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between a client and a server for computing the output of a Pseudorandom Function (PRF). The server provides the PRF private key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF private key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of 'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially oblivious, called a POPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Informative References n.d. National Institute of Standards and Technology (NIST) National Institute of Standards and Technology n.d. n.d. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password. This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group (CFRG). This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This memo specifies two prime-order groups, ristretto255 and decaf448, suitable for safely implementing higher-level and complex cryptographic protocols. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group. Likewise, the decaf448 group can be implemented using edwards448. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. National Institute of Standards and Technology (U.S.) This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer-oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema. This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques. This document represents a republication of PKCS #5 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 2898. This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

Acknowledgments 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, Matt Campagna, Eric Crockett, Paul Grubbs, Fredrik Kuivinen, Stefan Marsiske, Payman Mohassel, Marta Mularczyk, Jason Resch, Greg Rubin, and Nick Sullivan. Hugo Krawczyk wishes to thank his OPAQUE co-authors Stas Jarecki and Jiayu Xu without whom this work would have not been possible.

Alternate Key Recovery Mechanisms Client authentication material can be stored and retrieved using different key recovery mechanisms. Any key recovery mechanism that encrypts data in the envelope MUST use an authenticated encryption scheme with random key-robustness (or key-committing). Deviating from the key-robustness requirement may open the protocol to attacks, e.g., . This specification enforces this property by using a MAC over the envelope contents. 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 authentication material is successfully recovered, i.e., after the MAC in RecoverCredentials passes verification.

Alternate AKE Instantiations It is possible to instantiate OPAQUE with other AKEs, such as HMQV and . 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. 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 . 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 and integrity of application data encrypted under session_key (or a key derived from it) with a quantum-safe encryption function. However, the only effect of a break of the OPRF by a future quantum attacker would be the ability of this attacker to run at that time an exhaustive dictionary attack against the old user's password and only for users whose envelopes were harvested while in use (in the case of OPAQUE run over a TLS channel with the server, harvesting such envelopes requires targeted active attacks).

HMQV Instantiation Sketch An HMQV instantiation would work similarly to OPAQUE-3DH, differing primarily in the key schedule . First, the key schedule preamble value would use a different constant prefix -- "HMQV" instead of "3DH" -- as shown below. 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: Likewise, servers would compute IKM as follows: In both cases, u would be computed as follows: Likewise, s would be computed as follows: 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. Both parties should perform validation (as in ) on each other's public keys before computing the above parameters.

SIGMA-I Instantiation Sketch A instantiation differs more drastically from OPAQUE-3DH since authentication uses digital signatures instead 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 public keys exchanged between client and server.

Test Vectors This section contains real and fake test vectors for the OPAQUE-3DH specification. Each real test vector in specifies the configuration information, protocol inputs, intermediate values computed during registration and authentication, and protocol outputs. Similarly, each fake test vector in specifies the configuration information, protocol inputs, and protocol outputs computed during the authentication of an unknown or unregistered user. Note that masking_key, client_private_key, and client_public_key are used as additional inputs as described in . client_public_key is used as the fake record's public key, and masking_key for the fake record's masking key parameter. All values are encoded in hexadecimal strings. The configuration information includes the (OPRF, Hash, KSF, KDF, MAC, Group, Context) tuple, where the Group matches that which is used in the OPRF. The KSF used for each test vector is the identity function (denoted Identity), which returns as output the input message supplied to the function without any modification, i.e., msg = Stretch(msg).

Real Test Vectors

OPAQUE-3DH Real Test Vector 1

Configuration

Input Values

Intermediate Values

Output Values

OPAQUE-3DH Real Test Vector 2

Configuration

Input Values

Intermediate Values

Output Values

OPAQUE-3DH Real Test Vector 3

Configuration

Input Values

Intermediate Values

Output Values

OPAQUE-3DH Real Test Vector 4

Configuration

Input Values

Intermediate Values

Output Values

OPAQUE-3DH Real Test Vector 5

Configuration

Input Values

Intermediate Values

Output Values

OPAQUE-3DH Real Test Vector 6

Configuration

Input Values

Intermediate Values

Output Values

Fake Test Vectors

OPAQUE-3DH Fake Test Vector 1

Configuration

Input Values

Output Values

OPAQUE-3DH Fake Test Vector 2

Configuration

Input Values

Output Values

OPAQUE-3DH Fake Test Vector 3

Configuration

Input Values

Output Values