🔐 ZK-Auth Pattern 2

Docs →

Research prototype for browser-side password hashing with a STARK-style consistency layer.
Argon2id runs client-side, the pepper stays server-side, and request-scoped proof/hash material must be discarded after each verification.

⚙ Argon2id parameters
Research prototype security model:
* Your password is processed in the browser and is not sent to the server.
* The server sees request-scoped Argon2id credential material while verifying; it must discard the proof and encoded hash immediately after the request.
* The database stores only C = Poseidon(mimc_output, serverPepper), the public salt, and Argon2id parameters.
* The STARK-style proof checks algebraic consistency of the MiMC/FRI wrapper over the client-side KDF output.
* This demo does not yet prove the full Argon2id memory-hard computation inside the STARK; that is the next research milestone.
← Back to demo · Architecture docs

🔍 Backend & Database Insight

1. What you just sent to the server (Client ➔ Server)
Your browser computed an Argon2id output from the password and generated a STARK-style consistency proof over the derived field witness. The password itself was not transmitted. The proof body and encoded hash are request-scoped credential material and must be discarded by the server after verification.
2. Server Verification Process
The server validates the consistency proof, then hashes mimc_output with its private pepper to compute C = Poseidon(mimc_output, serverPepper). The submitted proof, encoded Argon2id output, and intermediate witness must be discarded and never stored.
3. Live Database View (What is actually stored)
Below is a live fetch of your row in the SQLite database. Notice that neither your password nor the request-scoped Argon2id output is stored.
Loading...