Encrypted email

When you try and look around for articles, regarding encrypted emails, all you’ll find is people complaining about it’s difficulties and shortcomings. But, no one actually explains what to do if you, nevertheless, want to encrypt your emails! At best most articles will just shove some product up your face.

That’s why, after a fairly lengthy research process, I’ve decided to do just that. These are the more common ways to encrypt your email with their strengths and weaknesses. I also wrote a (somewhat rough) tutorial on how to setup OpenPGP or S/MIME in practice.

Note: What I’m referring to is end-to-end encryption, where you send an encrypted email, and the recipient decrypts it. Encryption between you and a mail server is practically a given and is setup by the mail server administrator.

Encryption and signature

Unless stated otherwise, all of the listed encryption (and signature) schemes work by utilizing public-key cryptography.

In brief, if you are sending an encrypted email, the recipient needs to have generated a public and private key pair. Then you need to have acquired their public key. Finally, if you want to send them an encrypted email:

1. You encrypt your email with their public key
2. The recipient decrypts your message with their private key

And if someone wants to send you an encrypted email, you need to generate a public and private key pair, share your public key with them, and when you receive the message, decrypt it with your private key.

Every email you send can be digitally signed (not to be confused with electronic signatures), meaning the message is (cryptographically) “signed”, and with this signature, the recipient can check if the message was changed during transit. Digital signatures also use public-key cryptography, but the other way around:

1. You sign your email with your private key
2. Then the recipient verifies your message with your public key.

This might sound a bit complicated, but all you need to worry about is you and the recipient generating these public-private key pairs, exchanging public keys, and your email client should handle the rest. And if you use a tool like pEp, the creation and exchange of keys can be easily automated.

OpenPGP

By far, the most popular way to encrypt your emails is with OpenPGP. PGP is the original program which implemented the encryption scheme, while OpenPGP is the standard/encryption scheme, which was created from PGP (so when I say OpenPGP, I mean a program that implements OpenPGP).

By design, it relies on a web of trust, the idea being, different people sign each others public keys (sometimes at key signing parties), and you know that a specific key corresponds to a specific person, only when a large amount of people have signed it.

OpenPGP divides the security community quite a lot, some abolish it while other still defend it, but at the end of the day, it’s very widespread and if someone encrypts their email, chances are it’s with OpenPGP (unless they’re in a business, where S/MIME rules).

There are two main ways to encrypt an email with OpenPGP:

PGP/Inline

The first is called “PGP/Inline”, with which you encrypt only the message itself. That’s it. And there are other limitations too, to name a few:

1. You can’t encrypt attachments, period.
2. Your message can only be plain ASCII text characters. So any Unicode character (probably) won’t work, and HTML messages are out of the question.

Though, it’s not all bad. If you can survive only sending text to other people, PGP/Inline might be a better option:

1. It’s much easier to work with, you can directly copy the encrypted PGP message and decrypt it however you like
2. The other option, PGP/MIME, is much harder to implement properly and there have been cases where it’s implementation is flawed

PGP/MIME

“PGP/MIME” is the second option. As it’s name suggests, you can encrypt MIME data with PGP, which by definition means it supports any content type. This includes:

1. Support for Unicode characters and HTML messages
2. Attachments of any type
3. Delivery status report

Basically, any multipart subtype. Also, I should mention, the message structure and all metadata is hidden by design.

PGP/MIME is capable of a lot more, and is generally preferred over PGP/Inline. Nonetheless, it has it’s shortcomings:

1. As already mentioned, it is hard to implement and flawed implementations have been made
2. Everything is encrypted together, so you’ll need to download the whole email, including all attachments, to decrypt it
3. If your client doesn’t support it, manual decryption takes a bit more work

S/MIME

S/MIME, roughly said, combines and extends the Cryptograhic Message Syntax encryption scheme and MIME standard to create a singular, email-oriented standard.

Unlike OpenPGP it doesn’t use a web of trust, but a Public key infrastructure. This means that, rather than people exchanging certificates between themselves, a Certificate Authroity connects public keys with entities (people or organizations for example).

So, already, it has a huge advantage, you don’t need to exchange keys, since the email client will handle it. S/MIME is most often used by corporations/organizations, so support in commercial mail clients like Google Workspace Enterprise Edition and Outlook Enterprise/Business (Exchange Online has to be configured by an administrator and can be used only with paid clients) is available.

On the other hand, you can browse Google’s and Microsoft’s trusted (root) CAs all you want, but you’ll find that there is only one place where you could register a certificate for free: Actalis. A good tutorial on the procedure can be found here, but beware, they generate the private key.

Otherwise, it’s email encryption capabilities are the same as those outlined in PGP/MIME.

reop

reop is a very new, simple and “completed” system. The thing is, it’s only a single command line utility that uses some encryption schemes (picked by the nacl library) for it’s own unique system. Currently, there doesn’t seem to be any email clients that support it.

It is also fairly limited:

no support for key revocation, or long chains of certificates, or partial trust, or key servers

However, as explained in it’s article, that might not be that big of a deal. Finally, there are very very few people that use it. From experience, I have only seen Haelwenn Monnier use it.

The only reason for using reop is if you want a very small system with a very simple source code behind it. Nevertheless, it’s still a viable alternative.

Post-email systems

There is a somewhat old document, created by the OpenTechFunc, which outlines very thoroughly all “next generation secure email or email-like communication” technologies.

In it, they define the term “post-mail” as:

projects to create alternatives to email that are more secure yet still email-like

And outline zero trust and fingerprinting as the main advantages of these systems. Also most of these systems are peer-to-peer.

Given that these projects aren’t really email, I won’t dive much deeper into it. But I will mention, almost all listed projects seem to have been abandoned. Those still under active development are goldbug and retroshare. Until 2021, zeronet was updated, but the author seems to have disappeared.

Centralized non-email systems

“Centralized non-email systems” is another term, which as far as I can tell, is also coined by this document from OpenTechFunc. They define it as “centralized email-like messaging platform” and further divide it into:

1. Closed system: you can only send to other users on the same provider.
2. Semi-closed system: you can communicate outside the system, but it is troublesome to do so.
   • If you send an email to someone else using the same system, it is end-to-end encrypted.
   • If you send an email outside the system, then the recipient gets a URL they can use to view the message. Often, the message is symmetrically encrypted using a shared secret.
3. Semi-closed system, with no encryption: just like above, but emails outside the system have no encryption.

Out of the listed options, Enlocked doesn’t work anymore and was a bad system to begin with, ShazzleMail is pretty much dead and Walnut also isn’t up.

That leaves us with the two last-standing providers:

Protonmail

Protonmail, or proton.me as they are called now, which uses good old OpenPGP. That means they have end-to-end encryption and zero-access encryption by default for all protonmail accounts. They also support encrypted conversations with non-protonmail users.

Funnily enough, Protonmail doesn’t really fit in any of the listed categories, since encrypted emails outside the system will work as any OpenPGP encrypted one.

Protonmail’s services have a free tier, which should be enough for lighter usage, but restricts heavily storage, label and folder count, amount of sent messages per day, etc. At the time of writing, their second tier pretty much lifts all restrictions for 5 euro per month (without annual contracts). Check out their pricing here.

Tutanota

Tutanota uses it’s own special system for security. In brief, all of your emails are (zero-access) stored and end-to-end encrypted with (mostly) AES 128, and while they generate and hold your public and private keys, your password is needed to decrypt your private key (do check out their security page for more details).

However, it’s crucial to note that they are a type 2. Semi-closed system. If you send an encrypted email to a non-tutanota recipient, the recipient will get a URL from which they will be able to reply, through Tutanota’s web client.

Finally, pricing. In general, they have a lot less features than Protonmail, but their free tier is a lot more capable than Protonmail’s. Their pricing is extremely flexible, being able to buy specific features by themselves, like storage or mail aliases. Check it out here.

Conclusion

In brief, almost all email encryption systems use public-key cryptography. The most popular of these systems for personal use is OpenPGP, but in the business space, S/MIME is quite a bit more prominent. reop is a viable, but limited, very new and lightweight systems for encrypting your email messages.

Protonmail is an email provider, which has OpenPGP built-in, enabling and supporting encryption by default, but their free tier leaves what to be desired. Tutanota is another provider, with their own entirely different system, where encrypted emails to non-tutanota users force the recipients to use their web client.