# Encrypted email 'define expected-reading 10 min 'define created 10 September 2022 'define edited 16 September 2022 [$pagenav] :contents :numbered 1. [url #encryption-and-signature Encryption and signature] 2. [url #openpgp OpenPGP] .numbered 1. [url #pgpinline PGP/Inline] 2. [url #pgpmime PGP/MIME] 3. [url #smime S/MIME] 4. [url #reop reop] 5. [url #post-email-systems Post-email systems] 6. [url #centralized-non-email-systems Centralized non-email systems] .numbered 1. [url #protonmail Protonmail] 2. [url #tutanota Tutanota] 7. [url #conclusion Conclusion] 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 [url https://www.virtru.com/blog/arent-people-using-email-encryption 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) [url /blog/how-to-encrypt-email tutorial on how to setup] [url #openpgp OpenPGP] or [url #smime 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 [url https://en.wikipedia.org/wiki/Public-key_cryptography 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: .numbered 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 [url https://en.wikipedia.org/wiki/Digital_signature digitally signed] (not to be confused with [url https://en.wikipedia.org/wiki/Digital_signature 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: .numbered 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 [url https://www.pep.security/en/ pEp], the creation and exchange of keys can be easily automated. ## OpenPGP By far, the most popular way to encrypt your emails is with [url https://en.wikipedia.org/wiki/Pretty_Good_Privacy 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 [url https://en.wikipedia.org/wiki/Web_of_trust web of trust], the idea being, different people sign each others public keys (sometimes at [url https://en.wikipedia.org/wiki/Key_signing_party 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 [url https://restoreprivacy.com/let-pgp-die/ abolish it] while other still [url https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/ 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 [url #smime 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 [url https://josefsson.org/inline-openpgp-considered-harmful.html other limitations] too, to name a few: .numbered 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: .numbered 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 [url https://web.archive.org/web/20180625054201/https://www.whonix.org/blog/pgp-inline-vs-mime it's implementation is flawed] ### PGP/MIME "PGP/MIME" is the second option. As it's name suggests, you can encrypt [url https://en.wikipedia.org/wiki/MIME MIME] data with PGP, which by definition means it supports any content type. This includes: .numbered 1. Support for Unicode characters and HTML messages 2. Attachments of any type 3. Delivery status report Basically, any [url https://en.wikipedia.org/wiki/MIME#Multipart_subtypes 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 [url https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.html generally preferred] over PGP/Inline. Nonetheless, it has it's shortcomings: .numbered 1. As already mentioned, it is hard to implement and [url https://web.archive.org/web/20180625054201/https://www.whonix.org/blog/pgp-inline-vs-mime 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 [url https://en.wikipedia.org/wiki/S/MIME S/MIME], roughly said, combines and extends the [url https://en.wikipedia.org/wiki/Cryptographic_Message_Syntax Cryptograhic Message Syntax] encryption scheme and [url https://en.wikipedia.org/wiki/MIME MIME] standard to create a singular, email-oriented standard. Unlike OpenPGP it doesn't use a web of trust, but a [url https://en.wikipedia.org/wiki/Public_key_infrastructure Public key infrastructure]. This means that, rather than people exchanging certificates between themselves, a [url https://en.wikipedia.org/wiki/Certificate_authority 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 [url https://support.google.com/a/answer/6374496?hl=en#zippy= Google Workspace Enterprise Edition] and [url https://support.microsoft.com/en-us/office/encrypt-messages-by-using-s-mime-in-outlook-on-the-web-878c79fc-7088-4b39-966f-14512658f480 Outlook Enterprise/Business] ([url https://docs.microsoft.com/en-us/exchange/security-and-compliance/smime-exo/configure-smime-exo?view=o365-worldwide Exchange Online has to be configured] by an administrator and can be used only with [url https://docs.microsoft.com/en-us/deployoffice/endofsupport/microsoft-365-services-connectivity paid clients]) is available. On the other hand, you can browse [url https://support.google.com/a/answer/7448393?hl=en&ref_topic=9061730 Google's] and [url https://docs.microsoft.com/en-us/security/trusted-root/participants-list 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: [url https://www.actalis.com/s-mime-certificates.aspx Actalis]. A good tutorial on the procedure can be found [url https://www.dannyguo.com/blog/how-to-get-a-free-s-mime-certificate/ here], but beware, *[they]* generate the private key. Otherwise, it's email encryption capabilities are the same as those outlined in [url #pgpmime PGP/MIME]. ## reop [url https://flak.tedunangst.com/post/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 [url http://nacl.cr.yp.to/index.html 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: .quote no support for key revocation, or long chains of certificates, or partial trust, or key servers However, as explained in it's [url https://flak.tedunangst.com/post/reop 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 [url https://hacktivis.me/about 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 [url https://github.com/OpenTechFund/secure-email document], created by the [url https://www.opentech.fund/ OpenTechFunc], which outlines very thoroughly all "next generation secure email or email-like communication" technologies. In it, they define the term "[url https://github.com/OpenTechFund/secure-email#post-email-alternatives post-mail]" as: .quote 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 [url https://en.wikipedia.org/wiki/Peer-to-peer 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 [url http://goldbug.sourceforge.net/ goldbug] and [url https://retroshare.cc/ retroshare]. Until 2021, zeronet *[was]* updated, but the [url https://github.com/shortcutme author] seems to have [url https://github.com/HelloZeroNet/ZeroNet/issues/2808#issuecomment-1132820787 disappeared]. ## Centralized non-email systems "Centralized non-email systems" is another term, which as far as I can tell, is also coined by [url https://github.com/OpenTechFund/secure-email this document] from [url https://www.opentech.fund/ OpenTechFunc]. They define it as "centralized email-like messaging platform" and further divide it into: :quote :numbered 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. .bulleted - 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 [url https://adammonsen.com/post/853/ a bad system] to begin with, ShazzleMail is pretty much [url https://www.reddit.com/r/privacytoolsIO/comments/nv6gzu/comment/hf338kq/?utm_source=share&utm_medium=web2x&context=3 dead] and Walnut also isn't up. That leaves us with the two last-standing providers: ### Protonmail Protonmail, or [url https://proton.me/ proton.me] as they are called now, which uses good old [url #openpgp OpenPGP]. That means they have end-to-end encryption and zero-access encryption by default for all protonmail accounts. They also [url https://proton.me/support/how-to-use-pgp 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 [url #openpgp 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 [url https://proton.me/pricing here]. ### Tutanota [url https://tutanota.com/ 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) [url https://en.wikipedia.org/wiki/Advanced_Encryption_Standard 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 [url https://tutanota.com/security/ 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 [url #protonmail Protonmail], but their free tier is a lot more capable than [url #protonmail Protonmail]'s. Their pricing is extremely flexible, being able to buy specific features by themselves, like storage or mail aliases. Check it out [url https://tutanota.com/pricing/ here]. ## Conclusion In brief, almost all email encryption systems use [url #encryption-and-signature public-key cryptography]. The most popular of these systems for personal use is [url #openpgp OpenPGP], but in the business space, [url #smime S/MIME] is quite a bit more prominent. [url #reop reop] is a viable, but limited, very new and lightweight systems for encrypting your email messages. [url #protonmail Protonmail] is an email provider, which has [url #openpgp OpenPGP] built-in, enabling and supporting encryption by default, but their free tier leaves what to be desired. [url #tutanota 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.