How to make e-mail encrypted for everyone

Update: This post is a little naive. For the real deal, look at this video from the CTO of ProtonMail:

When you send an e-mail today it’s sent in plaintext. This means that when you connect to your local coffee shop’s WiFi they can intercept all e-mail that is sent through their router. This is probably not the relationship you have with your barista…

E-mail is way more important than this, and should receive the same privacy protection as the web has with HTTPS. I haven’t seen any meaningful progress on e-mail encryption in a long time, so this article is a suggestion of how to get things moving.

The base idea is this: We should make e-mail work just like the web in terms on encryption:

  • Encryption should be added gradually, without breaking backwards compatibility (interoperability)
  • Intermediate servers shouldn’t be able to read the message (privacy)
  • Users should be able to keep sending and receiving e-mail like they always have (usability)
  • E-mail clients and e-mail providers should be able to easily implement the scheme (simplicity)

Encrypt as much as possible of the e-mail message

For web traffic, we’ve encrypting everything except the domain name of the site we’re connecting to, this is how e-mail should work too. Since we need to know who to send the e-mail to, we should encrypt everything except the recipient address.

Some of you might have read about STARTTLS, a way to make SMTP encrypted. Unfortunately STARTTLS has several problems that makes it unfit to solve the privacy problem:

  • It only encrypts the message between the many servers your e-mail passes through. Your e-mail is decrypted and exists in plaintext on each of the intermediate servers. If any of the intermediate servers is hacked they get full access to all e-mails passing through. You likely don’t have that kind of relationship with your ISP network administrator either…
  • If any of the intermediate servers doesn’t support STARTTLS, the connection is downgraded to plaintext instead. One old server and the whole chain breaks.

We should apply encryption on the client when sending, and decrypt at the recipient. No intermediate servers should get access to the message.

Encrypt with public-key cryptography (without the hassle)

The best way to handle this encryption is with public-key cryptography, where the sender first fetches the public key of the receiver, sends the message encrypted with that key, and then that the receiver decrypts it using their private key.

People are already sending e-mail this way with PGP, so way not just use this everywhere? It has several big usability problems:

  • You need to do key management yourself. On the web the browser handles all cryptography for you. You  type the address in the browser and everything just works. This is not the case with PGP. Look at this guide in the eyes of a normal person: OpenPGP for a complete beginner – it quickly goes into downloading zipfiles, package managers and using the command line to generate keys.
  • You need to install software on your computer. Most e-mail providers are moving to the web, having to install a browser plugin just to send e-mail is not the experience we should strive for. I understand that this is means your e-mail provider can read your e-mail, so it won’t work for everyone. But I think most people will accept that the same way they accept that their bank can read their bank statement. If we can trade this for usability it’s still a HUGE step up for privacy.

Here’s how this could be done differently:


  1. For each recipient in the To, Cc, and Bcc fields:
    1. Do a lookup against their domain to see if it supports encryption. This should be a new DNS record that points to an address that the e-mail client can use to fetch the public key for a specific user of that domain.
    2. Fetch the public key for each of the users of the domain
    3. If both the domain has encryption support and the public key can be fetched, show a lock symbol beside that e-mail address to show that the message to that recipient will be encrypted. Clicking the lock can show information about the encryption that will be used, just like browsers do today.
  2. When the message is sent, split it into as many parts as the number of recipients and encrypt each part with that recipient’s public key. Send it off to each recipient using the normal protocols. Users on domains that don’t support encryption will get messages sent in plaintext, just like today. This ensures support can be added gradually.

Note that for the user nothing changes compared to how they send e-mail today, except that the lock shows up. Web users are slowly learning about the importance of the lock symbol when browsing the web, transfering that knowledge to e-mail too will create a push for e-mail server operators to support encryption.


  • When the encrypted e-mail reaches the intended recipients e-mail server, that server uses the private key for that user to decrypt the message and (securely) deliver it the the users inbox. The user reads their e-mail like they’ve always have.

Some may frown reading that I suggest leaving the private key in the hands of your e-mail provider. I agree that this means you lose some privacy to your e-mail provider. The upside here is that we gain a lot of usability. An e-mail provider (such as Gmail) could and an e-mail client (such as Thunderbird) could update all their software tomorrow and all e-mail sent from Thunderbird to Gmail would be instantly encrypted. This removes the burden of normal users to learn about cryptography to be safe on the web.

In summary, these are the changes that needs to happen for e-mail move towards being encrypted by default:

Consequences for e-mail clients

  • New features needed:
    • Fetch a DNS record for each receiving domain they want to send an e-mail to
    • Fetch each receiving user’s public key in the background
    • And encrypt as much as possible of the outgoing e-mail
    • Send the e-mail using the normal protocols
  • Ways to pitch this to users:
    • All e-mail sent to e-mail providers that support this scheme will be encrypted by default, with no effort on your part
    • You can easily see which addresses get encrypted messages with the lock icon that you know from browsers
    • Increased privacy from prying eyes

Consequences for e-mail providers

  • New features needed:
    • Add a DNS record that points to their public keys
    • Serve the public key of a specific user that the e-mail clients ask for
    • Decrypt incoming e-mails using the private key of that user
    • Deliver the e-mail using the normal protocols
  • Ways to pitch this to users:
    • All e-mails sent from clients that support this scheme will be encrypted by default, with no effort on your part
    • Increased privacy from prying eyes, do you really trust your local coffee shop as much as your e-mail provider?
  • Business reasons:
    • Support privacy without letting go of the chance to serve ads based on the content of the users e-mails. This is a very important point for big players like Gmail that serve ads. Users or course still have the option to use another e-mail provider or add PGP if they want.
    • Nothing in this scheme blocks smaller players from making their users safe using the same methods as the big players will.

In summary

I think this is a very straightforward way to make all e-mail encrypted. If anyone has a better suggestion that balances the needs of users, e-mail clients and e-mail providers differently I’m all ears. But let’s not let this privacy travesty go on much longer…

10 responses to “How to make e-mail encrypted for everyone

  1. I agree. I’ve been doing infosec for 10 years and average people would NEVER understand pgp/etc.

    What you are describing is basically equivalent to DKIM: except it’s encryption instead of signing

    DKIM has basically worked as a protocol, so the encryption equivalent should be doable too

  2. Your scheme seems a reasonable workable idea.

    Can I suggest an additonal bit of commentary, between ‘Decrypt incoming e-mails using the private key of that user’ and ‘Deliver the e-mail using the normal protocols’, of ‘Spam and malware content checking’.

    As the email is encrypted, it cannot be content checked in transit. The point I’m trying to clarify is that the receiving client can check the content, after decryption, but before delivery to the user.

  3. > Some may frown reading that I suggest leaving the private key in the hands of your e-mail provider.

    It’s a strict improvement over “no encryption,” and has a simple upgrade path to “true privacy” for those people/providers who want it: users give a public key to their email provider, and their provider delivers still-encrypted emails to the client.

  4. I gave $1,000 last year to EFF with a note to direct my funds to this very issue. It’s a very hard problem and needs big players to solve it. More people need to get involved to lay out a fully-baked solution. That takes money, at least to some degree.

    For me, more people need to complain to EFF since they seem to have the biggest bullhorn.

    What do you think? How do we increase the activism around this issue?

  5. “I understand that this is means your e-mail provider can read your e-mail, so it won’t work for everyone. But I think most people will accept that the same way they accept that their bank can read their bank statement. If we can trade this for usability it’s still a HUGE step up for privacy”

    Perhaps many fail to understand that millions of users are exactly trying to avoid their providers having the least chance to read their mails. And no, this is not the same as a bank statement. Perhaps in the US or somewhere else in the Anglosphere where people said goodbye to their privacy altogether.

    It wouldn’t work for millions of users. The system as it’s now simply grants no safety at all. Your chances that your mails are intercepted by strangers are relatively low. The chance your mail provider (from Google to outlook passing through yahoo or any other us based platform) will collect data on you for sure. That’s the problem in a nutshell. And encryption is not enough. Those mails simply shouldn’t be routed through those operators nor they should be stored in the cloud. From a security point of view, direct end-to-end with cryptography would be safer (in that case the OS would be the issue, yet better than having your personal data in somebody else’s server).

  6. The first entity I don’t trust is my email system provider (e.g. gmail) so I’m not at all confortable with the ideal of letting a third party managing any of my private key.

    A primary missing rule is that your private key must still be private, and managed like a real physical key: you must get it when required, and keep it near you.

    So, the servers of your email provider should be able to share your public key, that’s Ok.
    But your private key must be only yours.

    And so, if you really want to keep the ability to get your email from a cybercoffe, why not use a third party service to retrieve your encrypted private key, but please, don’t let your private keynésien to your email service provider.

    And then, web browsers should be able to provide trusty features to manage your keys:
    – ability to exchange with your own third party key server
    – ability to decrypt/encrypt your data on the fly
    – ability to forget your credentials when you leave your web session
    – ability to generate asymetric key pair for you
    – ability to use your already existing gpg (or even ssh) keys if any.

  7. To the people commenting that any solution that doesn’t perform end-to-end encryption won’t work: Unless you suggest another solution to the usability problem that key management puts on users, I don’t see any alternative.

  8. Splitting emails with multiple recipients into several emails will loose the “thread”, so users will not be able to “reply to all”. Multi-recipient emails are important part of the way business operate today, so this is major issue here.

  9. @Georgi: This is not true. All other recipients would still be included in the e-mail, just not the public, unencrypted part of it. After decryption it would look exactly the same as before. The idea between splitting it is so that each part can be encrypted with that persons individual encryption key.

Comments are closed.