The OPAQUE Asymmetric PAKE Protocol

1.1. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2. Notation

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

• Client (U): Entity which has knowledge of a password and wishes to authenticate.¶
• Server (S): Entity which authenticates clients using passwords.¶
• (skX, pkX): An AKE key pair used in role X; skX is the private key and pkX is the public key. For example, (skU, pkU) refers to U's private and public key.¶
• kX: An OPRF private key used in role X. For example, kU refers to U's private OPRF key.¶
• I2OSP and OS2IP: Convert a byte string to and from a non-negative integer as described in [RFC8017]. Note that these functions operate on byte strings in big-endian byte order.¶
• concat(x0, ..., xN): Concatenation of byte strings. concat(0x01, 0x0203, 0x040506) = 0x010203040506.¶
• random(n): Generate a random byte string of length n bytes.¶
• xor(a,b): XOR of byte strings; xor(0xF0F0, 0x1234) = 0xE2C4. It is an error to call this function with two arguments of unequal length.¶
• ct_equal(a, b): Return true if a is equal to b, and false otherwise. This function is constant-time in the length of a and b, which are assumed to be of equal length, irrespective of the values a or b.¶

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

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

3.1. Protocol messages

The OPAQUE protocol runs the OPRF protocol in two stages: registration and authenticated key exchange. A client and server exchange protocol messages in executing these stages. This section specifies the structure of these protocol messages using TLS notation (see [RFC8446], Section 3).¶

enum {
    registration_request(1),
    registration_response(2),
    registration_upload(3),
    credential_request(4),
    credential_response(5),
    (255)
} ProtocolMessageType;

struct {
    ProtocolMessageType msg_type;    /* protocol message type */
    uint24 length;                   /* remaining bytes in message */
    select (ProtocolMessage.msg_type) {
        case registration_request: RegistrationRequest;
        case registration_response: RegistrationResponse;
        case registration_upload: RegistrationUpload;
        case credential_request: CredentialRequest;
        case credential_response: CredentialResponse;
    };
} ProtocolMessage;

OPAQUE makes use of an additional structure Credentials to store user (client) credentials. A Credentials structure consists of secret and cleartext CredentialExtension values. Each CredentialExtension indicates the type of extension and carries the raw bytes. This specification includes extensions for OPAQUE, including:¶

• skU: The encoded user private key for the AKE protocol.¶
• pkU: The encoded user public key for the AKE protocol.¶
• pkS: The encoded server public key for the AKE protocol.¶
• idU: The user identity. This is an application-specific value, e.g., an e-mail address or normal account name.¶
• idS: The server identity. This is typically a domain name, e.g., example.com. See Section 3.5 for information about this identity.¶

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

The full Credentials encoding is as follows.¶

enum {
  skU(1),
  pkU(2),
  pkS(3),
  idU(4),
  idS(5),
  (255)
} CredentialType;

struct {
  CredentialType type;
  opaque data<0..2^16-1>;
} CredentialExtension;

struct {
  CredentialExtension secret_credentials<1..2^16-1>;
  CredentialExtension cleartext_credentials<0..2^16-1>;
} Credentials;

secret_credentials

OPAQUE credentials which require secrecy and authentication.¶

cleartext_credentials

OPAQUE credentials which require authentication but not secrecy.¶

Applications MUST include skU in secret_credentials and pkS in either cleartext_credentials or secret_credentials. All other CredentialExtension values are optional. It is RECOMMENDED that applications include pkS and idS in cleartext_credentials, as this allows servers to not store redundant encryptions of these values for each user in case the server uses the same values for multiple users.¶

Additionally, we assume helper functions SerializeExtensions and DeserializeExtensions which translate a list of CredentialExtension structures to and from a unique byte string encoding.¶

OPAQUE uses an Envelope structure to encapsulate an encrypted Credentials structure. It is encoded as follows.¶

struct {
  opaque nonce[32];
  opaque ct<1..2^16-1>;
  opaque auth_data<0..2^16-1>;
} InnerEnvelope;

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

nonce

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

ct

Encoding of encrypted and authenticated credential extensions list.¶

auth_data

Encoding of an authenticated credential extensions list.¶

auth_tag

Authentication tag protecting the contents of the envelope.¶

3.2. Offline registration stage

Registration is executed between a user U (running on a client machine) and a server S. It is assumed the server can identify the user and the client can authenticate the server during this registration phase. This is the only part in OPAQUE that requires an authenticated channel, either physical, out-of-band, PKI-based, etc. This section describes the registration flow, message encoding, and helper functions. Moreover, U has a key pair (skU, pkU) for an AKE protocol which is suitable for use with OPAQUE; See Section 3.3. (skU, pkU) may be randomly generated for the account or provided by the calling client. Clients MUST NOT use the same key pair (skU, pkU) for two different accounts.¶

To begin, U chooses password pwdU, and S chooses its own pair of private-public keys skS and pkS for use with the AKE. S can use the same pair of keys with multiple users. These steps can happen offline, i.e., before the registration phase. Once complete, the registration process proceeds as follows:¶

 Client (idU, pwdU, skU, pkU)                 Server (skS, pkS)
  -----------------------------------------------------------------
   request, metadata = CreateRegistrationRequest(pwdU)

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

            (response, kU) = CreateRegistrationResponse(request, pkS)

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

 record = FinalizeRequest(pwdU, skU, metadata, request, response)

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

                                             StoreUserRecord(record)

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

struct {
    opaque data<1..2^16-1>;
} RegistrationRequest;

struct {
    opaque data_blind<1..2^16-1>;
} RequestMetadata;

struct {
    opaque data<0..2^16-1>;
    opaque pkS<0..2^16-1>;
    CredentialType secret_types<1..255>;
    CredentialType cleartext_types<0..255>;
} RegistrationResponse;

struct {
    Envelope envelope;
    opaque pkU<0..2^16-1>;
} RegistrationUpload;

CreateRegistrationRequest(pwdU)

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

Output:
- request, a RegistrationRequest structure
- metadata, a RequestMetadata structure

Steps:
1. (r, M) = Blind(pwdU)
2. data = Serialize(M)
3. Create RegistrationRequest request with data
4. Create RequestMetadata metadata with Serialize(r)
5. Output (request, metadata)

CreateRegistrationResponse(request, pkS)

Parameters:
- secret_credentials_list, a list of CredentialType values clients should include
 in the secret_credentials list of their Credentials structure
- cleartext_credentials_list, a list of CredentialType values clients should include
 in the cleartext_credentials list of their Credentials structure

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

Output:
- response, a RegistrationResponse structure
- kU, Per-user OPRF key

Steps:
1. (kU, _) = KeyGen()
2. M = Deserialize(request.data)
3. Z = Evaluate(kU, M)
4. data = Z.encode()
5. Create RegistrationResponse response with
     (data, pkS, secret_credentials_list, cleartext_credentials_list)
6. Output (response, kU)

FinalizeRequest(pwdU, skU, metadata, request, response)

Parameters:
- params, the MHF parameters established out of band

Input:
- pwdU, an opaque byte string containing the user's password
- skU, the user's private key
- metadata, a RequestMetadata structure
- request, a RegistrationRequest structure
- response, a RegistrationResponse structure

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

Steps:
1. Z = Deserialize(response.data)
2. N = Unblind(input.data_blind, Z)
3. y = Finalize(pwdU, N, "OPAQUE00")
4. rwdU = HKDF-Extract("rwdU", Harden(y, params))
5. Create secret_credentials with CredentialExtensions matching that
   contained in response.secret_credentials_list
6. Create cleartext_credentials with CredentialExtensions matching that
   contained in response.cleartext_credentials_list
7. pt = SerializeExtensions(secret_credentials)
8. nonce = random(32)
9. pseudorandom_pad = HKDF-Expand(rwdU, concat(nonce, "Pad"), len(pt))
10. auth_key = HKDF-Expand(rwdU, concat(nonce, "AuthKey"), Nh)
11. export_key = HKDF-Expand(rwdU, concat(nonce, "ExportKey"), Nh)
12. ct = xor(pt, pseudorandom_pad)
13. auth_data = SerializeExtensions(cleartext_credentials)
14. Create InnerEnvelope contents with (nonce, ct, auth_data)
15. t = HMAC(auth_key, contents)
16. Create Envelope envU with (contents, t)
17. Create RegistrationUpload upload with envelope value (envU, pkU)
18. Output (upload, export_key)

3.3. Online authenticated key exchange stage

After registration, the user (through a client machine) and server run the authenticated key exchange stage of the OPAQUE protocol. This stage is composed of a concurrent OPRF and key exchange flow. The key exchange protocol is authenticated using the client and server private keys established during the offline phase; see Section 3.2. The type of keys MUST be suitable for the key exchange protocol. For example, if the key exchange protocol is 3DH, as described in Section 4.2, then the private and public keys must be Diffie-Hellman keys. At the end, the client proves the user's knowledge of the password, and both client and server agree on a mutually authenticated shared secret key.¶

This section describes the message flow, encoding, and helper functions used in this stage.¶

 Client (idU, pwdU)                           Server (skS, pkS)
  -----------------------------------------------------------------
   request, metadata = CreateCredentialRequest(pwdU)

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

         (response, pkU) = CreateCredentialResponse(request)

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

  creds, export_key = RecoverCredentials(pwdU, metadata, request, response)

                               (AKE with creds)
                              <================>

The protocol messages below do not include the AKE protocol. Instead, OPAQUE assumes the client and server run the AKE using the credentials recovered from the OPRF protocol.¶

Note also that the authenticated key exchange stage can run the OPRF and AKE protocols concurrently with interleaved and combined messages (while preserving the internal ordering of messages in each protocol). In all cases, the client needs to obtain envU and rwdU (i.e., complete the OPRF protocol) before it can use its own private key skU and the server's public key pkS in the AKE. See Section 4 for examples of this integration.¶

struct {
    opaque data<1..2^16-1>;
} CredentialRequest;

struct {
    opaque data<1..2^16-1>;
    Envelope envelope;
} CredentialResponse;

CreateCredentialRequest(pwdU)

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

Output:
- request, an CredentialRequest structure
- metadata, a RequestMetadata structure

Steps:
1. (r, M) = Blind(pwdU)
2. data = Serialize(M)
3. Create CredentialRequest request with data
4. Create RequestMetadata metadata with Serialize(r)
5. Output (request, metadata)

CreateCredentialResponse(request)

Input:
- request, a CredentialRequest structure

Output:
- response, a CredentialResponse structure
- pkU, public key of the user

Steps:
1. (kU, envU, pkU) = LookupUserRecord(request.id)
2. M = Deserialize(request.data)
3. Z = Evaluate(kU, M)
4. data = Z.encode()
5. Create CredentialResponse response with (data, envU)
6. Output (response, pkU)

RecoverCredentials(pwdU, metadata, request, response)

Parameters:
- params, the MHF parameters established out of band

Input:
- pwdU, an opaque byte string containing the user's password
- metadata, a RequestMetadata structure
- request, a RegistrationRequest structure
- response, a RegistrationResponse structure

Output:
- C, a Credentials structure
- export_key, an additional key

Steps:
1. Z = Deserialize(response.data)
2. N = Unblind(input.data_blind, Z)
3. y = Finalize(pwdU, N, "OPAQUE00")
4. contents = response.envelope.contents
5. nonce = contents.nonce
6. ct = contents.ct
7. rwdU = HKDF-Extract("rwdU", Harden(y, params))
8. pseudorandom_pad = HKDF-Expand(rwdU, concat(nonce, "Pad"), len(ct))
9. auth_key = HKDF-Expand(rwdU, concat(nonce, "AuthKey"), Nh)
10. export_key = HKDF-Expand(rwdU, concat(nonce, "ExportKey"), Nh)
11. expected_tag = HMAC(auth_key, contents)
12. If !ct_equal(response.envelope.auth_tag, expected_tag), raise DecryptionError
13. pt = xor(ct, pseudorandom_pad)
14. secret_credentials = DeserializeExtensions(pt)
15. cleartext_credentials = DeserializeExtensions(auth_data)
16. Create Credentials creds with (secret_credentials, cleartext_credentials)
17. Output creds, export_key

3.4. Export Key

In addition to Credentials, OPAQUE outputs an export_key that may be used for additional application-specific purposes. For example, one might expand the use of OPAQUE with a credential-retrieval functionality that is separate from the contents of the Credentials structure.¶

The exporter_key MUST NOT be used in any way before the HMAC value in the envelope is validated.¶

3.5. AKE Execution and Party Identities

The AKE protocol is run as part of the online authenticated key exchange flow described above. The AKE MUST authenticate the OPAQUE transcript, which consists of the encoded request and response messages exchanged during the OPRF computation and credential fetch flow.¶

Also, authenticated key-exchange 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 idU and idS. 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 idU to the identity the server uses to fetch envU (hence determined during password registration) and to tie idS to the server identity used by the client to initiate an offline password registration or online authenticated key exchange session. idS and idU can also be part of envU or be tied to the parties' public keys. In principle, it is possible that identities 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 user must always be those defined at time of password registration.¶

4.1. Key Schedule Utility Functions

The key derivation procedures for HMQV, 3DH, and SIGMA-I instantiations all make use of the functions below, re-purposed from TLS 1.3 [RFC8446].¶

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

Where HkdfLabel is specified as:¶

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

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

HKDF uses Hash as its underlying hash function, which is the same as that which is indicated by the OPAQUE instantiation.¶

4.2. Instantiation with HMQV and 3DH

The integration of OPAQUE with HMQV [HMQV] leads to the most efficient instantiation of OPAQUE in terms of exponentiations count. Performance is close to optimal due to the low cost of authentication in HMQV: Just 1/6 of an exponentiation for each party over the cost of a regular DH exchange. However, HMQV is encumbered by an IBM patent, hence we also present OPAQUE with 3DH which only differs in the key derivation function at the cost of two additional exponentiations (and less resilience to the compromise of ephemeral exponents). We note that 3DH serves as a basis for the key-exchange protocol of [SIGNAL]. Importantly, many other protocols follow a similar format with differences mainly in the key derivation function. This includes the Noise family of protocols. Extensions also apply to KEM-based AKE protocols as in many post-quantum candidates.¶

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

Km2 = HKDF-Expand-Label(handshake_secret, "server mac", "", Hash.length)
Km3 = HKDF-Expand-Label(handshake_secret, "client mac", "", Hash.length)
Ke2 = HKDF-Expand-Label(handshake_secret, "server enc", "", key_length)
Ke3 = HKDF-Expand-Label(handshake_secret, "client enc", "", key_length)

info = "HMQV keys" || I2OSP(len(nonceU), 2) || nonceU
                   || I2OSP(len(nonceS), 2) || nonceS
                   || I2OSP(len(idU), 2) || idU
                   || I2OSP(len(idS), 2) || idS

1. u' = (eskU + u\*skU) mod p
2. Khmqv = (epkS \* pkS^s)^u'

1. s' = (eskS + s\*skS) mod p
2. Khmqv = (epkU \* pkU^u)^s'

hashInput = I2OSP(len(epkU), 2) || epkU ||
            I2OSP(len(info), 2) || info ||
            I2OSP(len("client"), 2) || "client"
u = Hash(hashInput) mod (len(p)-1)

hashInput = I2OSP(len(epkS), 2) || epkS ||
            I2OSP(len(info), 2) || info ||
            I2OSP(len("server"), 2) || "server"
s = Hash(hashInput) mod (len(p)-1)

info = "3DH keys" || I2OSP(len(nonceU), 2) || nonceU
                  || I2OSP(len(nonceS), 2) || nonceS
                  || I2OSP(len(idU), 2) || idU
                  || I2OSP(len(idS), 2) || idS

K3dh = epkS^eskU || pkS^eskU || epkS^skU

K3dh = epkU^eskS || epkU^skS || pkU^eskS

4.3. Instantiation with SIGMA-I

We show the integration of OPAQUE with the 3-message SIGMA-I protocol [SIGMA]. This is an example of a signature-based protocol and also serves as a basis for integration of OPAQUE with TLS 1.3 as specified in [I-D.sullivan-tls-opaque]. This specification can be extended to the 4-message SIGMA-R protocol as used in IKEv2.¶

info = "SIGMA-I keys" || I2OSP(len(nonceU), 2) || nonceU
                      || I2OSP(len(nonceS), 2) || nonceS
                      || I2OSP(len(idU), 2) || idU
                      || I2OSP(len(idS), 2) || idS

6.1. Configuration Choice

Best practices regarding implementation of cryptographic schemes apply to OPAQUE. Particular care needs to be given to the implementation of the OPRF regarding testing group membership and avoiding timing and other side channel leakage in the hash-to-curve mapping. Drafts [I-D.irtf-cfrg-hash-to-curve] and [I-D.irtf-cfrg-voprf] have detailed instantiation and implementation guidance.¶

6.2. Static Diffie-Hellman Oracles

While one can expect the practical security of the OPRF function (namely, the hardness of computing the function without knowing the key) to be in the order of computing discrete logarithms or solving Diffie-Hellman, Brown and Gallant [BG04] and Cheon [Cheon06] show an attack that slightly improves on generic attacks. For the case that q-1 or q+1, where q is the order of the group G, has a t-bit divisor, they show an attack that calls the OPRF on 2^t chosen inputs and reduces security by t/2 bits, i.e., it can find the OPRF key in time 2^{q/2-t/2} and 2^{q/2-t/2} memory. For typical curves, the attack requires an infeasible number of calls and/or results in insignificant security loss (*). Moreover, in the OPAQUE application, these attacks are completely impractical as the number of calls to the function translates to an equal number of failed authentication attempts by a single user. For example, one would need a billion impersonation attempts to reduce security by 15 bits and a trillion to reduce it by 20 bits - and most curves will not even allow for such attacks in the first place (note that this theoretical loss of security is with respect to computing discrete logarithms, not in reducing the password strength).¶

(*) Some examples (courtesy of Dan Brown): For P-384, 2^90 calls reduce security from 192 to 147 bits; for NIST P-256 the options are 6-bit reduction with 2153 OPRF calls, about 14 bit reduction with 187 million calls and 20 bits with a trillion calls. For Curve25519, attacks are completely infeasible (require over 2^100 calls) but its twist form allows an attack with 25759 calls that reduces security by 7 bits and one with 117223 calls that reduces security by 8.4 bits.¶

6.3. Input validation

Both client and server MUST validate the other party's public key(s) used for the execution of OPAQUE. This includes the keys shared during the offline registration phase, as well as any keys shared during the online key agreement phase. The validation procedure varies depending on the type of key. For example, for OPAQUE instantiations using 3DH with P-256, P-384, or P-521 as the underlying group, validation is as specified in Section 5.6.2.3.4 of [keyagreement]. This includes checking that the coordinates are in the correct range, that the point is on the curve, and that the point is not the point at infinity. Additionally, validation MUST ensure the Diffie-Hellman shared secret is not the point at infinity. For X25519 and X448, validation is as described in [RFC7748]. In particular, where applicable, endpoints MUST check whether the Diffie-Hellman shared secret is the all-zero value and abort if so.¶

6.4. User authentication versus Authenticated Key Exchange

OPAQUE provides PAKE (password-based authenticated key exchange) functionality in the client-server setting. While in the case of user identification, wherein the focus is often on authentication, we stress that the key exchange element is essential. Indeed, in most cases, user authentication enforces some policy, and the key exchange step is essential for binding this enforcement to the authentication step. Skipping the key exchange part is analogous to carefully checking a visitor's credential at the door and then leaving the door open for others to enter freely.¶

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

6.6. User enumeration

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

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

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

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

6.7. 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 password to the server, even during registration. Note that a corrupted server can run an exhaustive offline dictionary attack to validate guesses for the user's password; this is inevitable in any aPAKE protocol. (OPAQUE enables a defense against such offline dictionary attacks by distributing the server so that an offline attack is only possible if all - or a minimal number of - servers are compromised [OPAQUE].)¶

Some applications may require learning the user'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.¶