The Custody Problem

In 2013, a small email provider in Texas received a court order. Lavabit had built its reputation on encrypted email — its roughly 410,000 users included, as it turned out, Edward Snowden — and the government wanted access to one account. But the order did not ask for one account. To read one user’s mail as it moved through the system, the government required Lavabit’s TLS private key: the key that protected every user’s connection. Ladar Levison, the company’s founder, was ordered to hand over the master key to his entire service. He printed it in 4-point type across eleven pages, delivered it in the least usable format he could contrive, and then did the only thing that actually protected his users: he shut the company down.

Lavabit’s users did not lose their privacy because the cryptography failed. AES did not fail. TLS did not fail. They lost it because of where the keys lived. The provider held them, so the provider could be compelled — and anything the provider can be compelled to do, the provider can also be tricked into, breached for, or bribed toward. The mathematics were sound. The custody was not.

This essay is about that gap — the distance between “encrypted” and “safe” — because nearly every document system you have ever used lives inside it.

What “encrypted” usually means

When a vendor tells you your documents are encrypted, they almost always mean two specific things, and both are true.

Encrypted in transit. Your file travels from your machine to their server inside a TLS tunnel. Anyone tapping the wire — a hostile network, a compromised router, someone on the same coffee-shop Wi-Fi — sees only ciphertext. This protects the pipe.

Encrypted at rest. On the server, your file is stored encrypted, typically with keys managed by the provider’s key-management service. If someone steals a decommissioned drive from the data center, or a backup tape falls off a truck, they get ciphertext. This protects the disk.

Both protections are real, mature, and worth having. Note carefully, though, what they have in common: in both cases, the threat being defended against is an outsider — the wiretapper, the drive thief. And note who is being defended against in neither case: the operator. The provider terminates the TLS connection, so the provider sees your plaintext arrive. The provider holds the at-rest keys, so the provider can decrypt your stored files whenever its software decides to. It must be able to — that is how it renders your preview thumbnails, indexes your text for search, scans for malware, and deduplicates storage.

Encryption in transit and at rest protects the pipe and the disk. It does not, and cannot, protect the document from the party that holds the keys. The industry’s standard phrase — “encrypted in transit and at rest” — is best read as a precise legal statement of what is not claimed.

The custodian

Call this party what it is: a custodian. Your documents are in its custody the way funds are in a bank’s custody — except banks are regulated as custodians, and document platforms mostly are not. The custodian can read everything. The entire security of the system therefore reduces to one question: what does it take to make the custodian act against you?

The historical answer is: not much, and in more ways than most threat models bother to list.

Legal compulsion. A subpoena, warrant, or national-security letter served on the provider is served on the keys. You may never be told; gag provisions are routine. The order need not name you — Lavabit’s order was about one user and exposed all of them. And “the provider” means whichever legal entity operates the servers, under whichever jurisdictions can reach it. Your confidentiality is bounded by the compliance posture of a company you have never met, responding to legal process you will never see.

Breach. In 2023, attackers found a SQL-injection flaw in MOVEit Transfer — a product whose entire purpose was secure file transfer, sold to enterprises precisely because email attachments were considered too risky. The Cl0p group used it to exfiltrate files from thousands of organizations: government agencies, banks, pension funds, universities. Tens of millions of people had personal data taken from a product marketed as secure. The point is not that MOVEit’s developers were careless — it is that the architecture made a single application flaw equivalent to total disclosure, because the server could read what it stored. When the custodian can read everything, every bug in the custodian is a bug in your confidentiality.

Insiders. Every custodial system has administrators, and administrators have access. Most insider access is legitimate; some is curious; a little is malicious; all of it is invisible to you. The rogue employee, the compromised admin account, the contractor with over-broad permissions — these are not exotic threats. They are line items in every breach report ever compiled.

Deception at the service layer. In 2007, Hushmail — “encrypted email” — turned over readable plaintext of specific users’ messages under a court order. No cipher was broken. Users of the convenient server-side mode had their passphrases pass through Hushmail’s servers, and the servers could simply be told to remember them. The system was encrypted; the service was the adversary’s point of entry. When encryption is a feature the operator performs for you, the operator can be made to perform it differently.

Drift. Companies are acquired; their data goes with them, under new management with new incentives. Terms of service are revised. Storage products sprout AI features that “process your content to improve your experience.” Bankruptcy courts treat data as an asset. None of these are attacks. All of them move your documents into hands you did not choose, without a single system being hacked — custody simply flows, and it flows away from you.

Notice what this list does not require: no broken ciphers, no nation-state cryptanalysis, no mathematics at all. Every one of these failures walks in through the front door, using the keys that were sitting in the building.

The hierarchy of “trust us”

Providers are not silent about this problem. Their answers form a ladder, and it is worth naming the rungs, because each one is an admission about the rung below.

At the bottom sits the policy promise: “We take your privacy seriously.” A privacy policy is a description of intentions, revisable at will, enforced — if at all — after the harm.

Above it, the contractual promise: the NDA, the DPA, the HIPAA business-associate agreement. These are stronger; they attach liability. But a contract does not prevent disclosure any more than a speed limit prevents speeding. It prices the violation, compensates it afterward, and does nothing whatsoever against a subpoena — which is not a breach of contract but the law working as designed.

Above that, the compliance certification: SOC 2, ISO 27001, HITRUST. These audit whether the custodian follows its own procedures. They are audits of the custodian’s diligence — necessary, useful, and entirely beside the point, because the question was never whether the custodian is diligent. It is whether the custodian is capable of disclosure. Diligence bounds negligence; it does not bound capability.

At the top of the ladder is a different kind of claim entirely — not a promise but a property: the custodian cannot read the data, because the custodian never had the keys. No policy needs to be trusted, no contract enforced, no auditor believed. The claim can be checked the way an engineer checks anything: by inspecting what the system actually possesses. Compelling such a provider yields what breaching it yields — ciphertext.

The distance between the top rung and every other rung is the distance between “we promise not to” and “we are not able to.” Everything below the top is a variation of “trust us.” The top is “verify us” — an invitation to audit rather than a request for faith.

One question

You can evaluate any document system — a vendor’s pitch, an internal tool — with a single diagnostic:

Who can read this document without asking me?

Ask it honestly and the familiar landscape reorganizes itself:

• Email. Your provider, the recipient’s provider, every relay in between, and anyone who later compels or compromises any of them. Email is a postcard with delivery confirmation. Professionals who would never discuss a client’s finances in a hotel lobby attach them to email daily.
• Cloud drives and file-sharing links. The platform, wholly and by design — reading your files is how its features work. “Anyone with the link” adds exactly what it says.
• Client portals. The portal operator and its hosting stack. The padlock in the address bar authenticates the pipe, not the custody.
• Managed “secure file transfer.” The transfer operator — see MOVEit. Often marketed on the phrase this essay has been dismantling.
• End-to-end encrypted messengers. Genuine progress: for message content, the operator finally answers “not us,” and billions of people now hold keys on their own devices without knowing what a key is. But messengers are built for conversations, not documents — a file forwarded out of the chat leaves its protection behind; there is no per-document policy, lifetime, quorum, or audit trail; and the security is tied to the channel rather than carried by the artifact. End-to-end encryption solved custody for messages in transit between phones. The document — as a thing that persists, moves across systems, and outlives the conversation — is still an orphan.

The pattern across the whole list: the protections you have been sold are almost all protections of the channel or the premises — better locks on the custodian’s building. The custody itself was never on the table.

The honest cost

Fairness requires saying plainly why the world is built this way, because the reasons are not stupid.

Custody is what convenience is made of. The provider that can read your files can search them, preview them, thumbnail them, deduplicate them, virus-scan them, translate them, and summarize them with the model of the month. It can recover your account when you forget your password — the single most economically important feature in consumer software — precisely because it holds what you lost. Custody also concentrates responsibility in an entity with an IT department, which is often a rational trade: your dentist’s office probably should not run its own key infrastructure.

Give up custody and you give up pieces of that. A server that cannot read your documents cannot search inside them for you. A provider that never holds your keys cannot hand them back when you lose them; key loss becomes data loss, and that is not a bug in zero-knowledge systems but their defining bargain. Recovery, where it exists at all, has to be rebuilt deliberately — split among parties you choose, on terms you set, using the same cryptography that locked the door.

This essay will not pretend those costs away. A security architecture that hides its trade-offs is indistinguishable from marketing. The claim here is narrower and stronger: for the documents that matter — the medical record, the wire instruction, the term sheet, the whistleblower’s file, the evidence — the convenience of custodial reading is not a feature you are enjoying. It is a liability someone else is holding, priced in someone else’s breach.

Documents that defend themselves

So the problem, stated once and completely: the protection lives in the wrong place. It lives in the channel (TLS), in the premises (at-rest encryption), in the custodian’s promises (policy, contract, certification) — everywhere except the one place that travels with the data. The moment a document leaves any protected perimeter, it is naked; and documents exist to leave. They are sent, shared, forwarded, exported, backed up, subpoenaed. A document’s entire career is a tour of other people’s perimeters.

The alternative is to move the protection into the document — to make the artifact itself carry its encryption, its access list, its required quorum of openers, its lifetime, its lineage, and its proof of integrity, so that these properties hold on any server, over any channel, in anyone’s custody, because they are made of mathematics rather than of premises. The server’s role collapses to what a server is actually trustworthy for: storing bytes and moving them. An opaque blob is a fine thing to store and a safe thing to move; it makes no difference whether the custodian is diligent, breached, compelled, or acquired, because the custodian is holding ciphertext and was never given anything else.

That is the thesis. Taking it from slogan to specification is the work of a whole system — what such a self-defending document looks like as bytes, how a working implementation is built and verified, and how to run the surrounding infrastructure without becoming a custodian yourself. What every part of that assumes — and what no document format undertakes to solve — is that a recipient already holds a key of their own. Ordinary people, patients and clients and board members who will never generate a keypair on purpose, have to come by one somehow. That assumption deserves to be named at the outset, so that it is not mistaken later for something the format quietly handles.

The machinery matters, but it serves one sentence, and it is worth fixing in mind before any of it, because it is the top rung of the ladder and the answer to Lavabit’s court order:

“We cannot read your documents” must be a fact about the architecture, not a promise from the operator — provable by anyone, deniable by no one.

Everything else is detail in service of making that sentence true.

---

David Brown writes about zero-knowledge document systems. This essay is adapted from the book Cellular Defense*, which documents an open, browser-native document format built so that the answer to “who can read this without asking me?” is no one. The format is published in full as a defensive disclosure — timestamped, open to being broken — and you can see how it works or publish your own key.*