Zero-Knowledge Proof Authentication on Tor Hidden Services

A zero-knowledge proof has three properties: completeness (an honest prover with valid credentials can always convince a verifier), soundness (a dishonest prover without valid credentials cannot convince a verifier except with negligible probability), and zero-knowledge (the verifier learns nothing beyond whether the prover has valid credentials). For .onion authentication, this means: the user proves they know a secret (password, private key, or membership token) without transmitting that secret. The server verifies the proof without storing the original secret. If the server is later compromised, the attacker cannot extract the user's secret because it was never transmitted. Common ZKP schemes applicable to authentication: Schnorr identification protocol, zk-SNARKs (Zero-Knowledge Succinct Non-interactive ARguments of Knowledge), Bulletproofs, and anonymous credential systems like U-Prove and Idemix.

The Schnorr identification protocol is a simple, efficient ZKP for proving knowledge of a discrete logarithm. Applied to authentication: the user's secret is their private key (or password-derived key). The server stores the corresponding public key. During authentication, the user proves knowledge of the private key without transmitting it. Implementation: the server sends a random challenge, the user computes a response using their private key and the challenge, and the server verifies the response using only the public key. No secret leaves the client. Libraries: libsodium's crypto_auth_hmacsha512 provides building blocks; implementing full Schnorr authentication requires a few hundred lines of code in any language with big-integer arithmetic. Limitation: Schnorr proves you know a specific private key - it does not provide anonymity between multiple authentications unless combined with a blinding mechanism.

Anonymous credential systems allow users to prove membership in a group (authorized users) without the server identifying which specific member is authenticating. This is stronger than standard ZKP authentication because it prevents the server from tracking which user logs in when, even if the user authenticates multiple times. Idemix (IBM Identity Mixer) and U-Prove (Microsoft Research) are two established anonymous credential systems. Idemix: credentials are issued by an authority, and users prove possession of a valid credential without revealing their identity. Each proof session produces an unlinkable signature. U-Prove: similar approach with different cryptographic foundations. Both are standardized and have open-source implementations. For .onion services, an anonymous credential system means: an administrator issues credentials (tokens) to authorized users via a separate secure channel, users authenticate to the service using their credential proof, and the service cannot link authentication sessions to individual users.

zk-SNARKs provide very compact proofs (a few hundred bytes) that can verify arbitrary computations. For authentication: the user proves knowledge of a preimage of a hash (password hash), membership in a Merkle tree of authorized users, or possession of a valid token without revealing any of these values. Libraries: Circom + SnarkJS (JavaScript) for browser-based ZKP generation, gnark (Go) for server-side verification, and Bellman (Rust) for high-performance proof generation. Practical implementation: store a Merkle tree root of all authorized user public keys server-side, users generate a zk-SNARK proving their key is in the tree and they know the corresponding private key, send only the proof (not the key), server verifies proof against the stored root. Authentication time: 100-500ms for proof generation client-side; 10-50ms for server-side verification. Proof size: 200-400 bytes. This is practical for web authentication even over Tor's latency.

Integrate ZKP authentication into a .onion web application using a middleware approach. For a Node.js/Express .onion application using SnarkJS: install snarkjs and circom compiler, define the authentication circuit (proves knowledge of private key with valid Merkle membership), compile the circuit to generate verification key, add a /zkp-challenge endpoint (returns random nonce), add a /zkp-verify endpoint (accepts the zk-SNARK proof and nonce, verifies using the verification key, issues a session token if valid). Client-side JavaScript generates the proof using the user's private key and the received nonce. The session token subsequent requests use is a standard JWT - ZKP is only required at login. For Python/.onion applications: py_ecc provides the elliptic curve primitives needed for Schnorr authentication; Bellman has Python bindings for zk-SNARK verification.