Demystifying Email Encryption

If you’re researching private email providers, you’ve probably seen terms like “end-to-end encryption (E2EE)”, “zero-access encryption” and “PGP” thrown around along with others. Often, it is assumed that readers already understand the nuances of these terms. It wasn’t until I started researching for my own degoogle process that I realized: There were some major gaps in my understanding.

This article is meant to help people who are on a similar journey – and might have similar knowledge gaps. It won’t be comprehensive – that would require something more book-like. Instead, my goal here is to help you navigate the topic of email encryption with a solid understanding of the main concepts – enough to help you choose the right provider for your needs without getting lost in the weeds.

So let’s start by clarifying some foundational concepts.

Essential Encryption Concepts

What Is Encryption?

The Wikipedia article on encryption defines it as the process of transforming information in a way that, ideally, only authorized parties can decode. In other words, an encrypted message is made unreadable and can only be made readable again when decrypted.

The Role of Keys

In modern email encryption, messages are often encrypted and decrypted using so-called keys. A public key (i.e. a key that is meant to be shared with others) is used to encrypt the message. The corresponding private or secret key is needed to decrypt the message.

What’s important to understand here is that while public keys are meant to be shared and accessed by anyone, encryption is only truly secure if the private keys are kept private – i.e. held in the user’s possession or only accessed/controlled by them.

Encrypted at Rest & Encrypted in Transit

These two terms describe encryption during an email’s two main states – when it is being sent (in transit) and when it is being stored on the provider’s servers (at rest). There is a third state, but we’ll get to that later.

For each of these forms of encryption (in transit & at rest), there are two levels of protection that differ primarily in their extent.

To unpack what I mean, let’s start by looking at encryption in transit.

Encryption in Transit

To get started, we need to understand the journey every email takes once sent:

With this now in mind we can break down the two different kinds of encryption in transit.

Basic Encryption in Transit (TLS)

Basic encryption in transit (which uses a protocol called TLS) involves encrypting and decrypting the connection across every “hop” (server/device) along the journey. This protects the email from being intercepted by unauthorized parties while being transmitted.

What is important to understand here is that the email itself is not encrypted with TLS. You can imagine it functioning like a special tunnel that is created just to send this one email and disappears once the email has successfully arrived. The contents of the email remain untouched throughout this process. This means that if the email was not encrypted before being sent, all servers/devices it travels across can theoretically read the full contents.

This form of encryption (TLS) is standard in the industry and is now nearly universally used.

End-to-End Encryption (E2EE)

True end-to-end encryption means the message is encrypted on your device before being sent on its journey and can only be decrypted when it reaches the intended recipient’s device. It remains encrypted across all three stages of the email’s journey.

This is a major upgrade from TLS, because it means neither the sending nor the receiving provider can read the contents. They simply act as delivery agents and would see only gibberish if they tried to access the contents.

We’ll talk about how to achieve E2EE a little bit further down. Now let’s turn our attention to encryption at rest.

Encryption at Rest

Encryption at rest describes how the email is protected when it is stored on the provider’s servers. Here, the difference between the two levels of protection is not about where the protection occurs, but how it is performed.

Basic Encryption at Rest

With basic encryption at rest, the email provider encrypts the data to be stored with their own keys. This means that they can decrypt and access the messages at will – whether for compliance purposes, government requests or to enable various features, such as searching or “smart reply” functions.

This, too, is standard in the industry and protects your data from unauthorized access – such as data breaches caused by hackers. Should hackers break into the servers, the data they steal is encrypted and therefore unreadable.

It does not, however, protect your mail from “authorized” access – access by the provider for what it deems are legitimate purposes.

Zero-Access (or Zero-Knowledge) Encryption

With this form of encryption, the email is re-encrypted before being stored on (and ideally before being sent to) the provider’s servers for storage. It is stored in this encrypted state and the provider has no way to access the unencrypted contents, because it has no access to your private key.

When paired with E2EE, you have the highest level of email encryption possible. An email sent and received using these forms of encryption can only be read by the sender and the recipient. No one else can read the contents (assuming the users have sole control of their devices – but that is another topic altogether).

Encryption Hierarchy

You can now think of email encryption as a spectrum:

The Uncomfortable Truth About Email Encryption

Now, if you’re like me – you read the article up to this point and felt pretty good. The explanations made sense, the conclusion seems clear: Find an email provider that offers E2EE and zero-access and you’re golden. Email encryption bliss achieved!

But you also might have read that list and thought: What about combinations like “E2EE with basic encryption at rest” or “TLS with zero-access encryption”? Do those combinations exist?

The answer is: Yes they do – and this is where things start to get a bit complicated.

What About Mixed Scenarios?

Let’s say I (as a Proton user) want to send an email to a friend who uses Gmail. Proton is a privacy-oriented provider that offers E2EE and zero-access encryption. Gmail provides only level 1 protections (TLS in transit and basic encryption at rest).

When I send a message to my friend, what level of protection does my email have?

To keep this example simple, we are going to assume I send a normal email without any optional protections (we’ll talk about those in a moment).

The entire journey breaks down as follows:

The same journey basically happens in reverse when my Gmail-using friend sends me a message.

If you felt a bit shocked reading that sequence from the third bullet onwards – you’re not alone. I’m not sure how I thought it worked, but seeing it spelled out made me go: How did I not know this before?!?

And so began my journey into the depths of email encryption.

The Three Paths to True E2EE & Zero-Access

At this point, you might be wondering if E2EE & zero-access are more hype than substance. But E2EE and zero-access are real – and offer real benefits.

There are actually three different ways to send emails with full E2EE/zero-access protection:

Let’s take a look at how each of these options works:

Emails within the same ecosystem
If you and your recipient use the same E2EE/zero-access provider, your emails never have to leave the ecosystem – and therefore retain their promised protection. Pretty straight-forward.

Compatible Encryption Methods
Most encryption methods use some form of public/private key encryption, like we discussed near the start of this article.

If both parties use the corresponding public key to encrypt their messages, only the person with the private key can decrypt the message and read its contents. Without that key, no one else can read the message.

There are (free!) programs available that can accomplish this with any email and any provider!

So why isn’t everyone using these magical tools? The short answer is: Because setting things up between the two (or more) parties is usually a bit finicky.

The tools require both parties to use compatible methods that are set up properly. This usually involves manually exchanging keys with each individual contact. The tools also often come with some notable limitations and risks: For instance, some do not work with mobile devices (meaning you cannot read or send any encrypted mails on such devices) and should you accidentally lose access to your key – you can never access your encrypted emails again.

Put it all together and – for most people – the effort isn’t worth it.

Password-protected Emails
Since most users are unlikely to be able to convince the majority of their contacts to either use the same provider or use a finicky encryption tool, privacy-focused providers usually offer more convenient alternatives for maintaining E2E/zero-access encryption when corresponding with contacts using other providers.

In most cases, this involves sending the recipient a link. This link takes them to a portal, where they must enter a password (you send this to them via other means or use a “hint” that only they would be able to answer). If they successfully enter the password, they enter a kind of temporary mailbox within the sender’s ecosystem. In most cases, they can reply to the message here and even add attachments.

This scenario is basically a way to recreate the environment of the first option. The email never leaves the sender’s ecosystem. Instead of downgrading the protections to successfully send the email to a non-compatible provider, the link gives your contact temporary access to your ecosystem.

So there are ways to achieve E2EE/zero-access even when using less secure providers or corresponding with someone who does. That’s the good news here. But we aren’t finished just yet. There are a few more details about encryption that are well worth knowing if you are looking to make the switch to a more privacy-oriented provider.

Where (and When) Does Encryption/Decryption Occur

To understand why this is important, let’s use Gmail as our baseline.

When Gmail encrypts user emails “at rest”, it uses a different approach than most privacy-oriented providers. You can think of it like this: Google stores email data inside a bank vault. Inside the bank vault are multiple safes. Inside each safe are thousands of locked boxes. And inside those boxes are your emails.

Thanks to that analogy, you might think: “That sounds really secure”. And you’d be partially right. It is really secure against outside access. Hackers are not likely to break through those multiple layers of security.

But when it comes to Google’s ability to access those locked boxes – they can do it practically instantaneously. Why? You might think its because they hold all the keys. And again – you’d be partially right. But having the keys is only one part of the equation. The other, more crucial part is having the ability to use them with no restraints. Indeed, their system is built to provide them with near unlimited access.

Gmail is in complete control of the encrypt/decrypt process. They do not need user involvement at any stage of the process. So to use the terms of this section’s heading: Gmail encrypts/decrypts on its servers and at any time it so chooses. From a privacy standpoint, this is not ideal (to state the obvious).

Now let’s contrast that approach with how privacy-oriented providers handle this “key” issue.

While each provider has its own model, they all start with the same basic approach. Each user generates (or is assigned) a pair of keys – a public and a private key (just as we’ve discussed before). Most also make the public key available to anyone who needs to use it (rather than you having to exchange it manually) – though this can vary depending on provider.

Where they tend differ more notably is in how the private key is stored, accessed and used for the encryption/decryption process.

There are two options for where the encryption/decryption process can take place:

With client-side encryption, the privacy and security benefits seem relatively obvious. If encryption and decryption happen on your device, the emails you receive are only decrypted once they reach your device, and likewise, when you send an email, it is encrypted before leaving your device. This ensures that the provider cannot access the unencrypted contents. As a result, this seems like the obvious winner. But as we will see, the decision may not be so clear-cut.

When it comes to server-side encryption, there is more variation in implementation. For one thing, the term server-side encryption can be used to describe anything from Google’s approach to that of some very privacy-oriented providers. So the range of potential meaning here is much greater.

What differentiates privacy-oriented providers from Gmail is how they have set their systems up: While Google uses their keys to ensure access to your email at any time, most privacy-oriented providers go to great lengths to limit their access.

The exact specifics can vary from provider to provider, but the most common version looks something like this:

Now, you might be reading this thinking: “Why on earth would anyone go this route? The other method is clearly superior!” That was my initial reaction as well – but I eventually learned that the truth is (as it often is) somewhat more complex.

Trust, Trade-offs and Other Tangents

So we’ve learned that privacy-oriented providers differ on the where of the encrypt/decrypt process, but they generally agree on the when. This is crucial: their models all require user involvement.

This is the core difference from Gmail: Google’s systems are built to provide them with access to everything at all times; privacy-oriented providers do the opposite – they build systems restricting their access to very narrow circumstances that generally require user involvement.

But why do some providers go the server-side route? What is the appeal, if it isn’t to read my mail?

While there are also some security/privacy considerations that can favor a server-side model (which would require us to get a bit too technical here), the main reason providers choose to go with the server-side approach is to maximize user convenience.

A Quick Detour to the Past

Email was originally built to send unencrypted, plaintext messages from one person to another. It was not built with security or privacy as a high priority. The systems and protocols that have grown up around it have had to maintain compatibility with this now relatively ancient technology.

What Email has Become

Email is massively popular and we have become accustomed to interacting with this technology in certain ways. Perhaps you use Thunderbird, Apple Mail or Outlook to read your emails. Or you like to use the search function to instantly find that email with Aunt Betty’s amazing recipe she sent you all those years ago. Or maybe you love the instant/smart reply feature.

Well, when you encrypt email, most of that stuff breaks. Using a third-party app to access your email requires IMAP – it breaks with E2EE. Searches require access to the unencrypted contents. Same goes for smart replies. Which means all of these providers that want to offer E2EE have to come up with workarounds – or tell you “sorry, we can’t do that”.

The Workarounds

Since most providers know that paying customers tend not to appreciate the second option, they try their darndest to find solutions. One of the simplest solutions is – you guessed it – server-side encryption. When a search request comes in, you are already logged in, which means your key is available for the provider to use. Its system can then perform any necessary decryption actions, execute the search and respond: Boom! Problem solved.

What does the workaround look like on the client-side, err, side? The emails have to be downloaded/stored locally, decrypted locally and searched locally. You can guess which of these workarounds provides faster results – the enterprise-level server or your daily-driver laptop (or phone).

Now, not everyone needs lightning fast search (or IMAP, or “smart” reply features). But if you are one of those people – server-side encryption starts to make a lot more sense.

Trade-offs in Both Directions

The fact that there are two options for handling encryption operations (client-side or server-side) means that prospective customers are faced with a choice: which approach makes the most sense for me?

Answering that question depends will primarily depend on what you value most.

Both approaches require at least some degree of trust in the provider. Client-side operations generally require less, but the difference between the two approaches isn’t necessarily as great as one might initially assume. Ultimately, it will depend on your specific needs/wants and how well the specific provider aligns with that.

Now, before we wrap things up, there is one last nugget that I learned while going down the encryption rabbit hole that I need to share. It is another aspect I had previously been aware of.

Metadata: Encrypted Email’s Achilles Heel

There is one aspect of encrypted email that (for the most part) is equal across most providers – and it is often under-reported.

Similar to postal mail, email needs certain information to function properly. With normal mail, you need to put a destination address and return address on the envelope along with a stamp. Email was built as a digital equivalent and follows the same principle.

The corresponding information needs to be visible to all “delivery agents” along the journey – i.e. the providers’ servers. As a result, this information cannot be encrypted.

What information are we talking about specifically?

This information cannot be encrypted in transit due to the way email functions. Theoretically, some of this information could be encrypted when at rest. However, a combination of legal requirements and technical difficulties mean that you can generally assume that even privacy-focused providers will keep this data unencrypted more or less permanently.

For most people, this is an acceptable trade-off. However, for people whose livelihood depends on a certain level of anonymity (journalists, whistleblowers, opposition leaders in certain countries), this information can represent a potential danger. If that is you – you should only use email as a last resort. There are usually better tools available (e.g. Signal).

Final Thoughts

Any privacy-oriented provider is miles ahead of Gmail when it comes to corporate surveillance and likely far better in terms of hindering government surveillance as well (but official details here are hard to come by). So don’t let the complexities of encryption hold you back from making a move – all privacy-oriented providers represent a giant step in the right direction!

This article only scratched the surface of email encryption. But I hope you now feel capable of sifting through the noise and better understand what you’re getting – and what you’re not – in terms of encryption when you choose your next email provider.

John @ Degoogle Your Life