What is zero-knowledge encryption?

The one-sentence version

Your data is encrypted on your device with keys derived from a secret only you know, before anything is transmitted, so the service stores ciphertext it has no way to decrypt.

The name is borrowed from "zero-knowledge proofs" in cryptography, but in the storage world it means something simpler and very practical: the vendor's knowledge of your plaintext is zero.

How it actually works

1. You choose a master password. It never leaves your device. It is not sent at sign-in, not stored server-side, not recoverable by support.
2. A key derivation function stretches it into a key. Modern systems use Argon2id, which is deliberately memory-hungry (Keyvaci uses 64 MiB per guess) so that brute-forcing billions of guesses is economically absurd.
3. Your device encrypts everything with that key (or with keys protected by it) using authenticated encryption such as XChaCha20-Poly1305, which both hides the data and detects tampering.
4. Only ciphertext travels. The server stores it, replicates it, backs it up, and can do absolutely nothing else with it.

What it protects you against

• A breach of the vendor. Attackers who take the whole database get ciphertext and no keys. Compare that with breaches where the vendor could read the data, and therefore so could the attacker.
• Insiders at the vendor. A rogue employee has the same access to your plaintext as an outside attacker: none.
• Legal compulsion. A vendor can only hand over what it holds. Ciphertext is the honest maximum.
• Vendor lock-in by hostage-taking. If the vendor cannot read your data, "pay us or lose it" loses its teeth, provided the vendor also promises export access, as any serious one should.

What it does not protect against

Honest vendors say this part out loud:

• Compromise of your own device. Decryption happens where you are; malware there sees what you see.
• Weak master passwords. Key derivation slows guessing; it cannot make "password123" safe. Length beats cleverness.
• Losing the keys. The vendor cannot reset what it never had. Serious business products solve this with an organisation-held recovery key, so recovery is possible without giving the vendor any power. That is how Keyvaci's recovery works.

Questions that expose a fake claim

1. "Can your support team reset my master password?" If yes, they hold something that can decrypt your data.

2. "Exactly which fields are encrypted client-side?" Some products encrypt entry passwords but leave titles, URLs, and structure readable. Keyvaci encrypts entries and vault names; the inventory of what we store is published.

3. "If I sign in with SSO, where does the encryption key come from?" A good answer names a mechanism that keeps key derivation on your device. In Keyvaci, SSO answers who you are; keys still come only from your master password.

4. "What happens to my data if I stop paying?" Zero-knowledge plus read-only-forever is trustworthy. Zero-knowledge plus deletion threats is a contradiction in spirit.

Zero-knowledge in a team setting

Multi-user vaults add a real complication: sharing means encrypting a vault key for a colleague's public key, and that is only safe if the public key genuinely belongs to your colleague. Keyvaci solves this with organisation countersignatures: an administrator verifies each member's key fingerprint out-of-band and countersigns it, and every device checks that signature before sharing anything. An attacker who wants into your vaults would have to fool a human administrator into signing their key, on a channel outside the system.

Want to see all of this behave in practice, including a live view of what the server receives? Try the interactive demonstration on our homepage, or read the full security architecture.