What "Zero-Knowledge" Actually Means
"Zero-knowledge" is one of the most abused terms in software marketing. Let's define it precisely: zero-knowledge encryption means the service provider cannot read your data, even if they want to, even if they're hacked, even if compelled by a court order.
This is possible because the encryption key never leaves your device. The server stores only ciphertext, encrypted data that is mathematically useless without the key. The company running the server doesn't have the key. Nobody does, except you.
Contrast this with what most "secure" apps actually do: they encrypt data in transit (SSL/TLS) and at rest (server-side encryption). In both cases, the service holds the decryption key. A breach, a rogue employee, or a government subpoena can expose your data. This is called server-side encryption, and it is not zero-knowledge.
AES-256-GCM: The Standard That Actually Matters
Keepra encrypts every sync blob with AES-256-GCM, the Advanced Encryption Standard, 256-bit key, Galois/Counter Mode. Let's break that down:
- AES (Advanced Encryption Standard): Adopted by the US government (NIST 2001). The same cipher used to protect classified information. There is no known attack that breaks AES faster than brute-force at 256-bit key length.
- 256-bit key: 2²⁵⁶ possible keys. If every atom in the observable universe were a computer running at the speed of light since the Big Bang, you would not have meaningfully sampled this space.
- GCM (Galois/Counter Mode): Provides both confidentiality AND authentication. An attacker who modifies the ciphertext in transit cannot successfully forge a valid authentication tag, any tampering is detected and rejected.
- Random IV per blob: Each encrypted object uses a fresh random Initialization Vector. Even if you encrypt the same data twice, the ciphertext is different every time, preventing pattern analysis.
PBKDF2: Why 600,000 Iterations?
Your Secret Key (a memorable passphrase or a generated random key) isn't directly used as an AES key. It goes through PBKDF2-SHA256, Password-Based Key Derivation Function 2, to stretch and harden it.
Keepra uses 600,000 iterations. The NIST recommendation as of 2023 is 600,000 for PBKDF2-HMAC-SHA256. Here's what this means in practice:
- Each "guess" at your password requires running SHA-256 600,000 times
- On modern hardware (GPU), this limits brute-force to roughly 1,000–5,000 guesses per second
- A 12-character random key with a large character set would take millions of years to brute-force at that rate
In comparison, LastPass was using only 1 iteration (later 5,000) for many accounts at the time of their 2022 breach, which is why some users' passwords were cracked from the stolen vaults within months.
The LastPass Lesson
In August and December 2022, LastPass announced that attackers had stolen encrypted password vaults from 25+ million users. The data included usernames, URLs, encrypted passwords: and, critically, the PBKDF2 iteration counts for each account.
Why did this matter so much? Because:
- LastPass used server-side storage of the "encrypted" data, making it a single high-value target
- Many accounts used weak or commonly-used master passwords
- Attackers could combine the stolen URLs (which were NOT encrypted) with cracked passwords to immediately access high-value accounts
- Older accounts had very low iteration counts (some as low as 1), making GPU-based cracking trivial
Keepra's architecture makes this attack fundamentally different: the server never holds the key. A breach exposes only {iv, ciphertext, timestamp}, computationally useless without the Secret Key that only exists on your device.
Why Notion Doesn't Count
Notion markets itself as a workspace for "sensitive" business data. But Notion stores your data in plaintext on their servers, they can read everything. Their security model protects against external attackers (using server-side encryption at rest), but not against Notion itself, government orders, or a future insider breach.
This isn't unique to Notion. Google Keep, Microsoft OneNote, Evernote, and virtually every mainstream productivity tool works this way. They are cloud-first, not privacy-first. For most data, this trade-off is fine. For credentials, client data, private notes, and anything sensitive, it's not.
How Keepra's Secret Key Model Works
Keepra's sync model uses a single Secret Key that serves dual purpose:
- Authentication: The key is deterministically hashed to derive a Firebase email+password. This identifies which user's data to sync from Firestore.
- Encryption: The key goes through PBKDF2 (600k iterations) to derive the 256-bit AES-GCM key used to encrypt/decrypt data.
The same key on any device → same Firebase account → same Firestore data → same decryption. No separate passphrase. No email/password to remember. Just one key that you can store securely (copy link, save as file, or scan a QR code from a linked device).
{iv, data, ts} blobs. Even if our entire Firebase project were compromised, an attacker would need your Secret Key to decrypt anything.
Security Model Comparison
| Feature | LastPass | Notion | Bitwarden | Keepra |
|---|---|---|---|---|
| Server can read data | ✗ No (but…) | ✗ Yes | ✓ No | ✓ No |
| Zero-knowledge E2E | ⚬ Partial | ✗ No | ✓ Yes | ✓ Yes |
| Cipher | AES-256 | AES-256 (server) | AES-256 | AES-256-GCM |
| Key iterations (2026) | 600k* | N/A | 600k | 600k |
| Breach history | ✗ 2022 | , | , | , |
| Offline-first | ✗ No | ✗ No | ⚬ Partial | ✓ Yes |
*LastPass raised iterations after the breach; older accounts may still have lower counts in stolen data.
For the full comparison of password managers, see our 2026 password manager comparison. For offline-first security benefits, see why your app should work without the internet.