"Zero knowledge" is a design, not a policy

“Zero knowledge” has become one of the most used and least examined phrases in cloud storage. It appears on pricing pages next to “military-grade” and “bank-level”, and it usually means something true but modest: the provider has a policy of not looking at customer data, backed by access controls and an audit log, and employees are trained not to.

That is a policy. A policy is a promise about behaviour. It can be broken by an insider, overridden by a court order, bypassed by an attacker with the right credentials, or quietly amended in a later version of the terms. None of that requires anything to go wrong with the cryptography, because in a policy-based system the cryptography was never what kept the provider out.

A design is different. In a design, the provider cannot read the data because the provider never holds anything that could. There is no key to misuse, no backdoor to be compelled to open, no privileged account whose compromise exposes plaintext. The promise is not “we won’t”. It is “we can’t, and here is why”.

This article is about how to tell the two apart, using Sapherbox as the worked example, and including the places where even a design has to be honest about its limits.

The test: where does the key come from?

The single most useful question for any encrypted service is where the keys are made and who ever holds them.

In Sapherbox, every key is generated in your browser. Your account master key is 256 random bits produced on your device at registration. Your identity key pairs, classical and post-quantum, are generated there too, and the private halves are encrypted under the master key before anything is stored. The master key itself is encrypted under a key derived from your password, on your device, and the password never leaves it. What reaches the server is a set of locked boxes. The server can store them, back them up and hand them back to you. It cannot open any of them.

Compare that with the common alternative: the provider generates a key per customer, stores it in a key management service, and encrypts data with it on the server. The data is encrypted at rest, which is good against a stolen disk. But the provider holds the key, so “zero knowledge” is a statement about intent, not capability. Ask where the key lives and the answer is “with us, protected by policy”.

Five places a design shows

A policy and a design look identical on the landing page. They diverge at the edges, where the provider would need plaintext to make something convenient work. Those are the places to look.

Password reset. A provider that can reset your password and give you back your files holds a key to those files. In a design, the reset path has to go through something only you hold. Sapherbox uses a recovery code shown once at registration, and optionally an escrow key that your own organisation generates and keeps. There is no provider recovery key, and we have written about why.

Search. Full-text search over plaintext on the server means the server reads your documents. A design has to search without the words. Sapherbox’s search works on blinded tokens computed on your device with a key the server cannot open, and the server matches tokens without learning what they stand for. The cost of that is documented: the server learns which files share tokens, not which words.

Sharing. If the server can hand a file key to a new recipient, the server can hand it to anyone, including itself. In Sapherbox the person sharing seals the key to the recipient’s public key on their own device and signs the grant. A compromised server cannot add itself as a recipient or redirect a share, and the recipient’s identity is pinned at first contact so a later key substitution is detected.

Revocation. A policy-based system removes a row from a permissions table. A design has to make the old keys useless, because the removed person may still hold them. Sapherbox rotates the keys of everything the person could open.

Scanning and analysis. Malware scanning, data classification, analytics and AI features all want plaintext. A provider that offers them server-side has plaintext. Sapherbox runs content disarm, classification, SQL analytics and the on-device AI features in your browser, before encryption or after decryption on your side, and the server sees only the results you choose to store, encrypted like everything else.

Each of these is a place where the convenient implementation needs the server to read your data. A provider that claims zero knowledge and also offers server-side search, server-side scanning and support-ticket password resets is describing a policy.

What a design still cannot hide

If a design is honest, it also says what the server does see, because no design hides everything. We do not use the phrase “zero knowledge” for Sapherbox for exactly this reason. The server knows how large your files are, when they were created and changed, how your folders are organised, who has access to what and with which role, who signed in and what they did, and which blinded search tokens occur in which files. It can see the labels classification attaches. It cannot see content, names, notes, search terms, passwords or keys.

That list is published in our security overview, and the whitepaper for security teams lists the known limitations alongside it: a compromised device sees what its user sees, the network connection uses classical TLS and carries metadata, revocation cannot recall copies already downloaded. A design that does not publish its limits is asking you to take its word for the rest, which brings you back to a policy.

Why the distinction matters more than it used to

Two things have changed. Regulators increasingly ask not whether data is encrypted but who holds the keys; the question appears in GDPR Article 32 assessments, in NIS2 supply-chain reviews, and in every serious vendor questionnaire. And the threat model has grown: a provider that holds keys is a single point where a breach, an insider, a subpoena or a future quantum computer turns every customer’s data into plaintext at once. A design spreads that risk back to where the data belongs, with each customer, on each device.

The way to tell which one you are buying is not the phrase on the page. It is the answer to a few specific questions: where are keys made, how does password reset work, how does search work, what happens when someone is removed, and what does the server see. A design answers all five in a sentence each and shows you the list of what it cannot hide. A policy answers with a certification and a promise.

Questions?

If you want to put those five questions to us directly, or your security team wants the full technical description behind the answers, get in touch at hello@sapherbox.com.