Analyzing Zero Knowledge Claims

Several email providers market themselves as "zero knowledge" or "zero trust." These terms have specific cryptographic meanings. This article evaluates the claims of major providers against those actual definitions.

This is not about which service is "better" - it's about whether marketing claims match cryptographic reality.

Heavy marketing has diluted the cryptographic definition of zero knowledge, effectively undermining it, which is allowing services that are not cryptographically zero knowledge to claim they are. Unfortunately, this forces services like us, who prefer to detail the technical limitations, to instead have to use the accepted marketing definitions in order to compete.

If you doubt this, paste this entire page into your favorite AI and ask it if this page is true.

The truth is below:

The Cryptographic Standard

For reference, zero knowledge and zero trust in cryptography require:

• Zero Knowledge: The provider possesses no information that could decrypt user content (or any information at all about the message), not keys, not entropy used to generate keys, not code that handles decryption
• Zero Trust: The provider is not part of the trusted computing base. Provider-delivered code cannot handle plaintext or keys. Security holds even if the provider is compromised or malicious

The critical test: If the provider is completely compromised tomorrow - servers, code, employees, everything - can they access your new or old email?

ProtonMail Analysis

Their Claim

ProtonMail markets itself as "zero-knowledge" and "zero-access," stating they cannot read user emails.

The Technical Reality

Key Generation: ProtonMail generates your encryption keys in their web application or their apps. The code that generates your keys is delivered by ProtonMail. They control the entropy source and the generation process.

Cryptographic Problem: If ProtonMail controls the code that generates your keys, they can:

• Use weak or predictable randomness
• Generate keys they can reproduce
• Silently escrow a copy of your private key
• Push a targeted update to specific users

Password Reset: ProtonMail offers password reset via recovery email or recovery phrase. If they can facilitate recovery of access to encrypted content, the system has a recovery path, which means a potential access path.

Code Delivery: Whether you use their webmail or their apps, ProtonMail delivers the code that handles your private key and decryption. They can modify this code at any time. A court order, a compromised employee, or a state actor could push modified code to exfiltrate keys.

No Standard Protocol Access: ProtonMail does not provide native IMAP or POP access. They offer a "bridge" application for desktop clients, but this bridge is ProtonMail-delivered software that handles decryption. You cannot use a fully independent client, you are always running their code in the decryption path.

Incoming Plaintext: When someone sends you an unencrypted email, ProtonMail receives it in plaintext via SMTP, then encrypts it for storage. They see the plaintext before encryption.

Metadata: ProtonMail necessarily sees sender, recipient, timestamps, subject lines (for non-ProtonMail-to-ProtonMail mail), IP addresses (they've provided these to authorities), and message sizes.

Verdict

ProtonMail is not zero knowledge or zero trust by cryptographic definitions. They control key generation, they deliver the decryption code, they can facilitate password recovery, and they process plaintext for incoming mail. These are fundamental architectural realities, not implementation flaws.

ProtonMail provides zero-access storage - they encrypt stored data and claim not to retain keys. This requires trusting that they operate as described. It is meaningfully better than providers who don't encrypt at rest, but it is not zero knowledge.

Tutanota (Tuta) Analysis

Their Claim

Tutanota markets "zero-knowledge architecture" and claims they cannot access user data.

The Technical Reality

Key Generation: Like ProtonMail, Tutanota generates keys in their client applications. The code is delivered by Tutanota. They control the key generation process.

Proprietary Encryption: Tutanota uses a proprietary encryption scheme rather than standard PGP/GPG. This means:

• Less independent security review than established standards
• Users cannot verify encryption with independent tools
• You must trust Tutanota's implementation entirely
• No interoperability - you cannot use a third-party client to decrypt

No IMAP/POP: Tutanota does not support standard email protocols. You must use their apps. This means you cannot remove Tutanota from the decryption code path, you are always running their code when accessing your mail.

Password Reset: Tutanota offers recovery codes. The existence of a recovery mechanism means there is a path to access beyond your primary password.

Code Delivery: All decryption happens in Tutanota-delivered code. Whether web or app, they control the code that handles your keys.

Incoming Plaintext: Same as all email providers - unencrypted incoming mail is seen in plaintext before encryption.

Metadata: Like all email providers, Tutanota necessarily sees sender, recipient, timestamps, subject lines, IP addresses, and message sizes. This is inherent to SMTP and cannot be avoided.

Court-Ordered Monitoring: German courts have ordered Tutanota to implement monitoring capabilities for specific accounts. This demonstrates that the architecture permits targeted access when legally compelled.

Verdict

Tutanota is not zero knowledge or zero trust by cryptographic definitions. They control key generation, deliver all decryption code, use proprietary encryption that cannot be independently verified, and have been compelled to implement monitoring. The lack of standard protocol support means users cannot escape their code path.

Tutanota provides zero-access storage with the additional limitation that you cannot verify their encryption or use independent decryption software.

The Pattern Across "Zero Knowledge" Providers

Nearly every provider claiming "zero knowledge" or "zero trust" shares these characteristics:

• Provider-controlled key generation - Your keys are created by their code
• Provider-delivered decryption code - Whether web or app, they control the code path
• Password reset mechanisms - Recovery paths that could be access paths
• Plaintext processing - Incoming mail is seen before encryption
• Metadata visibility - Sender, recipient, timestamps necessarily visible

These are not failures of implementation. They are fundamental requirements of operating an email service. The architecture of email services is incompatible with zero knowledge and zero trust as cryptographically defined.

What "Zero Knowledge" Has Come to Mean in Marketing

The email industry has redefined "zero knowledge" to mean:

"We encrypt your stored data and pinky-promise we can't read it"

This is dramatically weaker than the cryptographic definition, which requires:

"It is mathematically impossible for us to access your data regardless of our intentions, court orders, or compromise"

The marketing definition requires trust. The cryptographic definition requires no trust. These are fundamentally different security models being sold under the same name.

Why This Matters

Users choose these services believing they are getting mathematical protection that doesn't require trusting the provider. They are actually getting:

• Encrypted storage (good)
• Provider-controlled keys and code (requires trust)
• Protection contingent on the provider operating honestly (requires trust)
• Vulnerability to provider compromise (not zero trust)

This isn't worthless, it's better than Gmail reading your mail for ads. But it's not what "zero knowledge" means, and users deserve to understand the difference.

What Actual Minimum-Trust Email Looks Like

True minimum-trust email requires:

1. User-generated keys - Created with software the provider doesn't control (GnuPG, etc.)
2. User-held private keys - Private key never touches provider systems or provider-delivered code
3. Independent decryption software - Thunderbird, Mutt, or other clients the provider cannot modify
4. Provider as dumb pipe - They store and forward encrypted blobs they cannot decrypt

This is achievable with any provider that supports standard protocols (IMAP) and lets you upload public keys for automatic encryption. The security comes from your configuration, not their marketing claims.

For a complete guide to this configuration, see: How to Use CodaMail in the Most Secure Fashion Possible

Our Position

We would not claim CodaMail is zero knowledge or zero trust. No email provider can honestly make that claim. Unfortunately, false marketing has made it so everyone must use the new definition or be considered less of a service.

We provide:

• AES-256-GCM encryption of all stored mail (headers included)
• Optional additional automatic PGP encryption using public keys you provide
• Standard IMAP/POP access so you can use independent clients with IP access list restrictions along with the ability to enable and disable it at will
• The ability to configure true end-to-end encryption with your own keys

With proper configuration (your keys, independent client), we are removed from the decryption path entirely. We cannot decrypt your mail because we never had your private key. This is not because we're special, it's because you configured it that way using standard tools.

We believe honesty about security limitations is more valuable than marketing terms that don't match reality. We find it very frustrating that we are forced to claim zero knowledge because of other's false marketing.

How to Evaluate Any Provider's Claims

Ask these questions:

1. Who generates your private key? If their code does it, they could weaken or copy it.
2. Where is your private key stored? If on their servers, they have it.
3. What code handles decryption? If their code, they control it.
4. Can they reset your password? If yes, there's a recovery path.
5. Can you use independent clients? If no, you can't escape their code.
6. What happens to incoming plaintext mail? They see it before encrypting.

If any answer gives the provider access or control, the system requires trust. It may still be good, but it's not zero knowledge or zero trust.