OPAQUE Protocol Implementation
PAKE protocol with post-quantum protection. Server never receives or stores the password.
What is OPAQUE?
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.
Zero-Knowledge OPRF
Password processed via Oblivious PRF — server evaluates blinded input without ever seeing the plaintext password
No Password Storage
Server stores no password-equivalent data. Database breaches yield nothing usable for offline attacks
Offline Attack Resistance
Dictionary and brute-force attacks impossible without server cooperation. OPRF requires server's private key
Mutual Authentication
Both client and server prove identity cryptographically. Prevents phishing and man-in-the-middle attacks
Post-Quantum Protection
Hybrid ML-KEM-768 + Ristretto255 4DH key exchange. Resistant to harvest-now-decrypt-later quantum attacks
Security Properties
OPAQUE provides comprehensive password security at every layer of the authentication protocol
Zero-Knowledge
Server never learns the password. Not during registration, not during login, not ever. Mathematically proven via OPRF.
Post-Quantum Protection
Hybrid ML-KEM-768 + Ristretto255 4DH key exchange. Resistant to both classical and quantum attacks. NIST-standardized.
Offline Attack Resistant
Database breaches yield no usable data. Attacker cannot mount dictionary or brute-force attacks offline.
Mutual Authentication
Both client and server prove their identity. Prevents phishing and man-in-the-middle attacks.
Forward Secrecy
Each session generates unique keys via ephemeral DH. Compromise of long-term keys cannot decrypt past sessions.
Secure Key Derivation
Argon2id with configurable parameters for password stretching. HKDF-SHA512 for cryptographic key derivation.
Key Types & Sizes
Complete cryptographic material inventory for the OPAQUE protocol
Classical Cryptography
Elliptic curve keys for identity and key exchange operations
Classical Keys
Post-Quantum Cryptography
Lattice-based keys providing quantum resistance
Post-Quantum Keys
Cryptographic Material
Seeds, nonces, MACs, and derived session values
Cryptographic Material
Key Derivation
Password stretching and cryptographic key derivation
Argon2id Configuration
Runtime State Objects
Memory-resident state during protocol execution
Initiator (Client) State
Client-side cryptographic material maintained during authentication handshake
- blind 32 bytes
- initiator_secret_key 32 bytes
- initiator_public_key 32 bytes
- ephemeral_secret_key 32 bytes
- pq_secret_key 2,400 bytes
- pq_public_key 1,184 bytes
Responder (Server) State
Server-side cryptographic material maintained during credential verification
- expected_initiator_mac 64 bytes
- session_key 64 bytes
- ke1_serialized 1,272 bytes
- ke2_serialized 1,376 bytes
Client Envelope
Encrypted client credentials stored on server
Nonce Construction
XSalsa20-Poly1305 24-byte extended nonce format
Protocol Sequence
Registration Phase
Authentication Phase
OPRF Process
How passwords are processed without server knowledge
OPRF Flow
Key Exchange Derivation
Protocol Flow
Complete OPAQUE authentication sequence from registration to session establishment
Domain Separation Labels
AAD labels ensuring cryptographic domain separation
Classical Domain
Post-Quantum Domain
Technology Stack
Security Guarantees
Formal security properties mathematically proven by the OPAQUE protocol
Zero-Knowledge Password
Server never learns the password at any point. Mathematically proven via Oblivious PRF construction.
Offline Attack Resistance
Database breaches yield no password-equivalent data. Dictionary attacks require online server interaction.
Forward Secrecy
Each session generates unique ephemeral keys. Compromise of long-term keys cannot decrypt past sessions.
Mutual Authentication
Both parties prove identity cryptographically. Prevents phishing, MITM, and server impersonation attacks.
Security Comparison
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 | ✓ | ✗ | ~ |
Formal Verification
All security properties mathematically proven by two independent tools under a Dolev-Yao adversary with quantum oracle
Tamarin Prover 1.10.0
8 / 8 lemmas verified
ProVerif 2.05
8 / 8 queries verified (5 main model + 3 auth model)
Session Key Secrecy
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)Password Secrecy
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)Classical Forward Secrecy
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)PQ Forward Secrecy
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)Mutual Auth (Initiator)
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,τ)Mutual Auth (Responder)
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,τ)AND-Model Hybrid
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)Offline Dictionary Resistance
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)Threat Model
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.
Use Cases
Enterprise applications requiring zero-knowledge password authentication
Zero-Knowledge Authentication, Architected for Tomorrow
Password protection with post-quantum resilience — eliminate vulnerabilities at the protocol level
Discuss Implementation