"Zero-knowledge" is one of those phrases that gets printed on a lot of landing pages. Used properly it means something specific: the provider of the service has no knowledge of your content or of the keys that protect it. Not "promises not to look". Cannot look.
The test: can they reset your password?
Here is a simple way to tell. If you forget your password and the company can restore access to your existing data, then the company holds, or can derive, the key. That may be convenient, but it also means an employee, an attacker who breaches them, or a legal order can reach your data.
A zero-knowledge design fails that test deliberately. The key is derived from something only you know, on your device, and never transmitted.
How VaultBe is built around it
- The key comes from your pattern. It is stretched with Argon2id on your iPhone. The pattern is never stored and never leaves the device.
- There is no account. We have no user database, so there is nothing that links a person to a vault.
- Backups are encrypted before upload. They go to your own iCloud as ciphertext. Apple holds the data without the key; we hold neither.
- Names are encrypted too. File names, folders, dates and thumbnails live inside an encrypted index.
The full design is on our Security page.
The cost, stated plainly
Zero-knowledge has a price: if you lose both your pattern and your recovery phrase, your vault is gone. We cannot make an exception, verify your identity, or look something up, because there is nothing to look up.
That is why VaultBe makes you write down a nine-word recovery phrase when you create a vault, and why we wrote a whole guide on storing it safely.
What it does not cover
Zero-knowledge is about the provider. It does not protect a vault that is open in front of someone, a pattern someone watched you draw, or a phone with malware on it. Those are different problems with different tools: auto-lock and screen protection, a strong pattern, and keeping iOS up to date.