The Truth About Zero Knowledge / Zero Trust

Why these properties can only exist in clients, never in providers

There is no such thing as a true zero-knowledge or zero-trust email service, the limitations of the email protocol, itself, ensures that no mail service can be zero knowledge.

Many services market themselves as "zero knowledge," but they generate your keys, control the entire encryption and decryption code path, lock you into their software, and receive email in plaintext. This violates the cryptographic definition of zero knowledge, so they simply redefined the term to mean "we pinky promise we can't read your email."

Unfortunately, their heavy marketing has muddied the waters. "Zero knowledge" now commonly means little more than "we encrypt your mail and say we can't read it", what should properly be called zero-access storage (even though many of these providers still control key generation and decryption, which turns that specific "zero access" into a pinky promise). This forces purists like us to adopt the same diluted terminology or disappear from search results. We're actually closer to the cryptographic definition than they are, but we recognize that email can never fully meet that standard.

We offer the same ease-of-use features, but with far more flexibility. In our most secure configuration, we don't generate your keys, we store only your public key, we never access your private key, and we're completely removed from the decryption code path. We don't need to pinky promise anything, we're physically incapable of reading your encrypted mail, tampering with key generation, or altering decryption software. That's as close to true zero knowledge as email can get.

This method can be used with others to achieve the same minimal trust placed in the provider, our architecture is based upon standards, other standards based services can certianly be utilized in similar ways.

Zero Knowledge and Zero Trust are properties that can only exist in the sender's and recipient's clients, never in the provider.

What Zero Knowledge and Zero Trust Actually Mean

Zero knowledge and zero trust are not marketing slogans. They are strict architectural rules established by decades of formal cryptography research. For an email system to legitimately claim these properties, it must uphold all of the following:

A) Only the sender and recipients may ever access plaintext.

No one else - not the provider, not the infrastructure, not the network - may ever even possibly obtain plaintext or key material capable of deriving it (ie. your private key).

B) Code controlled by the adversary cannot be part of the trusted computing base.

This means the encryption and decryption logic must be entirely outside of the provider's (adversary's) control. The moment the provider can update, modify, or inject code that handles plaintext or keys, the system no longer meets zero trust or zero knowledge.

This is true with any provider controlled code, but is especially a concern with PWAs (Progressive Web Apps). These "apps" are basically just a live browser tab disguised as a stand-alone app, if these are used the code can be dynamically changed.

C) In a zero-knowledge/zero-trust email model, the provider is the adversary.

This is not a moral judgment. It's a threat model requirement. Providers can be compromised, coerced, compelled, hacked, quietly ordered to modify client-side code, or even simply face a disgruntled or unethical employee. Therefore, the security model must treat them as hostile.

When you combine A, B, and C, the conclusion becomes extremely clear:

A provider cannot guarantee zero knowledge or zero trust because the provider must never be trusted in the first place.

Why No Email Provider Can Deliver Zero Knowledge or Zero Trust

Most people assume that a sufficiently clever provider could build "true" zero knowledge or zero trust email. Some providers publish long documents using some variation of the cups and ball trick or a three card monty trick with authentication, encryption, decryption, and key management to redefine Zero Knowledge and Zero Trust.

However, these same providers control the entire key gen, key storage, encryption, and decryption code. That's everything! And it can be modified by them to do anything they are forced to do with it.

Zero Knowledge Requires the Provider to Know Nothing - But Email Providers Must Handle Something

Even if content is encrypted, traditional email protocols inherently expose metadata:

Metadata is not optional in SMTP. And metadata is often enough to reconstruct communication patterns, relationships, and behaviors; information that contradicts the spirit of zero knowledge.

Even if the provider cannot read the body, they still gain knowledge.

Zero Trust Means the Provider Cannot Be Part of the Trusted Computing Base - But Providers Deliver the Code

If the provider controls your encryption/decryption software or private key generation, they can:

Any ability for the provider to influence cryptographic code breaks zero trust instantly.

This eliminates:

All common features of email services.

If the provider controls the code path, the user cannot trust the code.

The Provider Is Always the Adversary - Therefore the Provider Cannot Also Be the Protector

In true zero-knowledge and zero-trust models, the adversary is assumed to be:

Since the provider is the adversary, the provider cannot simultaneously be the party guaranteeing privacy.

That responsibility must reside exclusively in the endpoints.

Substandard Randomness and Deliberately Weakened Keys

This is a critical, often-overlooked failure mode: the provider (or code the provider controls) can supply or force poor cryptographic randomness or deliberately weaken key generation and storage.

Because key strength and randomness are foundational to all cryptography, any provider influence here is fatal to zero knowledge/trust claims. If the provider can control or influence randomness or key material, the provider can trivially break confidentiality without touching plaintext code paths.

Zero Knowledge and Zero Trust Can Only Exist in Clients

A true zero-knowledge/zero-trust email architecture requires:

The service's only acceptable roles are:

This means:

Zero knowledge and zero trust are properties of the client, not the provider.

Any system where the provider is involved in encryption (unless public key), decryption, RNG, private key management, software delivery, email delivery via SMTP, or identity recovery cannot meet these definitions.`

And since every email service necessarily controls at least one of those variables, no service can honestly claim to be zero knowledge or zero trust.

Why These Definitions Matter

Users are being told they can outsource zero trust / zero knowledge email. Cryptography makes clear that they cannot.

Zero knowledge and zero trust mean:

If the system fails these conditions, and every email service does, it is not zero knowledge or zero trust, no matter what the marketing says.

This does not mean the system is worthless; a provider can still provide privacy and even zero access after-the-fact encryption, it is simply trust based privacy. You trust that the provider operates as they say they do.

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

← Back to Blog