The Truth About Zero Knowledge / Zero Trust

There are a growing number of services outright branding themselves as "Zero Knowledge" or "Zero Trust." However, these labels carry very specific cryptographic meanings, and the services branding themselves with these labels stretch, dilute, or redefine them to fit their product. To understand why these claims don't hold up, we need to examine what zero knowledge and zero trust truly require, especially in the context of email.

The conclusion is unavoidable:

There is no such thing as a zero-knowledge or zero-trust email service. Not even us. These properties can only exist in the sender's and recipient's clients, never in the provider.

Let's break down why.

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 obtain plaintext or key material capable of deriving it.

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

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.

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, or quietly ordered to modify client-side code. 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 to redefine Zero Knowledge and Zero Trust. But cryptographically and technologically speaking, it is currently impossible with email, not without a complete fundamental redesign of the underlying email protocol.

Here's why:

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:

• sender
• recipient
• timestamps
• routing information
• message size

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, they can:

• weaken keys
• push a silent update
• inject a key-exfiltration routine
• modify JavaScript in webmail
• force a client to upload keys
• add logging
• remove encryption entirely under a warrant

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

This eliminates:

• webmail
• server-delivered JavaScript
• provider-distributed apps
• automatic updates controlled by the provider
• password-reset mechanisms dependent on the provider
• key recovery dependent on the provider

All common features of email services.

If the provider controls the code path, the user cannot trust it. And if the user cannot trust the code path, the system cannot be zero trust.

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:

• able to compromise servers
• able to modify software
• able to observe traffic
• able to be compelled legally
• able to be gagged from notifying users
• able to be infiltrated internally

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.

• Weak or biased RNGs can make keys guessable or reduce entropy to deliver practical attacks.
• Deliberate parameter weakening (shorter keys, predictable IVs/nonces, reused nonces) destroys cryptographic assurances even if algorithms are otherwise correct.
• Supplying or seeding RNGs from a provider-controlled source means the provider can reproduce keys or predict secret values.
• Compromised hardware RNGs or supply-chain attacks on cryptographic libraries can silently undermine security.

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:

• independent client-side key generation using verifiable, high-entropy RNGs
• client-side encryption and decryption with code the provider does not control and cannot alter
• client-side control and custody of private keys outside any software distributed by or controlled by the provider
• verifiable, reproducible, open-source crypto code and build process, again not involving provider distribution
• update channels controlled by users, not providers
• minimized, ideally encrypted or obfuscated metadata

The service's only acceptable roles are:

• a dumb store-and-forward transport for ciphertext
• a metadata-unaware blob carrier (to the degree possible)
• an untrusted intermediary with no ability to affect cryptographic operations

This means:

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

Any system where the provider is involved in encryption, RNG, key management, software delivery, 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:

• You do not trust the provider.
• You do not rely on the provider for security.
• You assume the provider can act against you at any time.
• Your privacy holds even if the provider is compromised and has their code completely rewritten by the attacker.

If your system fails these conditions, 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.

But ask yourself this when picking a provider: can you really trust one that lies in their marketing or attempts to redefine the specifications to fit their model rather than explaining how their model doesn't meet the specifications?