Everyone promises zero-knowledge encryption — four cryptographers went and checked

Every password manager’s pricing page has the same three words on it somewhere, usually in grey, usually beside a tick: zero-knowledge encryption.

Most people read it the generous way — “Nobody but me can ever see my passwords”, end of story, sleep well. It sounds like a wall.

It’s considerably narrower than that. It’s a promise about one specific opponent, it can be tested, and this year four cryptographers went and tested it.

The promise is about the company, not about you

Here is what a cloud password manager means by it.

Your vault is encrypted before it goes anywhere. The encrypted result travels to that company’s servers, which is where it lives from then on. The keys don’t travel with it. So when somebody eventually helps themselves to that database — a breach, a subpoena, an employee with a grudge and a valid login — what they carry off is several million files of gibberish.

Now read who that protects you from. Not a thief holding your laptop. Not malware. Not a convincing fake login page that catches your master password on the way past. The company. Zero-knowledge is a company promising it cannot read the thing it is holding for you.

That is worth wanting. It is also a promise with a very particular way of failing, and the failure is the interesting part.

“On your device” is doing a lot of work in that sentence

Before we get to the failure, there is a distinction buried in the usual wording that deserves dragging into the light, because hardly anyone makes it and it changes what the promise is worth.

“Encrypted on your device” can describe two quite different arrangements.

It can mean a program you downloaded and installed. It sits on your disk. You can check where it came from. It doesn’t change while you’re using it, and it won’t change tomorrow unless you decide to update it. That’s Vauz 😏

Or it can mean a web vault. You open a tab, the company’s server sends your browser a fresh copy of its code, and that is what encrypts your vault. The encryption does happen on your device, in the narrow sense that your processor does the arithmetic. But the instructions arrived from that company, over that connection, a moment earlier — and they arrive again, new, every single time you open it.

Now hold that next to the promise. The company says it cannot read your vault. In a web vault, the same company writes and delivers the code that decides whether it can. Nothing needs to be breached for that to go badly. The server only has to send a slightly different file, to one person, on one day. And there is nothing left to examine afterwards, because the page you were handed stopped existing when you closed the tab.

Plenty of the well-known managers offer both a native application and a web vault, so this is less about which company you picked than which door you walk through. It is still worth knowing which one you are standing in.

Note

Vauz doesn’t need to make the zero-knowledge promise. That promise exists to reassure you about a vault living on somebody else’s server, and yours lives on your own machine. There is no web vault. Your passwords are encrypted on the machine in front of you and stay there — nothing of them reaches us unless you choose to turn on an online backup, and even then what we would hold is encrypted under keys we do not have. Vauz is an application you install, and every release is signed, so the copy you are running is one you can check for yourself. Although we are zero-knowledge in the most literal sense — we genuinely don’t know a single byte of your information. Hard to boast about, given we never built ourselves any other option ¯(ツ)/¯

A claim with no attacker in it isn’t a claim

The only reason that promise can be tested at all is that it names its opponent out loud, and naming the opponent turns out to be most of the work.

Threat modelling is one of the most underrated ideas in security, and it is three questions of homework. Who is attacking. What can they do. What are you keeping from them. Answer those and “secure” stops being a mood and becomes something with edges — arguable, testable, capable of being wrong. Skip them and you get a tick on a pricing page.

Zero-knowledge answers all three, which is to its credit. The attacker is the server holding your vault. It can do whatever it likes: read its own storage, misbehave, lie. You win if it still learns nothing.

So somebody can go and be that server.

Somebody went and was that server

Matteo Scarlata and Kenneth Paterson at ETH Zurich, with Giovanni Torrisi and Matilda Backendal at Università della Svizzera italiana, spent a year doing precisely that. The paper is Zero Knowledge (About) Encryption , appearing at USENIX Security ‘26. Backendal describes the promise under examination as meaning that server access “does not pose a security risk to customers.”

So they built servers that don’t behave . Servers that lie about what they are holding. That hand back the wrong ciphertext, or last week’s copy of it. That quietly substitute one user’s material for another’s. And they did it during the least dramatic moments a password manager has — signing in, sharing an entry with a colleague, syncing a change made on your phone — then watched what the software at the other end did about it.

Across four products they document 31 attacks. Twelve against Bitwarden, seven against LastPass, six against Dashlane, six against 1Password. How much damage they do varies enormously. At the mild end, a dishonest server can quietly alter a single entry in a single person’s vault — no warning, no visible sign, just a saved password that is no longer the one you saved. At the other end is the complete compromise of every vault belonging to an organisation: one company’s entire set of accounts, recovered in a single go.

The fair thing first, because it is true: these are serious products built by people who take this seriously, disclosure ran on a ninety-day clock, and the vendors were for the most part cooperative about fixing what was found.

Four teams, one ditch

The striking part isn’t any individual bug. It’s that four companies — four codebases, four sets of decisions taken years apart by people who never met — kept arriving at the same small handful of mistakes.

• Public keys nobody checked. If your software accepts a key from the server without establishing whose key it is, the server can hand over its own and read everything you encrypt from then on. The encryption works flawlessly. It is simply pointed at the wrong person.
• Ciphertext with nothing verifying it. Encryption hides content. It does not automatically notice edits. Software that decrypts whatever arrives, without first asking whether this is genuinely what it stored, can be fed altered data and will believe every word of it.
• Keys doing two jobs at once. Reuse key material across purposes that ought to be kept apart, and something obtained perfectly legitimately over here quietly becomes a skeleton key over there.
• Entries not tied to their own labels. If the name, the site and the owner of an item aren’t cryptographically bound to the secret inside it, a server can shuffle them freely — ciphertext untouched, meaning entirely rearranged.

None of that is carelessness. It is the standing difficulty of proving that a machine you are obliged to talk to, which is holding everything you own, hasn’t quietly cheated you. When four independent teams end up in the same ditch, the ditch is the story.

Where Vauz sits

Vauz  keeps your vault on your device. Not on our servers.

That is worth unpacking, because it is exactly the sort of sentence people skim past.

Your passwords are encrypted and stored on the machine in front of you. Nothing about that vault reaches us — not its contents, not its size, not the number of entries in it, not how often you open it. No telemetry. No crash reports. No usage analytics. Our servers take no part in unlocking it either; that happens on your hardware, and we could not intervene if we wanted to.

We do keep an account record: how to reach you, and what you have paid for. Nothing about what you actually do with Vauz — no activity log, no record of what you opened or when, nothing that accumulates into a picture of you. None of that is ours to have.

At the time of writing, Vauz runs on one device at a time. Moving to a new machine is a deliberate export and import that you perform yourself. That is a real limitation, and we would rather you heard it here.

Then the part written to outlast all of the above, because products change and promises ought to survive it: anything Sealzi ever holds on your behalf will be encrypted under keys we do not have. Not a pledge to look away. An arrangement in which looking is not among the things available to us.

Same instinct as keeping secrets local, and the same reason privacy shouldn’t be a setting: the most reliable way to secure part of a system is not to build it, and the next best is to build it so it cannot read anything.

Where this stops being flattering

A security claim without its limits is just marketing, so here are ours.

Vauz is closed-source. You cannot read our code and check our work, and that is the strongest form of verification there is. We are not going to dress its absence up as a feature.

At the time of writing this article, we have not had an external audit. We intend to when the budget reaches that far, and when it happens we will publish the scope and the findings, including the parts we would rather not. Until then, security@vauz.sealzi.com reaches us directly, and we would genuinely rather hear it from you than read about it somewhere else.

And keeping data local moves risk rather than deleting it. Your backups become properly your responsibility. A lost laptop is a worse day than a forgotten cloud password. Malware running as you, on your own machine, is still malware, and no vault design repairs that — which is why autofill refuses to trust the page asking for it.

What we can hand you today is that every release is signed with a key you can check yourself, in three commands, without asking us anything.

Three questions worth asking

Of any password manager. This one included.

Which attacker does this promise cover? “Encrypted” with nobody named is decoration. Ask which one, then notice everything the answer quietly leaves out.

Has anyone hostile and competent read it? All four products in that paper looked entirely reasonable right up until somebody skilled sat down with them properly. That is what the reading is for, and it is why the paper is good news rather than bad.

What happens to the promise when the product changes? Features arrive — sync, backups, sharing, team plans — and every one of them can quietly move the line the original promise was drawn around. A claim is only worth something if it still means the same thing two releases later.

The four vendors in that study come out of it more secure than they went in, and their users are better off for it. Public research, responsible disclosure, shipped fixes, and a paper anyone can download and read: that is the machinery working exactly as designed.

The only thing that really changed is that the phrase on the pricing page isn’t only a phrase any more. Somebody wrote down what it would take for it to be true, and then went and looked.