Zero-knowledge encryption explained
Zero-knowledge encryption is the architecture where the service hosting your data cannot read it — even if it wants to, even if it's hacked, even if it's subpoenaed. Here's how it works in plain language, with diagrams.
Mathis Belouar-Pruvot
Quick Answer. Zero-knowledge encryption is an architecture where the service hosting your data cannot decrypt it — the encryption key never leaves your device in plaintext. Even if the server is compromised, served a subpoena, or run by a malicious admin, all it has access to is opaque encrypted data. Used by Signal, Tutanota, Proton, Bitwarden, and Filarr's cloud sync.
When a cloud service says "your data is encrypted," that's usually true but rarely sufficient. The data is encrypted while in transit (TLS) and while at rest (server-side encryption with keys the service holds). But the service still has the keys. If they want to read your data, they can. If they're compelled by a court, they will.
Zero-knowledge encryption is the architecture that makes this impossible by construction. The service literally cannot read your data, because the keys to decrypt it never leave your device.
This article explains zero-knowledge in plain English, walks through how it works in practice, and clarifies the common confusion with end-to-end encryption.
What does zero-knowledge encryption mean?
"Zero-knowledge" in this context is a marketing term that borrows the name of a real cryptographic concept (zero-knowledge proofs) and uses it loosely. The clearer technical term is client-side encryption with no server-side key access.
The promise is straightforward:
- Your device generates the encryption keys
- Your device encrypts your data before sending it to the server
- The server stores only encrypted blobs and never has the keys to decrypt them
- When you log in from another device, your password (or a derived secret) decrypts the keys locally
The result: the service has zero knowledge of the contents of your data. They can see metadata (file sizes, sync timestamps, IP addresses), but the content itself is opaque to them.
How is zero-knowledge encryption different from regular cloud encryption?
Almost every cloud service today encrypts data at rest. Dropbox, Google Drive, iCloud, OneDrive — they all encrypt your files on their servers. The crucial question is: who holds the key?
| Encryption model | Server can decrypt? | Examples |
|---|---|---|
| TLS only (in transit) | Yes — server stores plaintext | Many small services |
| At-rest server-side encryption | Yes — server holds the key | Dropbox, Google Drive, iCloud (mostly) |
| Client-side encryption, server holds key | Yes (still!) | Some "encrypted" services where the server holds a copy of the master key |
| Zero-knowledge / E2E | No — key only on client | Signal, Proton, Tutanota, Bitwarden, Filarr cloud sync |
Server-side encryption protects against one threat: a thief who steals the physical disks from the data center. It does not protect against the service operator reading your data, hackers who breach the service, or governments compelling the service to hand over your data.
Zero-knowledge protects against all three.
How does zero-knowledge encryption actually work?
The mechanism is a chain of operations executed entirely on your device. A typical zero-knowledge service for a note-taking app works like this:
ON YOUR DEVICE ON THE SERVER
────────────── ─────────────
1. You enter your password
│
▼
2. KDF (PBKDF2 / Argon2id)
stretches password into KEK
│
▼
3. Random File Encryption Key (FEK)
generated for each file
│
▼
4. AES-256-GCM(file, FEK) ─────► encrypted blob ─────► stored as opaque bytes
│
▼
5. AES-256-GCM(FEK, KEK) ──────► encrypted FEK ───────► stored alongside blob
│
▼
6. KEK never leaves device
(some services upload an encrypted
copy of KEK that only your password
can unlock — see "key recovery" below)
The server's view of the world: a stream of opaque bytes. Even with full root access to the server, an attacker reads encrypted noise.
For the user's view to make sense across devices, the encrypted KEK is usually uploaded too — but only ever in encrypted form. To unlock it on a new device, you have to re-enter your password, which the server never sees.
What does the server actually see in a zero-knowledge system?
This is the critical question. A server can never see nothing — there's always some metadata required to make the service work. In a well-designed zero-knowledge system, the server sees:
- An opaque encrypted blob per file
- The size of each blob (within a fudge factor — some systems pad)
- Sync timestamps (when blobs are updated)
- Your account identifier (typically an email or a username)
- Authentication metadata (a password verifier, but never the password itself)
It does not see:
- File contents
- File names (well-designed systems encrypt these too)
- Folder structure (also encrypted)
- Note titles, tags, or any in-app metadata
The categories that do leak (size, timing, account email) constitute a side-channel risk — a sufficiently motivated adversary can sometimes infer information from sizes alone. Serious zero-knowledge implementations pad blobs to bucket sizes and add jitter to timestamps to mitigate this.
Why does zero-knowledge matter for your data?
Three concrete scenarios. In a zero-knowledge architecture:
Scenario 1 — The service is hacked. An attacker steals the entire database. They get encrypted blobs and email addresses, nothing more. The blobs are useless without the keys, which are on user devices.
Scenario 2 — The service is subpoenaed. A government compels the service to hand over user data. The service complies — by handing over what they have: encrypted blobs. The government can't decrypt them either.
Scenario 3 — A malicious or careless employee. An admin with database access tries to read user files. They see encrypted bytes. They can't decrypt without the user's password, which the system never stored.
The service literally cannot betray you, even if it wants to or is forced to. That's the value of zero-knowledge: the trust requirement is eliminated by mathematics, not by promises.
What is the cost of zero-knowledge encryption?
Zero-knowledge has real engineering trade-offs.
1. Lost passwords mean lost data. If the service can't decrypt your data, neither can it reset your password. Most zero-knowledge services offer recovery codes or recovery phrases, but if you lose both your password and your recovery secret, your data is permanently inaccessible. This is the cost of true privacy.
2. Server-side features are limited. The service can't search your data, can't generate previews server-side, can't run AI summarization on your notes — because they can't see anything. All such features must run on your device.
3. Multi-device sync is harder. Sharing keys between your devices requires a careful pairing protocol (typically ECDH with HKDF derivation). Designing this correctly is non-trivial.
4. Real-time collaboration is harder. If two users edit the same encrypted document, the merge has to happen client-side or via cryptographic protocols (CRDTs over encrypted data is an active research area).
These are accepted costs. The privacy guarantee is too valuable to give up for marginal feature gains.
How is zero-knowledge different from end-to-end encryption?
The terms are often used interchangeably. They overlap but are not identical.
End-to-end encryption (E2E) describes a property: only the endpoints of a communication can read the content. Any intermediate (server, ISP) cannot. The textbook example is Signal: a message is encrypted on your phone, sent through Signal's servers, and decrypted only on the recipient's phone.
Zero-knowledge is a deployment model for storage services: the server stores your data encrypted with keys it doesn't have. It can be seen as E2E applied to a "communication" between your past self (when you uploaded) and your future self (when you download on another device).
Most zero-knowledge services also implement E2E for sharing (when you share a file with another user, the keys are exchanged client-to-client without the server seeing them). But you can have zero-knowledge without sharing (a personal vault) or E2E without storage (a chat app that doesn't keep history).
For a deeper comparison, see end-to-end vs zero-knowledge: what's the difference?.
Which apps use zero-knowledge encryption?
Notable services that implement zero-knowledge correctly:
- Signal — end-to-end messaging
- Bitwarden — password manager (also zero-knowledge for vault storage)
- 1Password — password manager
- Proton (Mail, Drive, Calendar) — Swiss provider, fully zero-knowledge
- Tutanota — encrypted email, calendar, contacts
- Standard Notes — encrypted notes
- Cryptomator — local encryption for cloud storage
- Filarr — local-first workspace with optional zero-knowledge cloud sync
Services that are commonly believed to be zero-knowledge but aren't: iCloud (Apple holds the keys for most data, except items behind Advanced Data Protection), Dropbox, Google Drive, OneDrive.
How does Filarr implement zero-knowledge?
Filarr is a local-first workspace where the cloud sync layer is zero-knowledge. The architecture:
- Files live encrypted on your disk first. No cloud needed for the local app to work — that's the local-first part.
- When you enable cloud sync, your device encrypts each file with AES-256-GCM using a per-file FEK. See KEK and FEK explained for the key hierarchy.
- The server stores only encrypted blobs. The data lives on Cloudflare R2 in Europe. Without your password, the blobs are noise.
- Multi-device pairing uses ECDH (elliptic curve Diffie-Hellman) with HKDF-derived session keys to share your master key between your devices without ever exposing it to the server.
- Even your account login uses a password verifier — your password never reaches our servers, only a derivative that proves you know it.
The result: if our servers were compromised tomorrow, attackers would get encrypted noise and email addresses. They could not read a single file. If we received a subpoena, we could only hand over what we have — encrypted blobs — and we cannot decrypt them.
Read Filarr's full security architecture for the exact parameters, threat model, and audit results.