Zero-Knowledge Encryption, Explained Without the Marketing
What zero-knowledge actually means in a password manager, which guarantees it does and does not give you, and how to tell a real claim from a slogan.
"Zero-knowledge" appears on the landing page of almost every password manager, usually next to a padlock. It is a real and useful property. It is also routinely stretched past what it can carry.
This is what the term means, what it protects you from, what it does not, and the questions worth asking of any product that claims it.
The property, stated plainly
A service is zero-knowledge, in the sense the password-manager industry uses the phrase, when the operator cannot read your data even if they want to.
Not "will not". Cannot. The distinction is the whole point. A promise not to look is a policy — it survives exactly as long as the company's good behaviour, its security, and its ownership. An architecture where the operator holds only ciphertext is a structural fact. Subpoenas, breaches and acquisitions do not change it.
The mechanism is simple to describe: encryption and decryption happen on your device, using a key derived from a secret the server never receives.
How the key is derived
Your master password is not the encryption key. It is the input to a key derivation function, which stretches it into one.
master password
│
▼
KDF (slow, salted, memory-hard)
│
▼
vault key ──► encrypts / decrypts the vaultThat KDF step is doing specific work. A raw password is short, low-entropy and guessable at enormous speed. A modern KDF — Argon2id and scrypt are the current recommendations — is deliberately expensive in both time and memory, which is what blunts an attacker's advantage in specialised hardware. Memory-hardness is the part that matters most: GPUs and ASICs can parallelise arithmetic cheaply, but not memory.
The salt, unique per vault, is what stops one precomputed table from being reused against every user at once.
Two properties follow, and they are the ones that count:
- The key exists only on your device, only while the vault is unlocked.
- The server, if there is one, sees ciphertext and nothing else.
What zero-knowledge protects you from
Be concrete about the threats it actually removes.
| Threat | Does zero-knowledge help? |
|---|---|
| The provider's database is stolen | Yes. The attacker gets ciphertext. |
| An employee goes looking through vaults | Yes. There is nothing readable to look at. |
| A government compels the provider to hand over data | Yes. They can only hand over ciphertext. |
| The provider is acquired and the privacy policy changes | Yes. Policy cannot retroactively decrypt. |
| Malware on your device | No. |
| Your master password is guessed | No. |
| A phishing page that captures your master password | No. |
| A backdoored or tampered client build | No. |
The bottom half of that table is where most real-world losses happen. Notice what they share: they all attack the endpoint, not the server. Zero-knowledge moves the trust boundary to your device — it does not remove it.
The claim has a load-bearing assumption
Here is the part that marketing pages skip.
In a web-based manager, the code that performs the encryption is delivered by the same server that stores the ciphertext. Every time you load the page, you receive a fresh copy of the client and run it immediately.
That server could, in principle, serve a build that quietly transmits your key. You would have no practical way of noticing. The cryptography is sound; the delivery channel is the weak point.
This does not make browser-based managers useless. It does mean "zero-knowledge" is a claim about the architecture, and it holds only as far as you can trust the client actually running on your machine. Which is why the delivery model is worth as much attention as the cipher:
- Reproducible builds let a third party verify that a released binary corresponds to the published source.
- Open source clients allow the code to be reviewed at all.
- Long-lived installed clients narrow the window: you are not re-fetching the security-critical code on every use.
- Local-only vaults sidestep the question entirely — there is no server in the position to serve you a different client.
How NexusPass approaches it
NexusPass takes the last of those routes, which is the most boring one and, for a single-user vault, the most defensible.
The vault is a file on your device. There is no account, no sync server, and therefore no operator who could be compelled, breached or acquired. The question "can the provider read my vault?" does not need a cryptographic answer, because there is no provider in the data path.
Key material is held by the platform's own secure storage — the Android Keystore and the iOS Keychain — rather than written into application storage. The vault re-locks on a timer and when the app is backgrounded, because the window in which plaintext exists in memory should be as short as the product can make it.
On specifics. NexusPass is still in development, and this article deliberately does not name its cipher, KDF parameters or key sizes. Those belong in documentation that ships alongside a release and can be checked — not in a blog post written ahead of one.
Questions worth asking any provider
If you are evaluating a password manager, these five get you further than any comparison table:
- What exactly is sent to your servers? "Encrypted data" is not an answer. Metadata — entry counts, URLs, timestamps, folder names — is often stored unencrypted, and it is more revealing than people expect.
- Which KDF, and with what parameters? Argon2id with documented memory and iteration costs is a real answer. "Industry-standard encryption" is not.
- Can I verify the client I am running? Reproducible builds, published hashes, open source.
- What happens when I forget the master password? If the answer is "we can recover it", the architecture is not zero-knowledge, whatever the homepage says. This one question resolves most claims on its own.
- What is encrypted, and what is only stored? Attachments and TOTP seeds are not always covered by the same envelope as passwords.
Question four is the sharpest instrument in the set. Recovery and zero-knowledge are mutually exclusive by construction: if someone other than you can restore access to your data, someone other than you can reach your data.
The honest summary
Zero-knowledge encryption is a genuine architectural property with a precise meaning, and it is worth insisting on. It removes an entire class of risk — everything that depends on trusting the operator over time.
What it does not do is make a device safe, a master password strong, or a client trustworthy. It relocates the trust boundary rather than dissolving it, and knowing exactly where that boundary now sits is the difference between understanding your security and reciting a slogan.