The OPAQUE Asymmetric PAKE Protocol
Algorand Foundation
hugokraw@gmail.com
dan@bytema.re
Novi Research
lewi.kevin.k@gmail.com
Cloudflare
caw@heapingbits.net
Internet-Draft
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 and one instantiation
based on 3DH.
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 companies.
Moreover, plaintext password authentication over secure channels like
TLS is also vulnerable to cases where TLS may fail, including 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 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. 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 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 for requirements of the
OPRF and AKE protocols.) This document specifies one OPAQUE instantiation
based on 3DH . 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, 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 , 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.
This draft complies with the requirements for PAKE protocols set forth in
.
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.
- 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 , or pseudorandom function. For convenience, we define nil as a
lack of value.
The name OPAQUE is a homonym of O-PAKE where O is for Oblivious. The name
OPAKE was taken.
Cryptographic Dependencies
OPAQUE relies on the following cryptographic protocols and primitives:
-
Oblivious Pseudorandom Function (OPRF, , 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).
- 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.
- DeriveKeyPair(seed): Derive a private and public key pair deterministically
from a seed.
- Noe: The size of a serialized OPRF group element.
- Nok: The size of an OPRF private key.
Note that we only need the base mode variant (as opposed to the verifiable mode
variant) of the OPRF described in .
-
Key Derivation Function (KDF):
- 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 optional string info
into L bytes of output keying material.
- Nx: The output size of the Extract() function in bytes.
-
Message Authentication Code (MAC):
- 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 Function:
- 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.
-
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.
OPAQUE additionally depends on an Authenticated Key Exchange (AKE) protocol.
This specification defines one particular AKE based on 3DH; see .
We let Npk and Nsk denote the size of public and private keys, respectively,
used in the AKE. The AKE protocol must provide the following functions:
- RecoverPublicKey(private_key): Recover the public key related to the input private_key.
- DeriveAuthKeyPair(seed): Derive a private and public authentication key pair
deterministically from the input seed.
- GenerateKeyPair(): Return a randomly generated private and public key pair. This can be
implemented by generating a random private key sk, then computing pk = RecoverPublicKey(sk).
Finally, all random nonces used in this protocol are of length Nn = 32 bytes.
Protocol Overview
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. The client inputs its credentials,
which includes its password and user identifier, and the server inputs its
parameters, which includes 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., to encrypt additional information
to the server. The server output of this stage is a record corresponding to
the client's registration that it stores in a password file alongside other
client registrations as needed.
Registration is the only part in OPAQUE that requires an authenticated and
confidential channel, either physical, out-of-band, PKI-based, etc.
The registration flow is shown below:
registration response
<-------------------------
record
------------------------->
------------------------------------------------
| |
v v
export_key record
]]>
In the 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 an 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 password 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
]]>
The rest of this document describes the details of these stages in detail.
describes how client credential information is
generated, encoded, encrypted, and stored on the server. 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
OPAQUE makes use of a structure Envelope to manage client credentials.
This envelope holds information about its format and content for the client to
obtain its authentication material.
OPAQUE allows applications to either provide custom client private and public keys
for authentication, or to generate them internally. Each public and private key
value is encoded as a byte string, specific to the AKE protocol in which OPAQUE
is instantiated. These two options are defined as the internal and external
modes, respectively. See for their specifications.
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 normal 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.
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.
During protocol execution, the identity values can be stored in an
implementation-specific Credentials object with names matching the
values.
Envelope Structure
A client Envelope is constructed based on the EnvelopeMode, consisting
of an InnerEnvelope entry whose structure is determined by the mode. Future
modes MAY introduce alternate InnerEnvelope contents. Envelope is
defined as follows:
nonce: A unique nonce of length Nn used to protect this Envelope.
auth_tag: Authentication tag protecting the contents of the envelope, covering the envelope nonce,
InnerEnvelope, and CleartextCredentials.
inner_env: A mode dependent InnerEnvelope structure. See for its specifications.
The size of the serialized envelope is denoted Ne and varies based on the mode.
The exact value for Ne is specified in and .
Envelope Creation and Recovery
Clients create an Envelope at registration with the function CreateEnvelope defined below.
For the internal mode, implementations can choose to leave out the client_private_key
parameter, as it is not used. For the external mode, implementations are free to
additionally provide client_public_key to this function. With this, the public key does
not need to be recovered by BuildInnerEnvelope() and that function should be adapted
accordingly.
Clients recover their Envelope during authentication with the RecoverEnvelope
function defined below.
Envelope Modes
The EnvelopeMode specifies the structure and encoding of the
corresponding InnerEnvelope. This document specifies the values
of the two aforementioned modes:
Each EnvelopeMode defines its own InnerEnvelope structure and must implement
the following interface:
-
inner_env, client_public_key = BuildInnerEnvelope(randomized_pwd, nonce, client_private_key):
Build and return the mode's InnerEnvelope structure and the client's public key.
-
client_private_key, client_public_key = RecoverKeys(randomized_pwd, nonce, inner_env):
Recover and return the client's private and public keys for the AKE protocol.
The implementations of this interface for both internal and external modes
are in and , respectively.
The size of the envelope may vary between modes. If applications implement
, they MUST use the same envelope mode throughout
their lifecycle in order to avoid activity leaks due to mode switching.
Internal mode
In this mode, the client's private and public keys are deterministically derived
from the OPRF output.
With the internal key mode the EnvelopeMode value MUST be internal and the
InnerEnvelope is empty, and the size Ne of the serialized Envelope is Nn + Nm.
To generate the private key OPAQUE-3DH implements DeriveAuthKeyPair(seed) as follows:
HashToScalar(msg, dst) is as specified in ,
except that the dst parameter is "OPAQUE-HashToScalar".
Note that implementations are free to leave out the client_private_key
parameter, as it is not used.
Note that implementations are free to leave out the inner_env parameter,
as it is not used.
External mode
This mode allows applications to import or generate keys for the client. This
specification only imports the client's private key and internally recovers the
corresponding public key. Implementations are free to import both, in which case
the functions FinalizeRequest(), CreateEnvelope(), and BuildInnerEnvelope()
must be adapted accordingly.
With the external key mode the EnvelopeMode value MUST be external, and the
size Ne of the serialized Envelope is Nn + Nm + Nsk.
An encryption key is generated from the hardened OPRF output and used to encrypt
the client's private key, which is then stored encrypted in the InnerEnvelope.
On key recovery, the client's public key is recovered using the private key.
encrypted_creds : Encrypted client_private_key. Authentication of this field is
ensured with the auth_tag field in the envelope that covers this InnerEnvelope.
If the implementation provides the client_public_key, then BuildInnerEnvelope()
can skip the RecoverPublicKey() call.
Offline Registration
This section describes the registration flow, message encoding, and helper functions.
In a setup phase, the client chooses its password, and the server chooses its own pair
of private-public AKE keys (server_private_key, server_public_key) for use with the
AKE, along with a Nh-byte oprf_seed. The server can use the same pair of keys with multiple
clients and can opt to use multiple seeds (so long as they are kept consistent for
each client). These steps can happen offline, i.e., before the registration phase.
If using external mode, the client provides a key pair
(client_private_key, client_public_key)
for an AKE protocol which is suitable for use with OPAQUE; See .
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.
Once complete, the registration process proceeds as follows. The client inputs
the following values:
- password: client password.
- creds: client credentials, as described in .
The server inputs the following values:
- server_private_key: server private key for the AKE protocol.
- server_public_key: server public key for the AKE protocol.
- credential_identifier: client credential identifier.
- oprf_seed: seed used to derive per-client OPRF keys.
The registration protocol then runs as shown below:
(response, oprf_key) = CreateRegistrationResponse(request,
server_public_key,
credential_identifier,
oprf_seed)
response
<-------------------------
(record, export_key) = FinalizeRequest(client_private_key,
password,
blind,
response)
record
------------------------->
]]>
describes details of the functions and the
corresponding parameters referenced above.
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
- data
-
A serialized OPRF group element.
- 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.
- client_public_key
-
The client's encoded public key, corresponding to the private key client_private_key.
- masking_key
-
A key used by the server to preserve confidentiality of the envelope during login.
- envelope
-
The client's Envelope structure.
Registration Functions
CreateRegistrationRequest
CreateRegistrationResponse
FinalizeRequest
To create the user record used for further authentication, the client executes
the following function. In the internal key mode, the client_private_key is nil.
Depending on the mode, implementations are free to leave out the client_private_key
parameter (internal mode), or to additionally include client_public_key
(external mode). See {#envelope-creation-recovery} for more details.
See for details about the output export_key usage.
Upon completion of this function, the client MUST send record to the server.
Finalize Registration
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.
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 a mutually authenticated shared secret key.
In this stage, the client inputs the following values:
- password: client password.
- client_identity: client identity, as described in .
- client_info: optional, application-specific information to send to the server
during the handshake.
The server inputs the following values:
- server_private_key: server private for the AKE protocol.
- server_public_key: server public for the AKE protocol.
- server_identity: server identity, as described in .
- record: RegistrationUpload corresponding to the client's registration.
- credential_identifier: client credential identifier.
- oprf_seed: seed used to derive per-client OPRF keys.
- server_info: optional, application-specific information to send to the client
during the handshake.
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 . The output export_key MUST NOT be
used in any way before the protocol completes successfully. See
for more details about this requirement. The server receives a single output: a session
secret matching that of the client's.
The protocol runs as shown below:
ke2 = ServerInit(server_identity, server_private_key,
server_public_key, record,
credential_identifier, oprf_seed, ke1)
ke2
<-------------------------
(ke3,
server_info,
session_key,
export_key) = ClientFinish(password, client_identity,
server_identity, ke2)
ke3
------------------------->
session_key = ServerFinish(ke3)
]]>
The rest of this section describes these authenticated key exchange messages
and their parameters in more detail. discusses internal
functions used for retrieving client credentials, and discusses
how these functions are used to execute the authenticated key exchange protocol.
Credential Retrieval
Credential Retrieval Messages
- data
-
A serialized OPRF group element.
- data
-
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
CreateCredentialResponse
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 a client that has
yet to register).
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, the server invokes the
CreateCredentialResponse function where the record argument is configured so that:
- record.masking_key is set to a random byte string of length Nh, and
- record.envelope is set to the byte string consisting only of zeros, of length Ne
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.
AKE 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 protocol consists of three messages sent between
client and server, each computed using the following application APIs:
- ke1 = ClientInit(client_identity, password, client_info)
- ke2, client_info = ServerInit(server_identity, server_private_key, server_public_key, record, credential_identifier, oprf_seed, ke1)
- ke3, server_info, session_key, export_key = ClientFinish(password, client_identity, server_identity, ke2)
- session_key = ServerFinish(ke3)
Outputs ke1, ke2, and ke3 are the three protocol messages sent between client
and server. Outputs client_info and server_info correspond to the optional
information exchanged between client and server during the key exchange protocol.
And finally, session_key and export_key are outputs to be consumed by applications.
Applications can use session_key to derive additional keying material as needed.
Both ClientFinish and ServerFinish return an error if authentication failed. In this case,
clients and servers MUST NOT use any outputs from the protocol, such as session_key or
export_key. ClientInit and ServerInit both implicitly return internal state objects
client_state and server_state, respectively, with the following named fields:
and specify the inner working of these functions
and their parameters for clients and servers, respectively.
Prior to the execution of these functions, both the client and the server MUST agree
on a configuration; see for details.
Protocol Messages
;
uint8 client_keyshare[Npk];
} KE1;
]]>
- request
-
A CredentialRequest generated according to .
- client_nonce
-
A fresh randomly generated nonce of length Nn.
- 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.
;
uint8 server_mac[Nm];
} KE2;
]]>
- response
-
A CredentialResponse generated according to .
- server_nonce
-
A fresh randomly generated nonce of length Nn.
- 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.
- server_mac
-
An authentication tag computed over the handshake transcript computed using Km2,
defined below.
- client_mac
-
An authentication tag computed over the handshake transcript computed using
Km2, defined below.
Key Schedule Functions
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.
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 function.
Using this shared secret, further keys used for encryption and authentication are
computed using the following function.
External Client API
Internal Client Functions
External Server API
Internal Server Functions
Configurations
An OPAQUE-3DH configuration is a tuple (OPRF, KDF, MAC, Hash, MHF, EnvelopeMode, Group)
such that the following conditions are met:
- The OPRF protocol uses the "base mode" variant of and implements
the interface in . Examples include OPRF(ristretto255, SHA-512) and
OPRF(P-256, SHA-256).
- 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 MHF has fixed parameters, chosen by the application, and implements the
interface in . Examples include Argon2 ,
scrypt , and PBKDF2 with fixed parameter choices.
- EnvelopeMode value is as defined in , and is one of
internal or external.
- 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 OPRF(ristretto255, SHA-512),
then Group SHOULD be ristretto255.
Absent an application-specific profile, the following configurations are RECOMMENDED:
- OPRF(ristretto255, SHA-512), HKDF-SHA-512, HMAC-SHA-512, SHA-512, Scrypt(32768,8,1), internal, ristretto255
- OPRF(P-256, SHA-256), HKDF-SHA-256, HMAC-SHA-256, SHA-256, Scrypt(32768,8,1), internal, P-256
Future configurations may specify different combinations of dependent algorithms,
with the following considerations:
- 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.
- 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 the
32 bytes.
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 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).
Related Analysis
Jarecki et al. 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
under the random oracle model. This assumes security of the OPRF
function and the underlying key exchange protocol. In turn, the
security of the OPRF protocol from is proven
in the random oracle model under the One-More Diffie-Hellman assumption .
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.,
). 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 and SPAKE2+ .
We note that as shown in , these protocols, and any aPAKE
in the model from , 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 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).
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 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 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.
Envelope Encryption
The analysis of OPAQUE from requires the authenticated encryption scheme
used to produce the envelope in the external mode to have a special property called random key-robustness
(or key-committing). This specification enforces this property by utilizing
encrypt-then-MAC 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., .)
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 MAC in RecoverCredentials
passes verification.
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.
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 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.
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 . 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 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.
Preventing Client Enumeration
Client enumeration refers to attacks where the attacker tries to learn
extra information about the behavior of clients that have registered with
the server. There are two types of attacks we consider:
1) An attacker tries to learn whether a given client identity is registered
with a server, and
2) An attacker tries to learn whether a given client identity has recently
completed registration, or has re-registered (e.g. after a password change).
Preventing the first type of attack requires the server to act with
unregistered client identities in a way that is indistinguishable from its
behavior with existing registered clients. This is achieved in
for an unregistered client by simulating a
CredentialResponse for unregistered clients through the sampling of a
random masking_key value and relying on the semantic security provided by
the XOR-based pad over the envelope.
Implementations must employ care to avoid side-channel leakage (e.g.,
timing attacks) from helping differentiate these operations from a regular
server response.
Preventing the second type of attack requires the server to supply a
credential_identifier value for a given client identity, consistently between the
and steps.
Note that credential_identifier can be set to client_identity, for simplicity.
In the event of a server compromise that results in a re-registration of
credentials for all compromised clients, the oprf_seed value must be resampled,
resulting in a change in the oprf_key value for each client. Although this
change can be detected by an adversary, it is only leaked upon password rotation
after the exposure of the credential files.
Applications must use the same envelope mode when using this prevention
throughout their lifecycle. The envelope size varies from one to another,
and a switch in envelope mode could then be detected.
Finally, note that 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.
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 .)
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.
IANA Considerations
This document makes no IANA requests.
References
Normative References
Key words for use in RFCs to Indicate Requirement Levels
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.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
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.
Randomness Requirements for Security
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.
Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups
Cloudflare
Cloudflare
Cloudflare
An Oblivious Pseudorandom Function (OPRF) is a two-party protocol for
computing the output of a PRF. One party (the server) holds the PRF
secret key, and the other (the client) holds the PRF input. The
'obliviousness' property ensures that the server does not learn
anything about the client's input during the evaluation. The client
should also not learn anything about the server's secret PRF key.
Optionally, OPRFs can also satisfy a notion 'verifiability' (VOPRF).
In this setting, the client can verify that the server's output is
indeed the result of evaluating the underlying PRF with just a public
key. This document specifies OPRF and VOPRF constructions
instantiated within prime-order groups, including elliptic curves.
HMAC: Keyed-Hashing for Message Authentication
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
Informative References
HPAKE: Password Authentication Secure against Cross-Site User Impersonation
The static Diffie-Hellman problem
Universally composable security: A new paradigm for cryptographic protocols
Security analysis of the strong Diffie-Hellman problem
Server-assisted generation of a strong secret from a password
SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
National Institute of Standards and Technology (NIST)
A method for making password-based key exchange resilient to server compromise
AuCPace: Efficient verifier-based PAKE protocol tailored for the IIoT
Recommendation for pair-wise key-establishment schemes using discrete logarithm cryptography
OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Computation Attacks
Highly-efficient and composable password-protected secret sharing (or: how to protect your bitcoin wallet online)
Partitioning Oracle Attacks
n.d.
HMQV: A high-performance secure Diffie-Hellman protocol
Security Analysis of SPAKE2+
Signal recommended cryptographic algorithms
The SRP Authentication and Key Exchange System
This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. [STANDARDS-TRACK]
HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
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.
Requirements for Password-Authenticated Key Agreement (PAKE) Schemes
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).
The Transport Layer Security (TLS) Protocol Version 1.3
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.
PKCS #1: RSA Cryptography Specifications Version 2.2
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.
The memory-hard Argon2 password hash and proof-of-work function
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.
The scrypt Password-Based Key Derivation Function
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.
PKCS #5: Password-Based Cryptography Specification Version 2.0
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 memo provides information for the Internet community.
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.
Alternate AKE Instantiations
It is possible to instantiate OPAQUE with other AKEs, such as 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.
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 of application data encrypted
under session_key (or a key derived from it) with a quantum-safe encryption function.
HMQV Instantiation Sketch
An HMQV instantiation would work similar 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.
SIGMA-I Instantiation Sketch
A SIGMA-I 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 key shares exchanged between client and server.
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 .
OPAQUE-3DH Test Vector 10
OPAQUE-3DH Test Vector 11
OPAQUE-3DH Test Vector 12
OPAQUE-3DH Test Vector 13
OPAQUE-3DH Test Vector 14
OPAQUE-3DH Test Vector 15
OPAQUE-3DH Test Vector 16
OPAQUE-3DH Test Vector 17
OPAQUE-3DH Test Vector 18
OPAQUE-3DH Test Vector 19
OPAQUE-3DH Test Vector 20
OPAQUE-3DH Test Vector 21
OPAQUE-3DH Test Vector 22
OPAQUE-3DH Test Vector 23
OPAQUE-3DH Test Vector 24
OPAQUE-3DH Test Vector 25
OPAQUE-3DH Test Vector 26
OPAQUE-3DH Test Vector 27
OPAQUE-3DH Test Vector 28
OPAQUE-3DH Test Vector 29
OPAQUE-3DH Test Vector 30
OPAQUE-3DH Test Vector 31
OPAQUE-3DH Test Vector 32
OPAQUE-3DH Test Vector 33
OPAQUE-3DH Test Vector 34
OPAQUE-3DH Test Vector 35
OPAQUE-3DH Test Vector 36
OPAQUE-3DH Test Vector 37
OPAQUE-3DH Test Vector 38
OPAQUE-3DH Test Vector 39
OPAQUE-3DH Test Vector 40