What “the server can’t read it” actually means

"The server can't read your secrets" is one of the most common sentences on security product pages. It is also one of the least specific. Read one way, it means the data is encrypted at rest, which almost every service does. Read another way, it means nobody at the company could see your data even if they wanted to. Those are very different promises.

This post spells out what the sentence means for Crunu, layer by layer: what the server stores, what it cannot do even if someone takes it over, what it still sees, and where the protection ends. The same questions are worth asking of any vault, including the ones you are comparing Crunu against.

Three layers, three different guarantees

Every protection in a system like this comes from one of three places, and it helps to keep them apart.

Crunu's interface labels its guarantees with these same three layers, so you can see which kind of protection you are relying on. "The server can't read it" is a claim about the first layer. It should survive a breach of the second.

What the server stores

A Crunu server holds:

• Ciphertext. The contents of every environment, encrypted on a device before upload.
• Public keys. The public halves of member, machine and organization keys. The private halves never reach it.
• Signed documents. Access lists, versions, access profiles, invitations and revocation lists, each signed by the person or key that created it.
• Token hashes. For sessions and links, the server keeps a keyed hash, not the token itself. Service tokens are created in the admin's browser, and the server knows only their public keys.
• Metadata. Names, email addresses, the audit log, sizes and times. More on that below.

There is no point in the protocol where the server holds a key that decrypts a value. Encryption and decryption happen only in the browser, through WebCrypto, and in the crunu agent.

What the server cannot do, even if compromised

The interesting test of a blind server is not whether it is honest. It is what happens when it is not: a stolen database, a malicious operator, a hijacked cloud account. Here is what Crunu's design rules out.

Decrypt values. The server never has an environment key. Each environment key is sealed to the public key of every recipient, and only their private keys can open it.

Guess your password from a copy of the database. Your account key is derived from your password and your Secret Key, a random value of about 128 bits created on your device. Neither is sent over the network in any form. An attacker with the full database would have to guess both, which is why offline password guessing gets nowhere. The Emergency Kit post covers this in detail.

Add itself as a recipient. Who can read an environment is written in a document signed by an admin. Clients and agents check that signature before sealing a key to anyone. A server that inserted its own key would produce a list nobody signed, and every client would reject it.

Swap the data. Every version is signed by the member who saved it, and the ciphertext is bound to its organization, environment and version number. A server cannot pass off one environment's data as another's, or edit a version without the signature failing.

Quietly roll you back. A signature proves who wrote something, not that it is current. So browsers and agents remember the newest state they have verified and refuse anything older. A server that served last month's access list, from before someone was removed, would be caught by any device that had already seen the newer one. See rollback protection.

What the server still sees

A blind server is blind to values, not to everything. To route data, enforce access and keep a log, Crunu's server sees:

• names of organizations, projects, environments and machines;
• email addresses of members;
• the audit log, including who did what and when;
• the size and time of each version;
• which person or machine received which version, and from which address.

That last item is not a leak by accident. It is the record that powers the exposure report when someone leaves. But it is information, and it lives on the server.

This is why Crunu says “blind server” and not “zero-knowledge”. The server knows nothing about the contents of your secrets. It knows quite a lot about their shape. A practical rule follows: do not put secrets in names. A project called acquisition-of-competitor-x tells the server something, encrypted or not.

What a compromised server could still do

Some attacks are out of reach of cryptography because they do not require reading anything.

• Refuse service or lose writes. A server can stop answering, or drop data. The defense is operational: backups, an offline copy of your environments, and the ability to move the server elsewhere with one archive.
• Serve a tampered web client. This is the main residual risk of any browser-based vault. If the server sends a modified page, that page sees your password and Secret Key as you type them. Crunu's answers are signed releases, a reproducible web build, a strict content security policy with integrity checksums, and a single-file client, crunu.html, that loads its code from disk and checks the site against the signed release. Administrators are advised to work from that file.
• Freeze a new device. A server colluding with a removed member could show a freshly set-up device an old state of the organization. Devices that have seen the newer state are not fooled, but a brand-new one has nothing to compare against. Closing this fully would need an external transparency log, of the kind Certificate Transparency uses for TLS certificates. Crunu does not have one; its settings show the key generation and revocation epoch so you can compare them across your own devices.
• Skip waits it enforces. Recovery codes release keys after a waiting period, one hour by default, during which you are notified. The server enforces that wait, so a compromised server could skip it.
• Ignore network rules. Restricting an environment to certain networks is a server-side check. It is a useful extra layer, but a compromised server would not apply it.

The TUF specification, written for software update systems, describes rollback and freeze attacks in the same terms. They are general problems for any system that trusts signed data from an untrusted server, not quirks of one product.

What no server can protect

Some risks sit outside the server entirely.

• The device where values are decrypted. Malware, a hostile browser extension or root access on a laptop sees what the user sees. Encryption ends where the plaintext is used.
• Machines that legitimately receive secrets. A production machine running the agent is a valid recipient. Root on that machine can read what it was given, and a running process keeps its environment variables until it restarts.
• Copies. Anyone who decrypted a value can copy it. Removing their access protects future versions, not the past. That is why offboarding ends with reissuing values at providers.

Crunu lists these in its security limitations. They are not unusual for this category; they are just rarely written down.

Questions to ask any vault

If you are evaluating vaults, these questions get past the marketing sentence quickly.

1. Where does encryption happen, and where are the keys? If the server can decrypt on request, "can't read it" means "chooses not to".
2. What exactly does the server see in plaintext? Ask for the list: names, emails, logs, sizes, access records.
3. Can the server change who has access? If access lists are not signed by someone the clients trust, a compromised server can add itself.
4. What stops it from serving old data? Signatures alone do not.
5. Who delivers the client code, and how can you check it? For a web app, the honest answer involves signatures, reproducible builds or a local copy.
6. What does the vendor say it does not protect? A product that names its limits is easier to reason about than one that claims none.

For Crunu, the detailed answers are on what the server sees, how encryption works and the security overview.

Sources

• RFC 6962: Certificate Transparency, checked October 27, 2026.
• The Update Framework Specification, checked October 27, 2026.