Consider the standard age verification problem. A bar asks you for ID. You hand over a driver's license. They now know your name, address, license number, exact date of birth, and physical description — none of which are relevant to the question "are you over 21?" The relevant fact is one bit: yes or no. Everything else is excess disclosure.
Zero-knowledge proofs (ZKPs) are a class of cryptographic protocols that let you prove a statement is true without revealing why it's true. In the age verification case: prove that the current date minus your birth date exceeds 21 years, without revealing the birth date. The verifier learns the single bit they needed. Nothing more.
The Mathematics Behind the Idea
The formal definition of a zero-knowledge proof has three properties:
- Completeness: if the statement is true, an honest prover can always convince an honest verifier.
- Soundness: a dishonest prover cannot convince an honest verifier of a false statement (except with negligible probability).
- Zero-knowledge: the verifier learns nothing beyond the truth of the statement — not the witness (the secret used to prove it), not any intermediate information.
The classic pedagogical example is the Ali Baba cave: a circular cave with a door in the middle that only opens with a secret password. Alice wants to prove to Bob that she knows the password without revealing what it is. She enters the cave and goes to the left or right fork. Bob calls out which fork she should emerge from. If she knows the password, she can always appear at the correct fork — because she can open the door and cross if needed. If she doesn't know the password, she can only succeed 50% of the time. Repeating this many times makes the probability of a non-knower succeeding negligibly small.
This is an interactive proof — it requires back-and-forth between prover and verifier. Modern ZKP systems are non-interactive, meaning the prover generates a single proof object that any verifier can check independently.
zk-SNARKs and zk-STARKs: The Practical Constructions
The two main families of practical ZKP systems you'll encounter are zk-SNARKs and zk-STARKs. The acronyms are dense but the distinction matters:
zk-SNARK (Succinct Non-interactive ARgument of Knowledge): compact proofs, fast verification, but requires a "trusted setup" — a ceremony where secret parameters are generated and then discarded. If the ceremony is compromised, fake proofs can be constructed.
zk-STARK (Scalable Transparent ARgument of Knowledge): no trusted setup, quantum-resistant, but larger proof sizes and slower verification. "Transparent" means all randomness is public.
zk-SNARKs are widely deployed in blockchain contexts (Zcash uses them for shielded transactions) because their compact proof size is valuable when proofs are stored on-chain. zk-STARKs are gaining adoption where the trusted setup requirement is a dealbreaker — government contexts, high-security applications, and scenarios where the ceremony participants can't be fully trusted.
Anonymous Credentials: ZKPs for Identity
Anonymous credentials are a specific application of ZKP techniques to identity and authorization. The canonical construction is due to Jan Camenisch and Anna Lysyanskaya (known as CL credentials or CL signatures), with modern implementations including the W3C Verifiable Credentials specification and the BBS+ signature scheme.
The flow works like this:
- An issuer (a government, employer, or trusted authority) signs a credential containing your attributes — name, age, membership status, authorization level.
- You store the signed credential in your wallet.
- When a verifier asks you to prove a property, you generate a zero-knowledge proof that: (a) you possess a credential signed by the issuer, and (b) that credential satisfies the required predicate (e.g., "age > 21", "membership_status = active").
- The verifier learns only that the predicate holds and that the credential was signed by a legitimate issuer. They don't learn your name, your exact age, or any other attribute in the credential.
| Approach | What Verifier Learns | Linkability Across Sessions |
|---|---|---|
| Standard login (username/password) | Full identity, usage history | Fully linked by account ID |
| OAuth/SSO ("Login with Google") | Identity token, profile data granted | Linked across all services using same SSO |
| Anonymous credentials (BBS+, CL) | Only the proven predicate (e.g., age ≥ 21) | Unlinkable across sessions by design |
| Pseudonymous token (JWT with opaque ID) | A consistent pseudonym, not real identity | Linked within service, but not to real identity |
Where This Is Being Deployed Today
ZKP-based authentication has moved from academic papers to production systems over the past five years. Notable deployments:
Zcash shielded transactions use zk-SNARKs to allow transaction validation without revealing sender, receiver, or amount. The blockchain can verify that no coins were created from nothing (validity) without learning who sent what to whom (privacy).
Cloudflare's Privacy Pass protocol uses anonymous credential techniques to let users prove they passed a CAPTCHA without re-solving one, and without Cloudflare being able to link individual token uses back to the user who earned them. This is now standardized in IETF RFC 9578.
Apple's Private Access Tokens, introduced in iOS 16, are a similar construction: Apple signs a token attesting that a device request is legitimate, and websites accept the token to skip CAPTCHA without Apple learning which site you visited or the site learning which Apple device you used.
W3C Verifiable Credentials with selective disclosure are being piloted for government identity applications in the EU (the EUDI Wallet), several US states, and in corporate environments for employee authorization.
The Limits and the Honest Assessment
ZKPs aren't magic. Several limitations are worth understanding:
Zero-knowledge proofs prove mathematical statements. They don't prove the underlying real-world facts are true. A ZKP that proves "the credential says this person is 21" doesn't prove the credential was issued correctly to the right person — it only proves the credential exists and was signed by the claimed issuer. The root of trust is still in the issuer.
Selective disclosure is powerful but only covers what's in the credential. If the issuer embedded a unique serial number to enable correlation, ZKPs can't hide that linkage.
Performance remains a challenge for some ZKP constructions. zk-SNARK proof generation is computationally expensive — generating a proof can take seconds to minutes for complex statements on consumer hardware, though dedicated circuits and hardware acceleration are improving this significantly.
Why This Matters for Secure Messaging
Anonymous credentials have specific relevance to messaging systems in a few ways. Authentication without identity — proving you have a valid account without revealing which account — can protect privacy against the service provider itself. Abuse-resistance systems that work without enabling per-user tracking are possible with ZKP constructions. Subscription proofs that verify "this user has an active subscription" without logging which user requested what content preserve billing relationships without creating a surveillance record.
Haven's current authentication uses client-side PBKDF2 key derivation — your passphrase never leaves your device — which is a different privacy property than ZKPs but addresses a similar concern: the server shouldn't hold your credentials in a form it can use independently of you. Anonymous credential systems represent a further step in that direction, and are on the research roadmap for privacy-preserving authentication in messaging systems broadly.
The gap between "research paper" and "deployed in production" for ZKP applications has narrowed substantially since 2020. If you're evaluating privacy-preserving systems, it's worth asking whether they use anonymous credentials for authorization — and if not, whether the tradeoffs are intentional or an oversight.