PAKE protocol with post-quantum protection. Server never receives or stores the password.
OPAQUE (Oblivious Pseudo-Random Function with Asymmetric Password-Authenticated Key Exchange) is the cryptographically most secure method of password authentication. Unlike traditional password hashing, the server never sees, stores, or processes the actual password — not even during registration.
Password processed via Oblivious PRF — server evaluates blinded input without ever seeing the plaintext password
Server stores no password-equivalent data. Database breaches yield nothing usable for offline attacks
Dictionary and brute-force attacks impossible without server cooperation. OPRF requires server's private key
Both client and server prove identity cryptographically. Prevents phishing and man-in-the-middle attacks
Hybrid ML-KEM-768 + Ristretto255 4DH key exchange. Resistant to harvest-now-decrypt-later quantum attacks
OPAQUE provides comprehensive password security at every layer of the authentication protocol
Server never learns the password. Not during registration, not during login, not ever. Mathematically proven via OPRF.
Hybrid ML-KEM-768 + Ristretto255 4DH key exchange. Resistant to both classical and quantum attacks. NIST-standardized.
Database breaches yield no usable data. Attacker cannot mount dictionary or brute-force attacks offline.
Both client and server prove their identity. Prevents phishing and man-in-the-middle attacks.
Each session generates unique keys via ephemeral DH. Compromise of long-term keys cannot decrypt past sessions.
Argon2id with configurable parameters for password stretching. HKDF-SHA512 for cryptographic key derivation.
Complete cryptographic material inventory for the OPAQUE protocol
Elliptic curve keys for identity and key exchange operations
Lattice-based keys providing quantum resistance
Seeds, nonces, MACs, and derived session values
Password stretching and cryptographic key derivation
Memory-resident state during protocol execution
Client-side cryptographic material maintained during authentication handshake
Server-side cryptographic material maintained during credential verification
Encrypted client credentials stored on server
XSalsa20-Poly1305 24-byte extended nonce format
How passwords are processed without server knowledge
Complete OPAQUE authentication sequence from registration to session establishment
AAD labels ensuring cryptographic domain separation
Formal security properties mathematically proven by the OPAQUE protocol
Server never learns the password at any point. Mathematically proven via Oblivious PRF construction.
Database breaches yield no password-equivalent data. Dictionary attacks require online server interaction.
Each session generates unique ephemeral keys. Compromise of long-term keys cannot decrypt past sessions.
Both parties prove identity cryptographically. Prevents phishing, MITM, and server impersonation attacks.
How OPAQUE compares to traditional authentication methods
| Security Property | OPAQUE | Password Hash | OAuth 2.0 |
|---|---|---|---|
| Password never leaves client | ✓ | ✗ | ~ |
| Offline attack resistant | ✓ | ✗ | ~ |
| Mutual authentication | ✓ | ✗ | ✗ |
| Post-quantum secure | ✓ | ✗ | ✗ |
| Forward secrecy | ✓ | ✗ | ~ |
All security properties mathematically proven by two independent tools under a Dolev-Yao adversary with quantum oracle
8 / 8 lemmas verified
8 / 8 queries verified (5 main model + 3 auth model)
The derived session key remains computationally indistinguishable from random for any PPT adversary, provided neither party's long-term key has been compromised at the time of the handshake.
SKC(C,S,sk) ∧ ¬CLtk(C) ∧ ¬CLtk(S) ⟹ ¬K(sk)The user's password is never transmitted, stored, or derivable by the server or any network adversary. The OPRF construction ensures that only the blinded output enters the key schedule.
PwdGen(C,p) ⟹ ¬K(p)Compromise of long-term Ristretto255 keys after session completion does not allow decryption of past sessions. Fresh ephemeral DH shares are zeroized on completion.
SKC(C,S,sk)@i ∧ CLtk(C)@j ∧ CLtk(S)@k ∧ i'<'j ∧ i'<'k ⟹ ¬K(sk)Even if a quantum adversary breaks ECDLP, past sessions remain protected by ML-KEM-768 encapsulation, as long as ephemeral keys are not directly revealed.
UsedQuantum() ∧ ¬RevEph(C) ∧ ¬RevEph(S) ⟹ ¬K(sk)The initiator is authenticated to the responder via HMAC-SHA-512 MAC over the full transcript. The server verifies the KE3 MAC before accepting.
CommI(C,S,sk,τ) ⟹ ∃ CommR(S,C,sk,τ)The responder is authenticated to the initiator via the KE2 MAC. The client verifies this MAC before sending KE3, preventing server impersonation.
CommR(S,C,sk,τ) ⟹ ∃ CommI(C,S,sk,τ)The hybrid combiner follows the AND-model: an attacker must break BOTH Ristretto255 4DH AND ML-KEM-768 simultaneously. Breaking only one is provably insufficient.
¬RevEph(C) ∧ ¬RevEph(S) ⟹ ¬K(sk)Even with full access to the server's credential database, offline dictionary attacks are infeasible. The OPRF key derived from the server's secret seed is required.
PwdGen(C,p) ∧ CDB(S,C) ⟹ ¬K(p)Dolev-Yao adversary with full network control, adaptive long-term key corruption, and quantum oracle breaking classical Diffie-Hellman. Security follows the AND-model: an attacker must compromise BOTH Ristretto255 4DH AND ML-KEM-768 simultaneously to break session key secrecy.
Comprehensive defense against 12 critical attack vectors with dedicated test suites for each
| Attack Vector | Protection Mechanism | Tests |
|---|---|---|
| Offline Dictionary Attack | Argon2id (19 MiB, 2 iterations) + OPRF blinding | 47 |
| OPRF Seed Compromise | Server-side rate limiting + credential isolation | 12 |
| Server Impersonation | 4DH mutual authentication + server public key pinning | 23 |
| Client Impersonation | OPRF prevents offline verification without server | 18 |
| Replay Attack | Unique nonces per session + transcript binding | 15 |
| Transcript Tampering | HMAC-based transcript hashing over all messages | 21 |
| Forward Secrecy (Classical) | Ephemeral X25519 keys + 4DH key schedule | 14 |
| Forward Secrecy (Post-Quantum) | Ephemeral ML-KEM-768 encapsulation per session | 14 |
| Quantum Key Recovery | Hybrid X25519 + ML-KEM-768 with dual combiner | 8 |
| aPAKE Model Violation | Formal verification against Ristretto255 group laws | 31 |
| Password Leakage via Timing | Constant-time comparison + fake credential generation | 9 |
| Version Downgrade | Protocol version bound in AAD + strict negotiation | 6 |
Randomized testing with proptest for invariant verification
Compact binary format with hybrid post-quantum cryptography overhead
| Message | Total Size | Payload | Description |
|---|---|---|---|
| RegistrationRequest | 32 bytes | Blinded OPRF element | Client-blinded password hash sent to server |
| RegistrationResponse | 64 bytes | Evaluated element + server PK | Server OPRF evaluation and public key |
| RegistrationRecord | 192 bytes | Envelope + client PK | Encrypted credentials stored server-side |
| KE1 (Login Start) | 1,252 bytes | Credential request + X25519 + ML-KEM-768 | Client ephemeral keys and blinded OPRF |
| KE2 (Login Response) | 2,468 bytes | Credential response + ciphertext + MAC | Server response with PQ ciphertext |
| KE3 (Login Finish) | 64 bytes | Client MAC | Client confirmation of shared key |
Defense capabilities against common and advanced threat actors
| Threat | Status | Description |
|---|---|---|
| Passive Eavesdropper | Protected | All messages encrypted; OPRF hides password from network |
| Active Man-in-the-Middle | Protected | 4DH mutual authentication prevents impersonation |
| Server Database Compromise | Protected | Argon2id + OPRF; no plaintext or reversible hashes stored |
| Server Impersonation | Protected | Client verifies server identity via public key in envelope |
| Offline Dictionary Attack | Protected | OPRF blinding requires server cooperation for each guess |
| Online Brute Force | Detected | Server-side rate limiting; Argon2id slows each attempt |
| Client Device Compromise | Partial | Forward secrecy limits exposure; no long-term secrets on client |
| Replay Attack | Protected | Unique nonces and transcript binding prevent replay |
| Pre-computation / Rainbow Tables | Protected | Per-user OPRF salt makes pre-computation infeasible |
| Key Compromise Impersonation | Protected | Mutual 4DH prevents impersonation even with one key leaked |
Comprehensive security audit completed March 2026 covering all protocol components
Criterion.rs benchmark suites for continuous performance regression testing
Continuous fuzzing with cargo-fuzz targeting all protocol entry points
Enterprise applications requiring zero-knowledge password authentication
Password protection with post-quantum resilience — eliminate vulnerabilities at the protocol level
Discuss Implementation