The claim, stated precisely
Zero-knowledge means the provider cannot read your data, because the keys that decrypt it are derived on your device and are never sent. The server holds ciphertext it has no way to open. That is the whole claim — and notice what it does not say: not that the provider is trustworthy, not that they are well run, not that they have never been breached. It says that those questions matter less, because a server that cannot read your vault is a much less interesting thing to steal.
The test is uncomfortable and simple: if you forget your master password, can the provider get your data back? If yes, they can read it. Every real zero-knowledge system answers no, and that answer is the cost of the guarantee.
What actually happens on your device
Concretely, in our case: your master password and your email go into Argon2id — 64 MiB of memory, 3 passes, 4 lanes — which produces a master key. That key is stretched, and the result is split two ways.
One branch is hashed and sent to the server as your authentication hash; it is the only derived value that ever crosses the wire, and it cannot be run backwards into the other branch. The other branch becomes the vault encryption key, which stays on the device. Items are encrypted with AES-256-GCM under a fresh 96-bit nonce each time.
The important property is the split, not the algorithm names. Plenty of products use the same primitives and still hold a key that can open your data. What makes it zero-knowledge is that the value proving who you are and the value decrypting your vault are different, and only the first one leaves.
What the server still sees
This is the part most explanations skip, and it is the part that decides what a breach would actually cost you. Encrypted contents are not the same as no information.
Our server knows your email address, because you log in with it. It knows when you logged in, from roughly where, and on what device — that is what makes a “new sign-in” alert possible. It knows how many items you have and when each one changed, because it stores and syncs them. It holds an audit log for as long as your plan keeps one. Those are metadata, they are real, and no amount of client-side encryption removes them.
What it does not hold is anything that opens the box: not your master password, not your vault key, not the plaintext of any item, and not enough to reconstruct any of the three.
- Seen: your email, sign-in times, the IP a request came from, the devices you sign in from, item and folder counts, modification timestamps, billing status, audit events.
- Not seen: master password, vault key, item titles, usernames, passwords, card numbers, secure notes — every item reaches the server as one encrypted blob. TOTP secrets are not there at all: they live in a different app.
- Kept for: 7-day free / 30-day basic / 365-day premium, depending on plan.
The asterisk on “never leaves your device”
Here is one we would rather you heard from us. “The key never leaves your device” is a statement about the network, not about memory or storage, and on a phone it needs qualifying.
On the web and in the browser extension, the vault key exists only in RAM for the length of the session. On mobile it is different: the key is written to the OS keychain, protected by biometrics or the device passcode, because that is what makes Face ID unlock possible at all. It is deliberately not cleared when the app locks — only signing out removes it.
The consequence is worth stating in one sentence, because no vendor volunteers it: on a phone, the practical floor on your vault is your device credential, not your master password. That is an accepted trade for unlock that people will actually use, not an oversight, and it is written down in our code with a test that fails if someone changes it quietly. Any vendor offering biometric unlock has made some version of this same trade — it is a fair question to ask them.
A phone with a four-digit PIN and biometric vault unlock is protected by that PIN. If that is not a trade you want, turn biometric unlock off and type the master password.
Four checks you can run on any vendor
None of these require trusting a marketing page, and all four work on us.
- Try the forgotten-password flow. If support can restore your vault, the claim is false. If the answer is “your data is gone unless you have a recovery key”, it is behaving like a real one.
- Look for published parameters. A vendor that tells you which KDF it uses and with what cost parameters is making a checkable claim; “bank-grade encryption” is not a claim at all.
- Watch the network on a web client. The vault should load as ciphertext and decrypt after you type the password — no request should be fetching a key.
- Ask what the server holds besides ciphertext. A vendor that can answer this quickly and specifically has thought about it. A vendor that says “nothing” has not.
What we cannot claim yet
Applying the fourth check to ourselves: no published third-party security audit yet. Our cryptography is documented, our client code ships to your browser where it can be read, and the design is described on our security page in the same detail as above — but an independent audit is a different kind of evidence, and we will not imply we have one until we do.
Until then, the honest position is that you should verify the checkable parts rather than take the claim on trust. That is what they are for.