The Truth About Zero Knowledge / Zero Trust / Zero Access

Zero Knowledge Email Is Off the Table

Zero knowledge, in the strict cryptographic sense, is simply impossible for any email system, and this has nothing to do with how scrupulous a given provider is. The protocol itself exposes a stack of metadata that travels in the clear no matter what you do to the body: the To address and the From address, the full delivery path stamped into the headers as the message hops from relay to relay, the Message-ID, the size of the message, and the exact time and date it was sent and received, down to the time-zone offset stamped into the Date header. None of that is optional in SMTP; the mail cannot be routed without it.

On top of the routing essentials, the sending client typically volunteers more on its own: an X-Mailer or User-Agent header naming the mail software and its version, the originating IP address recorded in the Received chain or an X-Originating-IP header, and content headers such as MIME-Version and Content-Type that hint at how the message was composed. And every one of those fields is, by definition, knowledge, the provider knows who you are talking to, who is talking to you, how often, from where, at what hour, on what device and software, and how large each exchange is.

Metadata alone is routinely enough to reconstruct relationships, communication patterns, and behavior, so even a provider that genuinely cannot read a single word of your message body still holds a detailed record of your correspondence. A system that knows all of that is not, and cannot be, zero knowledge. That is the end of the zero-knowledge conversation for email; the term cannot legitimately apply.

That said, there is a real difference between a provider that lets all of this leak and one that fights it. Most mail clients quietly attach the worst of it for you, your X-Originating-IP, your User-Agent and X-Mailer strings, read-receipt requests, and dozens of other identifying headers ride along with every message you send, telling the recipient your location, your device, and your software.

We strip more than 35 of those headers from every outgoing message at the server level, including the IP, mailer, and read-receipt headers. Because the stripping happens on our servers rather than inside any particular app, it works with whatever client you choose, Thunderbird, Apple Mail, Outlook, a phone's stock mail app, or our own webmail. The headers are removed after the message leaves your client and before it reaches the recipient, so the leak is closed no matter what you send with, and you can still keep, add, remove, or change headers to taste.

That dramatically shrinks what a recipient and the relays in between can learn about you. What it cannot do is erase the envelope itself: the To, the From, the routing path, the timestamps, and the message size are what actually move the mail, so some irreducible knowledge always remains. Stripping the leaks is a large privacy win; it is still not, and can never be, zero knowledge. The rest of this article is about the two properties you can actually demand and verify: zero trust and zero access.

E-mail can never be zero knowledge because it must contain knowledge for it to be able to be delivered.

It Is Never 100% Once the Provider Joins the Path

The cleanest way to understand zero access is to ask when encryption stops being absolute. It is not 100% the moment the service becomes part of the cryptography path in any way at all, and it is not 100% the moment the service generates or stores your private key, even if that key is encrypted. Public key cryptography was designed from the ground up to treat the provider as an adversary, an entity that must never, under any circumstances, have access to your plaintext or your private key. That is the entire point of the design. The asymmetry exists precisely so that the party moving your mail can be hostile and still learn nothing about the content.

What the marketing-driven services have done is bolt convenience onto that model. They generate the keys for you, they hold an encrypted copy so you can recover it, they run the encryption and decryption inside their own webmail or app. Every one of those conveniences is a real trade-off, because each one pierces the veil of true zero access. The system stops being trustless and quietly becomes trust us. You are no longer protected by mathematics; you are protected by a promise that the provider operates the way it claims to, and you have no way to verify that promise from the outside.

Cryptography is about trusting the math, not the provider.

How "Trust Us" Encryption Usually Works

It helps to see the actual mechanics, because they are less impressive than the branding. When one of these services needs to deliver an "encrypted" message to a recipient who isn't using encryption, it almost always does one of two things. The first is to email the recipient a link back to the provider's own website, where they log in and read and reply on the provider's pages. The second is to send a password-protected blob, or a link to one, that the recipient unlocks with a password shared through some separate channel. Conceptually that second case is no different from encrypting a file with a passphrase and telling the other person the passphrase, the same thing a tool like 7-Zip does, only usually with AES-256.

And it is still trust-us encryption even when the encryption and decryption happen in the browser through the WebCrypto API, because the provider wrote and serves that code, and in the website case it handles your plaintext directly.

The same trust-us shape shows up closer to home, in how you read your own mail. When a provider stores your mailbox encrypted but then decrypts it for you, through its webmail, its app, or a private key it holds on your behalf and unlocks with your password, the provider is sitting squarely in the decryption path. This is not just about the messages you send to outsiders; it is everything you receive and read.

Whatever code performs that decryption, whether it runs on the server or in the client the provider serves you, can capture the plaintext, the password, or the key at the moment it is used, and you are once again trusting that it does not. A mailbox you can only open through software the provider controls is trust-us encryption, no matter how the storage is described.

There is nothing inherently wrong with trust-us encryption. For most people it is a genuine improvement over encrypting nothing at all, and plenty of reputable services offer it in good faith. The problem is the marketing. When a service sells this as Zero Knowledge (which is impossible in email), as Zero Access, or as Trustless, or simply phrases things so the user walks away believing that, it has crossed from a useful convenience into a false promise.

People then genuinely believe they are completely anonymous and that the whole arrangement is trustless, when it is neither. Anonymity in particular is a separate problem that message encryption does not solve at all; it takes additional tools such as Tor, and no amount of "encrypted" branding substitutes for them.

Zero Trust Means Treating the Provider as the Adversary

Zero trust is a threat-model requirement, not a slogan and not a moral judgment about any particular company. It says that code controlled by the adversary cannot be part of the trusted computing base, and that the adversary you must plan around is the provider itself. Providers can be compromised, coerced, legally compelled, hacked, quietly ordered to modify their own code on either the client or the server, or betrayed by a single disgruntled employee. The moment the provider can update, modify, or inject the code that handles your plaintext or your keys, the system fails the test.

This is a danger with any provider-controlled code, and it is especially acute with Progressive Web Apps, which are really just a live browser tab dressed up as a standalone application and can be changed dynamically at any time.

Once you accept that the provider must be treated as hostile, the conclusion writes itself. The provider cannot simultaneously be the adversary you are defending against and the party guaranteeing your safety. That responsibility has to live entirely in the endpoints, in the sender's and recipient's own software, because nothing the provider controls can be trusted by definition.

Zero Trust - The definition is right in the name.

Why You Cannot Outsource Zero Trust to a Provider

Some providers publish long, impressive-sounding documents that perform a kind of cups-and-balls routine with authentication, encryption, decryption, and key management in order to claim zero trust anyway. But those same providers control the entire key generation, key storage, encryption, and decryption code. That is everything, and all of it can be modified by them to do anything they are forced or want to do with it.

If the provider controls your encryption or decryption software, or your private key generation, it can weaken your keys, push a silent update, inject a routine that exfiltrates your key, modify the JavaScript in webmail, force a client to upload keys, quietly add logging, or remove encryption entirely.

Any ability whatsoever to influence the cryptographic code breaks zero trust instantly, which is why it rules out webmail that depends on the provider's own served code for encryption, along with server-delivered JavaScript, provider-distributed apps, Progressive Web Apps, provider-controlled automatic updates, password resets, and key recovery, in other words nearly every feature people expect from an email service.

An independent browser extension such as Mailvelope is the exception that proves the rule: its code and your keys live in the extension rather than in the provider's pages, so it can perform genuine client-side encryption inside a webmail tab. That is exactly why webmail without something like Mailvelope is ruled out, while webmail with it is not.

There is one failure mode underneath all of that which often goes unnoticed: randomness. The provider, or any code the provider controls, can supply weak or biased random number generation, deliberately weakened parameters such as shorter keys or reused nonces, or randomness seeded from a source the provider can reproduce.

Because key strength rests entirely on the quality of that randomness, a provider that can influence it can break confidentiality without ever touching a plaintext code path, and compromised hardware generators or supply-chain attacks on cryptographic libraries can do the same damage silently. Any provider influence over randomness or key material is fatal to the claim.

One distinction keeps this from contradicting what comes later. What breaks the claim is provider control over anything that can expose your plaintext or your private key: key generation, key storage, the decryption path, and the software you yourself use to encrypt or decrypt. It is not provider involvement in encryption as such.

A provider that encrypts your incoming plaintext messages to a public key you generated independently is relatively harmless, because the mail is already plaintext when it arrives, the encryption step needs only the public key, and it cannot be undone without the private key the provider never holds. However, this is still trust based in that you trust they are not duplicating the plain text mail. It is the trust side of trustless after-receipt encryption described below: the provider can sit in the encryption-on-receipt path while staying entirely out of the decryption path, which matters all the more for messages that arrive already encrypted, where it has no part to play in the cryptography at all.

A provider cannot guarantee zero trust if you must trust that they operate as they say they do.

Why the Usual Reassurances Don't Hold

When the claims are challenged, the defense usually comes down to a few familiar arguments. They sound convincing, and they all fall apart under a little weight.

"The source is open, anyone can audit it"

What gets published is the client source code. What is not published is the live server setup and its configurations that actually handle your account, and the server is the part that matters. Thunderbird publishes its source too, and that does not make every email service on the Internet trustworthy simply because you use Thunderbird. Beyond that, did you personally read the entire client, understand it, and compile it yourself? If not, you are trusting that someone else did, and that the binary you installed matches the published source with nothing slipped in at build time.

And every open-source email client ever written has shipped vulnerabilities that had to be patched; Thunderbird has had a long list and will have more. If you have never once seen this provider publish a vulnerability and a fix for its own client, it is worth asking how a single company manages to produce flawless software that nobody else on the Internet can, especially while relying on the very libraries that have had vulnerabilities of their own.

"It has been independently reviewed, and they said they couldn't produce messages"

History has already run this experiment, and its name is Crypto AG. Crypto AG was a Swiss manufacturer of encryption machines, trusted for decades, independently examined by neutral experts, sold as effectively unbreakable, and headquartered in a celebrated "privacy country." The company maintained that it could not produce its customers' messages. In reality it was secretly owned and run by the American CIA and the West German BND, with Swiss authorities aware of the arrangement by the 1990s. It was backdoored from the beginning and used to read the supposedly secure communications of more than 120 countries for nearly half a century, from 1970 until the operation was finally wound down in 2018.

The lesson is uncomfortable but simple. An operation that has been compromised will never announce it; it will insist it cannot produce messages, which is exactly what a legitimate service would also say, so the statement proves nothing on its own.

Where a government is involved the script is the same and the cover is usually better. The most effective move of all is public frustration: when officials loudly complain that they cannot get into a particular service, that it is "going dark" on them and putting messages beyond their reach, the service instantly looks unbreakable and trustworthy.

That complaint is free marketing, and it is exactly the cover an intelligence agency would want for a service it secretly runs. The louder it grumbles in public that it cannot read a given service, the more users flock to that service believing it must be safe. Layer on advertising at a scale no ordinary company could fund and quiet pressure to make competitors look less trustworthy, and the disguise is complete.

"We were independently reviewed" and "we told them we couldn't comply" are not evidence of safety. They are designed to fabricate trust.

What True Zero Access Looks Like

True zero access inverts the convenience model entirely. You generate your own keys yourself, using software that is not connected to the provider. You encrypt using software that is not connected to the provider. Your recipient decrypts using software that is not connected to the provider, with a private key that has no possible path of access to anyone but the recipient.

At no point in that chain does the provider have an opportunity to act, which is exactly why it never has to be trusted: it is never part of the cryptography path at all. The most it ever holds is a public key, which is designed to be public, and a public key alone cannot decrypt anything.

The catch is that this requires third-party, open-source client and key-generation tools that are completely independent of the provider, and that is not as easy as logging into a webmail tab and typing. There is the trade-off again, stated plainly: convenience is the thing you pay trustlessness for. The more the provider does on your behalf to make encryption effortless, the more of the cryptography path it has to occupy, and the more "trustless" decays into "trust us."

Trust nothing but the encryption you personally execute using your choice of software on your own computer.

The Realistic Middle Ground for Email

Email has one stubborn property that no provider can change: nearly all of it arrives in plaintext. Because of that, it is genuinely desirable to have mail encrypted the moment it is received, so that it lives on disk as ciphertext rather than as readable text. Encrypting on receipt does mean the provider sees the plaintext at that one instant, which is unavoidable for inbound mail, but it gets stored encrypted from then on.

Given that reality, the strongest practical posture is to remove the provider from the decryption path completely. If the provider encrypts incoming mail to your public key and has no access to your private key, then at most it ever holds the public key, and there is no way for it to decrypt after that encryption has happened.

Even if it were compelled to backdoor its own servers, the stored mail would remain unreadable to it, because a provider kept out of the decryption path has no client of its own for you to be running: you decrypt with independent, open-source software of your own choosing.

That might be Thunderbird with its built-in OpenPGP or the Mailvelope browser extension on Windows, macOS, or Linux; Evolution, KMail, or Claws Mail on Linux; GPG Suite alongside Apple Mail on macOS; Gpg4win and Kleopatra on Windows; K-9 Mail (now Thunderbird for Android) paired with OpenKeychain on Android; or a tool such as PGPro on iOS. None of it is distributed or controlled by the provider, so there is nothing on your end for it to tamper with.

This matters not only for the after-receipt encryption the provider performs, but even more for messages that arrive already encrypted to you: a provider kept out of the decryption path cannot read those either, no matter what it is later ordered to do. That is about as close to zero access as after-receipt email encryption can get. You no longer have to trust the provider on the decryption side at all, even though you do still extend it trust on the encryption side, since it is the one performing that initial encryption on receipt.

This is not the same as true end-to-end zero access, and we will not pretend it is, but it is the most realistic option for a protocol that hands every message to the provider in the clear, and it asks for far less trust than the "we hold your keys and decrypt for you" model that dominates the market.

If You Take Encryption Seriously

For anything you consider seriously sensitive, the safe rule is to trust no service with the cryptography itself. Keep the provider out of the path entirely: let it encrypt your incoming mail on receipt if you like, since it arrives in plaintext anyway, but make certain it is no part of the decryption path.

Now that you know what the terms mean, is your provider promising you the impossible? If they use the term Zero Knowledge for email, they most certainly are. If they use the term Zero Trust, yet are handling all of the encryption and decryption for you and you have to use their software, they most certianly are. If they use the term Zero Access, yet their software or webmail does the decryption, they most certainly are.

If a provider is promising you the impossible, what are you trusting?

Follow-up: How to use CodaMail encryption with the least amount of trust possible for an email system