Zero-Knowledge Proofs in Authentication
How Hawcx uses ZKPs for secure authentication without revealing secrets
With passwords, your server stores the secret (or a hash of it). With passkeys, your server stores a public key tied to a long-lived private key. In both cases, your server has something valuable that an attacker wants.
With Hawcx, your server receives a proof: mathematical evidence that the user has the secret, without the secret itself ever being transmitted or stored. This is a zero-knowledge proof.
Why this matters
For developers: Your backend never handles, stores, or transmits user secrets. You receive verified claims (user ID, email), and that's it. No credential table to encrypt, no hashing algorithm to choose, no salt rotation to manage.
For security teams: A complete database dump of your Hawcx-authenticated system reveals zero usable credentials. There is no "credential table" to exfiltrate. Incident response for auth breaches becomes a non-event because there's nothing to compromise.
The cryptographic foundation
Hawcx's proof system is built on the Classical Sigma (Σ) Protocol, the same cryptographic foundation that underlies FIDO2/WebAuthn. Specifically, both systems use Schnorr-family signatures (EdDSA/Ed25519) for proof of private-key possession. This is not a novel or unproven construction. It's the canonical example of a zero-knowledge proof in the academic literature, formalized by Goldwasser, Micali, and Rackoff.
The Σ-protocol provides three guarantees:
- Completeness: An honest user with the correct key always produces a valid proof
- Special soundness: A valid proof can only be produced by someone who possesses the private key
- Honest-verifier zero-knowledge: The verifier learns nothing beyond the fact that the proof is valid, since a simulator can produce transcripts indistinguishable from real ones
Where Hawcx goes beyond FIDO2: Both systems share the same Σ-protocol core. The difference is what's built around it. Hawcx adds a hash commitment tier and a symmetric AEAD mutual-authentication tier before the signature step, creating three independent verification barriers where FIDO2 has one. See How It Works for the full three-tiered chain.
How it works in practice
- User initiates login on their device
- Hawcx sends a unique challenge
- The device generates a fresh proof using its secure hardware. This proof demonstrates possession of the secret without revealing it
- The proof passes through three sequential verification tiers (hash → symmetric → asymmetric)
- Hawcx confirms all tiers pass and issues an auth code
- Your backend exchanges the auth code for verified claims
At no point does the secret leave the device. At no point does your server or Hawcx see the secret. The proof is valid for this single challenge only. Intercepting it is useless because it cannot be replayed.
What this changes
| Traditional auth | Hawcx with ZKPs |
|---|---|
| Server stores password hash → breach exposes hashes | Server stores nothing → breach exposes nothing |
| Secret transmitted during login → interceptable | Only proof transmitted → useless if intercepted |
| Credential reuse across sites → one breach cascades | No credential exists to reuse |
| You choose hashing algorithm (bcrypt, argon2) | No hashing needed because there is no secret to hash |
| You manage salt, pepper, rounds, migration | None of this exists |
The practical impact
Think about what you don't have to build:
- No password hashing pipeline
- No credential storage encryption
- No breach notification for "credentials may have been exposed"
- No forced password resets after incidents
- No credential stuffing protection (there are no credentials to stuff)
The attack surface for authentication-related breaches drops to zero, not because of better defenses, but because the thing attackers want doesn't exist on your system.