End-to-End vs. Zero Access Encryption

The Mail Analogy: Postcards, Sealed Envelopes, and Security

When discussing email encryption, there are two important concepts that often get confused: end-to-end encryption (E2EE) and zero access storage encryption. Let's use the familiar postal mail system to understand the critical differences between these two approaches to protecting your communications.

The Unprotected Postcard: Email Without Encryption

First, let's consider standard, unencrypted email as a postcard sent through the mail:

• You write your message on a postcard
• You drop it in your mailbox, where your mail carrier picks it up
• The mail carrier can read your message
• It passes through the sorting facility, where workers can read it
• Another mail carrier delivers it to the recipient's mailbox, and they can also read it
• Finally, the recipient takes it from their mailbox and reads it

In this scenario, your message is completely exposed at every step of the journey. This is how standard email works. The content is visible to your email provider, potentially to network operators during transmission, and to the recipient's email provider.

SSL/TLS: Protection During Transit Only

When email providers implement SSL/TLS (the same as the padlock icon in your browser), it's like:

• You write your message on a postcard
• Your mail carrier puts it in a sealed envelope for transport
• At the sorting facility, they open the envelope to sort the postcard
• They put it in another sealed envelope for delivery
• The delivery mail carrier opens the envelope and puts the postcard in the recipient's mailbox

SSL/TLS only protects the message during transit between servers. Your email providers at both ends can still read the content. This is better than nothing, but your message is still exposed at the beginning and end of its journey.

End-to-End Encryption: The Sealed Envelope

True end-to-end encryption is like sending a sealed envelope through the mail:

• You write your message on paper
• You place it in an envelope that only the recipient has the key to open
• You seal the envelope with a special lock that only the recipient can unlock
• You drop it in your mailbox
• The mail carrier picks it up but cannot open the envelope
• Workers at the sorting facility handle the envelope but cannot read its contents
• The delivery mail carrier delivers the still-sealed envelope
• Only the recipient, with their unique key, can unlock and open the envelope

In E2EE, your message is encrypted on your device before it leaves, and it stays encrypted throughout its entire journey. Only the intended recipient, with their private decryption key, can decrypt and read the message. No one in between, not even the email service providers, can access the content.

This is a zero-trust model. You don't need to trust any third party with your message content. It's mathematically protected from the moment it leaves your device until it's decrypted on the recipient's device.

Zero Access Storage Encryption: The Protective Service

Zero access storage encryption is different, and works more like this:

• You write your message on a postcard
• You drop it in your mailbox
• Your mail carrier picks it up (and can read it)
• It travels through the postal system (where others can read it)
• When it arrives at the recipient's post office, a special service puts it in a secure lockbox
• The lockbox has a special lock that only the recipient can open
• The post office stores the lockbox until the recipient comes to retrieve it
• Only the recipient, with their unique key, can unlock the lockbox and read the message

With zero access storage encryption, your message may travel unencrypted (or with just SSL/TLS protection) but is encrypted before being stored on the recipient's server. The service provider applies this encryption and promises they don't keep a copy of the key, ensuring they cannot access the stored messages.

In its most common form, this requires some trust in the service provider. You're trusting that they correctly encrypt the message upon receipt and don't retain access to the decryption keys or make a copy before encryption. The provider could technically read the message before encrypting it for storage.

Not All Zero Access Storage Is Equal: Whose Key, and Who Decrypts

How much trust zero access storage actually requires depends on two things: whose key the message is encrypted to, and who controls the decryption. Those vary enough that the same label can describe very different trust levels.

In the weaker and more common form, the provider generates and holds the key, even if that key is itself encrypted under your password, and decrypts your mail for you through its own webmail or app. Here the provider sits in the decryption path, so you are trusting it on both ends: that it encrypts correctly on receipt, and that it never misuses the key it holds or the code it runs to read your stored mail.

In the stronger form, the provider encrypts your incoming plaintext mail to a public key you generated independently, holds only that public key, and is removed from the decryption path entirely. You decrypt later with your own software, using a private key the provider never sees.

Because the mail arrives in plaintext, the provider still glimpses it at the instant of receipt, so a thin slice of trust remains on the encryption side. But on the decryption side there is nothing left to trust: the provider cannot read what it has stored, even if compelled, because it never holds the key. For messages that arrive already encrypted, the provider has no part to play in the cryptography at all.

This stronger form is what we mean by genuinely zero-access after-the-fact encryption. It is not full end-to-end encryption, because the provider is still in the encryption-on-receipt path, but it removes the provider from the decryption path, which is the half that matters most. The distinction is covered in detail in The Truth About Zero Knowledge / Zero Trust / Zero Access.

Requirements for True End-to-End Encryption

For email to be truly end-to-end encrypted, several strict requirements must be met:

• Compatible encryption standards: All participants must use compatible encryption tools (like PGP/GPG or S/MIME)
• Proper key generation: Encryption keys must be securely generated using your choice of compatible software
• Sender exclusivity in encryption: The sender must be the only party involved in encrypting the message, using the recipient's public key
• Key exchange: Recipients must have securely shared their public keys with senders beforehand
• Persistent encryption: The message must remain encrypted throughout its entire journey, during transmission and storage
• Client-side decryption: Decryption must only happen on the recipient's device, using their private key that never leaves their control
• Provider-independent software: The tools that generate your keys and perform the encryption and decryption must not be supplied or controlled by the email provider. A provider's own servers, webmail, mobile app, or browser extension, including Progressive Web Apps, can be silently updated, so encryption running inside provider-controlled code may still be end-to-end in form, but it can never be trustless end-to-end. You would be trusting the provider's code rather than the protocol, and that code can be changed at any time to capture your keys or your plaintext.
• No third-party access: No intermediary should have any kind of access to the private key or the encryption or decryption process at any point

When any of these requirements is compromised, the communication is no longer trustless end-to-end encrypted. For example, if the email service handles any part of the encryption process and has access to the private keys, it's not trustless E2EE because a third party has potential access to the unencrypted content. The same is true when you rely on the provider's own app or webmail to encrypt or decrypt. Even when the cryptography runs on your device, code the provider can change at any time is not a trustworthy place to handle your keys or your plaintext, so this is the provider's app you are trusting, not the protocol.

The Trust Factor: Key Differences

The fundamental difference between these encryption approaches comes down to the trust model:

• End-to-End Encryption: Based on a zero-trust model toward the email provider and the network. You don't need to trust them because the security is mathematical and only the participants holding the keys can read the content. One condition makes this real: the key generation, encryption, and decryption must be done with software independent of the provider. If the provider supplies the E2EE code or generates the keys, the math is still sound, but you are back to trusting the provider rather than the protocol, which is no longer zero-trust.
• Zero Access Storage Encryption: Requires some trust in the service provider, but how much depends on the variant. Incoming mail arrives in plaintext, so the provider sees it at the moment of receipt no matter what, and encrypting it to a public key is harmless in itself because the message is already plaintext. What you are actually trusting is:
  • That they encrypt the stored message as promised
  • That they don't quietly keep a plaintext copy after receipt
  • That they have implemented their systems securely
  In the weaker variant you must also trust them with the key that decrypts your mail. In the stronger variant, where the message is encrypted to a public key you generated and the provider stays out of the decryption path, that concern disappears, because the provider never holds a key that can decrypt your stored mail.

This distinction is crucial when evaluating security claims from email providers and other communication services. True zero-trust end-to-end encryption doesn't require you to trust the provider's promises. The security is built into the protocol itself.

Keep in mind, though, that the trust in zero access storage is not all-or-nothing. As described above, encrypting to a public key you control and keeping the provider out of the decryption path removes the decryption-side trust entirely, leaving only the brief moment of receipt when the mail is still plaintext.

Standards-Based vs. Proprietary Encryption

Another important consideration is whether the encryption is based on open, widely-reviewed standards or proprietary systems:

• Standards-based encryption (like PGP/GPG or S/MIME):
  • Independently verified by security experts
  • Interoperable across different services and applications
  • Not tied to any single provider or platform
  • Transparent security properties
• Proprietary encryption:
  • Security claims may be harder to verify
  • Often works only within a specific ecosystem
  • May create vendor lock-in for your encrypted data
  • Security depends entirely on the provider's implementation

Standards-based encryption is generally preferable because it allows for greater interoperability and independent verification of security claims.

Key Takeaways

• End-to-end encryption protects messages from the moment they leave your device until they're decrypted by the recipient. No one in between can read them. It's a zero-trust model where the sender is the only party to the encryption process using the recipient's public key and the recipient being the only party with any kind of access to the private key and decryption process.
• Zero access storage encryption keeps messages encrypted while they sit on the server. Because incoming mail arrives in plaintext, the provider sees it at the moment of receipt regardless, then encrypts it for storage. How much you must trust the provider depends on the variant: if it generates and holds the key and decrypts for you, you are trusting it on both ends; if it encrypts to a public key you generated and stays out of the decryption path, the decryption-side trust goes away entirely, leaving only the brief moment of receipt.
• SSL/TLS only protects messages during transmission between servers but leaves them readable by email providers.
• True E2EE requires compatible encryption standards (like PGP or S/MIME) used by all participants. True E2EE doesn't require you to use any specific e-mail service at all, zero trust means you could post the message publicly and it would still be secure.
• Standards-based encryption provides better interoperability and transparency than proprietary systems.

Understanding these differences helps you make informed choices about how to protect your digital communications based on your specific security requirements and risk profile.