Prove the Password Without Sending It
In a conventional password login, HTTPS protects the password while it travels, but the service receiving it can still read it. OPAQUE changes the exchange itself: the client sends randomized protocol messages instead. The password stays an input to the client’s computation, including during OPAQUE registration. The server keeps a registration record for future authentication. Cloudflare’s OPAQUE explainer introduces this distinction.
The unusual ingredient is an oblivious pseudorandom function (OPRF). Your device and the server jointly calculate a result: you supply a password, and the server supplies a secret key. “Oblivious” means the server can perform its part without learning your input or the final result. Your device does not learn the server’s key.
Registration, Then a Three-Message Login
OPAQUE combines the OPRF with credential recovery and an authenticated key exchange. During registration, the device uses the OPRF result and a deliberately expensive key-stretching step to prepare a record. That record includes an OPAQUE envelope, which later allows the correct password to recover authentication credentials. It is not a copy of the password. See the implementation’s registration and login documentation.
At sign-in, the device repeats the OPRF calculation with fresh blinding. The correct password recovers the credentials needed to finish the exchange; a wrong password does not. Fresh key-exchange material and authentication tags bind the conversation together. The server accepts the login only after checking the client’s final proof.
The protocol produces a shared session secret and a separate export key available only to the client. The export key can protect application secrets stored remotely. It is reproducible for the same registration and correct password; it is not the fresh session secret. The library’s export-key documentation describes this use.
How OWL Uses OPAQUE
One implementation across clients
OWL’s cryptographic adapter pins opaque-ke 4.0.1. It uses Ristretto255 for the OPRF and triple Diffie–Hellman exchange, SHA-512 within that suite, and Argon2id for key stretching. The Argon2id settings are 64 MiB of memory, three passes and one lane. These are fixed protocol settings shared by the native and browser implementations; the browser runs the adapter as WebAssembly.
The server verifies the completed OPAQUE exchange before creating the ordinary OWL application session. Account restrictions, sign-in throttling and required multi-factor authentication still apply. An OPAQUE proof does not bypass a second factor.
Unlocking the account’s private key
OWL also uses the client-only export key to protect the account’s P-256 private key. That account key is separate from OPAQUE’s authentication keys. In the OWPK v2 format, HKDF-SHA256 derives a dedicated wrapping key from the export key; AES-256-GCM then seals the private key. The envelope authenticates the immutable account ID so that a blob belonging to another account cannot simply be substituted.
This matters because a private key encrypted directly under a password-derived key gives a thief another place to test password guesses. OWPK v2 instead requires the OPAQUE-derived export key. A copied v2 blob alone does not provide that password-only test. OWL stores its OPAQUE server setup encrypted under a server-side wrapping key; protecting that key remains essential.
Replacing an OPAQUE registration changes its export key, so OWL pairs a new registration with the private-key envelope sealed under its new key. Losing a password is a separate recovery problem: OWL’s user-held recovery key can unlock a separate recovery envelope. An emailed account-reset code alone does not supply the secret needed to decrypt the old private key.
What It Protects—and Where the Boundary Ends
The original research establishes security against pre-computation: an attacker cannot prepare the relevant password mappings in advance of learning the server’s secrets. It does not abolish password guessing. A full compromise of the credential records and the necessary server secrets permits an offline dictionary attack, with work for each guess. A strong, unique password still matters. Jarecki, Krawczyk and Xu’s paper defines that threat model and its security proof.
| Situation | What to expect |
|---|---|
| Captured OPAQUE conversation | A passive recording does not become an offline password checker. The protocol also provides forward secrecy for its session keys. |
| Full server-secret compromise | Password guessing becomes possible. OWL’s Argon2id step increases the cost; a weak password remains weak. |
| Malicious login page or infected device | Code that reads your keystrokes or unlocked keys can steal them before OPAQUE helps. Trusted clients and HTTPS remain necessary. |
| Stored files | File confidentiality depends on file encryption, sharing and recovery. Client-side decryption (CSD) keeps payload keys on authorized endpoints; server-side decryption (SSD) deliberately gives the provider a different role. |
Forward secrecy for an authentication session does not automatically give forward secrecy to every stored file or to OWL’s long-lived account key. OPAQUE also does not hide account metadata or turn the Ristretto255/3DH suite into post-quantum cryptography. The RFC’s security considerations and OWL Encryption describe these separate layers.
The Original Paper and Public Audits
Protocol research and specification
- Original paper: Stanislaw Jarecki, Hugo Krawczyk and Jiayu Xu, OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Computation Attacks, EUROCRYPT 2018; the ePrint page hosts the revised paper. Read the PDF. It supplies the formal construction and proof, rather than an audit of a particular product.
- Current protocol specification: RFC 9807, by Daniel Bourdrez, Hugo Krawczyk, Kevin Lewi and Christopher A. Wood. Use this for the published message formats and OPAQUE-3DH construction; the 2018 paper and earlier drafts are not interchangeable wire specifications.
1. NCC Group: opaque-ke, 2021
NCC Group’s review, commissioned by WhatsApp, examined the Rust library and the then-current protocol draft in June 2021. The full report, version 1.3, is dated December 10, 2021. The library’s audit history states that issues were found in v0.5.0 and fixes were incorporated into v1.2.0. OWL pins v4.0.1: this is relevant audit history for the library, not a claim that the exact version OWL uses received that 2021 audit.
2. 7ASecurity: Serenity’s OPAQUE packages, 2023
The 7ASecurity report covers @serenity-kit/opaque, related packages and React Native bindings, with work performed in October–November 2023. Its scope included code review, fuzzing, supply-chain review, threat modeling and privacy analysis. It reported no directly exploitable vulnerabilities and five hardening recommendations in the code-testing work packages, primarily involving examples and dependencies. These are separate wrappers and integrations around OPAQUE; OWL uses its own adapter.
Read the scope, not just the word “audited”
A mathematical proof addresses a protocol under stated assumptions. An implementation audit examines specified code at a particular time. Neither report above audits NDEVR OWL’s complete authentication, recovery or file-encryption system, and neither is a certification of OWL.
For implementation detail, read the opaque-ke 4.0.1 documentation. For the surrounding product boundary, see OWL Security and Hashing & Key Derivation. All three diagrams on this page are original NDEVR illustrations; they simplify the cited protocol and OWL’s implementation rather than reproduce audit figures.