Every cloud service promises it can't read your data. Very few can show you why that's true instead of asking you to take their word for it. The difference between the two is the difference between a policy (which can change, be subpoenaed, or be quietly violated) and an architecture, which limits what there is to hand over in the first place.
This guide explains zero-knowledge encryption in plain English, using the sign-in system we run in production. The OPAQUE libraries behind it are open source, so the protocol claims in this post link to real code or a real protocol spec. No math degree required — but receipts throughout.
Updated 18 October 2026: we corrected what a stolen database or a court order could reach, when password guesses can be tested offline, how sign-in handles your email address, and which parts of the code are public.
Update, 19-07-2026 — this guide was rewritten. The previous version misdescribed our own authentication as layered password hashing. The real system is OPAQUE, a password-authenticated key exchange: the password, and anything that could test a guess without the server's own OPRF key, never reach our servers. The corrected walkthrough is below.
Update, 13-09-2026 — account recovery is live, and has been since 3 September 2026. Earlier versions of this post said it was switched off; it was, from 11 August to 3 September, while the browser half of the ceremony was finished. Recovery runs on the 24-word phrase shown at the end of signup, which enrols a second identity we cannot read. Signup has enrolled it automatically since 7 September 2026; accounts created before that set it up from Security settings, which needs the password. Every claim below has been corrected to say that.
What "Zero-Knowledge" Actually Means (and What It Doesn't)
Think of a safety deposit box. A traditional cloud service is a bank vault: you hand over your valuables, the bank locks them up, and the bank keeps a copy of the key. They promise security — but they can open your box any time, and so can anyone who compels or compromises them. Zero-knowledge encryption is different: you bring your own padlock, you keep the only key, and the bank stores a sealed box it cannot open.
Formally: all encryption and decryption happens on your device, your keys never leave your device, and the server receives, stores, and serves only ciphertext. The provider's knowledge of your data is zero — not by promise, by construction.
Two distinctions worth making before we go further:
Zero-knowledge encryption is not zero-knowledge proofs. ZKPs are a mathematical protocol for proving you know something without revealing it (NIST); ZKE describes a service architecture. The naming overlap is mostly coincidence — though as you'll see below, modern login protocols like OPAQUE genuinely borrow from the proof-without-revealing idea.
Zero-knowledge encryption is stronger than end-to-end encryption. All ZKE is E2EE, but some E2EE systems still derive or escrow keys server-side, leaving the provider a theoretical path to plaintext. ZKE closes that path entirely.
Why Server-Side Encryption Keeps Failing
Most breached companies had encryption. The Dropbox Sign breach of April 2024 is the instructive example — and it's usually told wrong. The attacker didn't crack any cipher or steal decryption keys. They compromised an automated service account and walked in through the front door with legitimate backend access, reaching customer emails, hashed passwords, API keys, OAuth tokens, and MFA data. The encryption at rest was real. It just didn't matter, because encryption the server can undo is undone the moment someone becomes the server.
That's the general pattern: server-side encryption protects against stolen disks. It does not protect against the vendor itself, compromised employee or service accounts, government compulsion, or bugs in the key-management layer. Credential theft was the top attack vector in cloud breaches again in 2025 (Thales, 2026) — and stolen credentials grant exactly the access that server-held keys were supposed to gate.
Zero-knowledge architecture changes what a breach is. If the server never holds plaintext or keys, then full server compromise yields ciphertext and metadata, and no plaintext. You can't leak what you never had.
A Worked Example: Logging In Without Ever Sending a Password
Here's where most explanations go abstract. We'll do the opposite and walk through our production system. Ciphera ID uses OPAQUE, an asymmetric password-authenticated key exchange specified in RFC 9807 (an IRTF Informational RFC), via Tessera, our open-source wrapper around opaque-ke, Meta's OPAQUE library. The property that makes OPAQUE remarkable: the server verifies your password without ever seeing your password or any hash of it. Without the server's own OPRF key, what it stores cannot be used to test password guesses.
When you sign up:
- Your browser computes two independent things. From your email, it derives a blind index (PBKDF2-SHA256 at 1,000,000 iterations), which becomes the sign-in server's only way to look up your account. The sign-in server never sees your email address. Your browser also seals a copy for our mail service, which decrypts it to send mail.
- From your password, the browser runs the OPAQUE registration exchange: an oblivious pseudorandom function (OPRF) over Ristretto255, with Argon2id as the key-stretching function. The ciphersuite is RFC 9807's recommended configuration; the Argon2id cost parameters (64 MiB memory, 3 passes) are our own pinned deployment choice in Tessera's client. What travels to the server is a blinded registration message: it contains neither the password nor a hash of it. Without the server's own OPRF key, nothing the server receives in registration lets an attacker test password guesses offline.
- The exchange yields two outputs. The server gets a credential record to store — an opaque envelope it cannot invert. Your browser gets a 64-byte
export_keythat the server never sees and cannot compute without your password. - Your browser then generates a random 32-byte vault master key (VMK), encrypts your profile data (name, email, settings) under it, and wraps the VMK itself under a key derived from
export_key. The wrapped key is a 61-byte envelope; the VMK inside it never exists on our servers in unwrapped form.
When you log in:
- Your browser recomputes the blind index from your email and starts an OPAQUE login exchange.
- The server looks up your credential record and responds. It learns nothing about the password you typed — for accounts that don't exist, it even responds with a timing-safe decoy record, so an attacker can't probe which emails are registered.
- If — and only if — you typed the right password, your browser independently re-derives the same
export_keyfrom the exchange. Wrong password, wrong key, and the login simply fails. Without the server's OPRF key, nothing transmitted at any step lets an attacker test password guesses offline. - Your browser uses the
export_keyto unwrap your VMK — imported as a non-extractable WebCrypto key, meaning even our own frontend code can't export its bytes, only use it — and decrypts your vault locally.
Notice what never happened: your password never left your device, and your vault key never reached the sign-in server in unwrapped form.
What a Full Database Breach Would Yield
The honest way to evaluate any zero-knowledge claim is to enumerate what the server actually stores and ask what each item is worth to an attacker. For a Ciphera account, the fields that hold your credentials and vault are, per user:
| Stored field | What it is | What an attacker gets |
|---|---|---|
opaque_record | The OPAQUE credential envelope | Nothing to test password guesses against on its own. With the server's OPRF key as well, guesses can be tested offline, each paying the full Argon2id cost (64 MiB, 3 passes) |
opaque_credential_id | 16 random bytes | Nothing — it's random |
email_blind_index | The PBKDF2 email digest, HMAC-peppered again server-side | No email address; peppering means even a rainbow table of common emails doesn't apply outside our infrastructure |
encrypted_vault | Your profile data, AES-256-GCM under the VMK | Ciphertext |
opaque_wrapped_key | The VMK, wrapped under a key derived from your export_key | A locked box whose key only your password or recovery phrase can re-derive |
There is no password column and no password-hash column in the classical crackable sense. The last legacy authentication columns (from the SRP protocol we previously ran) were dropped on 18 June 2026 when the OPAQUE migration completed. The sign-in server never sees your email address. These five fields cover credentials and the vault. A breach or a court order could reach those and more: account ids, timestamps, the sign-in record, hashed IP addresses, notification metadata, backups, two-factor secrets and the email address (your browser seals a copy for our mail service, which decrypts it to send mail). None of it contains your password or your vault's readable contents. For the full accounting of what Ciphera can and cannot see, read our trust page.
The Limits: What ZKE Cannot Protect Against
No encryption system protects against everything, and vendors who skip this section are selling, not explaining.
Endpoint compromise. If malware runs on your device, it sees what you see — before encryption happens. ZKE protects data in transit and at rest, not a compromised screen and keyboard.
Weak passwords. OPAQUE's Argon2id stretching makes each guess expensive. A stolen database on its own gives an attacker nothing to test guesses against, so guesses can only be made online against our rate-limited servers. An attacker who also holds the server's OPRF key can test guesses offline, at Argon2id cost per guess. Needing that second secret is still a major upgrade over crackable stolen hashes. But "correct horse battery staple" still beats "hunter2".
Metadata. Zero-knowledge applies to content. A server still observes that an account exists, when it authenticates, and how large its ciphertext is. We minimize this (blind indexes exist precisely to take email addresses out of that picture), but minimized is not zero.
User error. Losing your password means losing your data unless you enrolled the second key — there is no backdoor for us to helpfully use. The 24-word phrase is that second key: with it enrolled, the sentence is "losing both"; with no phrase enrolled, a lost password cannot be recovered by anyone, including us. That trade-off is the entire point, and you should walk into it with open eyes.
Verify, Don't Trust: The OPAQUE Code Is Public
The OPAQUE libraries described above are inspectable. The sign-in service that uses them, including its PBKDF2 email index, is not public. Tessera (the OPAQUE core, the sidecar service, and the SDKs) is open source under Apache-2.0:
ciphera-tessera— the Rust core and sidecar, built on the widely usedopaque-keimplementation,#![forbid(unsafe_code)], with the cipher suite pinned to RFC 9807's recommended configuration (Ristretto255-SHA512, 3DH, Argon2id).@ciphera-net/tessera— the browser SDK: OPAQUE flows, blind index, vault, BIP-39 recovery, WebAuthn-PRF.tessera-go— the server-side SDK our backend uses to relay OPAQUE messages to the sidecar.
One disclosure we make prominently, because a receipts-driven post cuts both ways: Tessera has not yet had an independent third-party audit. We've published our threat model, security docs, and a detailed self-audit in the repositories, and an external audit is planned — but until it happens, "audited" is a claim you won't find us making. What you can do today is read the code, which is more than most zero-knowledge claims allow.
How to Spot Fake Zero-Knowledge
Four questions expose most pretenders in five minutes:
- Can they reset your password without you? If yes, a key exists outside your control. (We can't — a password change requires your device re-running OPAQUE registration.)
- Does account recovery work without a recovery secret you generated? If yes, that's a backdoor with a friendlier name. (Ours requires the 24-word phrase your device minted at signup — a second identity enrolled with your own password, so nothing on our side can drive it. Accounts from before 7 September 2026 enrol it from Security settings.)
- Can support access your data "for troubleshooting"? Then it isn't zero-knowledge, whatever the marketing page says.
- Are the clients closed-source? Client-side encryption you can't inspect is client-side encryption you're taking on faith. (Ours: the OPAQUE libraries, browser SDK included, are open source; the sign-in service around them is not public.)
Ask these of any vendor — including us. The difference with a zero-knowledge architecture is that the answers are properties of the system, not promises of the company. Policies change with ownership, jurisdiction, and pressure. Architecture limits what there is to hand over, whoever is asking.
If you want the broader philosophy behind building this way, read about Ciphera, and if you want the full inventory of what Ciphera does and does not see, we wrote that down too.