The Truth About Zero Knowledge / Zero Trust

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.

Protonmail and Tutanota market themselves as zero knowledge, but they generate keys, they control the entire encryption and decryption code paths, you cannot escape their software, and they receive email in plain text. This violates the cryptographic principles of zero knowledge and thus is not zero knowledge. So they changed the definition of zero knowledge and created a new definition that now only means "we pinky promise can't read your email" to match their offerings

Unfortunately, their heavy marketing has now defiled the actual definition of cryptographic zero knowledge and changed it to simply mean "we encrypt your mail and can't read it". This has forced services like us, who are purists, to have to call ourselves zero knowledge because we offer the same thing or be penalized in searches. We are actually closer to the cryptographic definition than they are, but would still prefer to define what zero knowledge actually means when email cannot meet the actual cryptographic definition.

We offer the same ease of use methods, but we are flexible and can be configured to offer even more; where we do not generate your keys, we only store your public key, never access your private key, and we are completely removed from the decryption code path. In this configuration, we don't need to "pinky promise", we are physically incapable of reading your encrypted mail, altering key generation, or altering any of the decryption software. This is much closer to the true meaning of zero knowledge.

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.

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.

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:

• 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 or private key generation, 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

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

This eliminates:

• webmail
• server-delivered JavaScript
• provider-distributed apps
• Progressive Web Apps (PWAs)
• automatic updates controlled by the provider
• password-reset mechanisms
• key recovery

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:

• 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 (Random Number Generators) 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 decryption, 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 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