Email Is Insecure, but You Can Fix It
Email is insecure.
We need to make this clear – email is like sending a postcard: anyone (or any service) that handles the message can see the entire message. When you send a Gmail message to your friend on Yahoo Mail, Google, Yahoo, and every internet service provider connecting the two can read that message (1).
Often, this isn’t a problem. We’re not sending messages we think need to be secured, and we’re making a simple trade: less security (Google, or your email provider, can see all our messages) for increased convenience (I can access my mail from anywhere, it’s easily searched).
But, what if you wanted to send messages securely? What if you wanted to tip off a reporter that there was a problem at a company? Or you wanted to send your super-secret warp engine design to your collaborator? There are times we want more security than we’re provided on normal email. Thankfully, there’s a solution: PGP, or Pretty Good Privacy.
But First, Reality
Before we discuss PGP we need to cover something: while using PGP isn’t hard, getting your friends and collaborators to use it can be exceptionally difficult. People don’t want to expend effort to send messages, and often convenience wins over privacy. PGP requires all parties sending messages be on board (unless you’re both securing your messages, there’s not much point).
So, if you want a secure way to send messages with your friend, your collaborator, someone who you already have contact with, just use Signal. Signal is incredibly secure, highly regarded in the security community, and dead simple to use (sending signal messages is just like sending texts on your phone – if both you and your friend have Signal on your phones, just open Signal, hit their contact, and go). Signal is the de-facto tool used by dissidents and others who need the highest security and, perhaps most critically, there’s no real place for you, as a user, to mis-configure something (thinking you have security when you don’t is often worse than not having any security).
However, Signal is linked to your phone number. This is by design – Signal manages users by phone numbers, so to send someone a Signal message, you just need their cell number. But this isn’t always desirable; while many of us are fine with giving out our email addresses online, but we’re often far more protective about our phone number. If you want to have encrypted, secured conversations with someone online, but you don’t want to give out your number, Signal isn’t a good fit.
Ultimately – if Signal meets your needs (and for most of you, it will), just use that. If it doesn’t… let’s get back to PGP.
PGP (And Public Key Cryptography) Explained
Before I can tell you how to encrypt your email, we do need to briefly explain how encrypted email works. I promise, we’ll keep this short here’s slightly more detail.
Let’s say two people want to send encrypted messages over the internet – we’ll call them person A and person B, or Alice (A) and Bob (B). But the internet is insecure, and they can’t just say, “Hey, I’m going to use the password Super$ecre77hing to encrypt my message” over email because, well, email is insecure (if it wasn’t, we wouldn’t be doing this).
This is where “public key cryptography” comes in. Alice and Bob each make their “keys:” a “public key” which can be shared freely on the insecure internet, and a “private key” which they’ll hold onto. Anyone with Alice’s public key can encrypt a message to Alice, but only the person with Alice’s private key (we assume only Alice) can decrypt the message. So, if I want to send Bob a secured message, all I need is Bob’s public key, which he can freely give me over insecure channels, because you can’t reverse engineer a private key from a public key.
That’s all you really need to know to get started – to send someone an encrypted message, you need their public key. For someone to send you a message, they need your public key.
And… depending on how you go about this, you might not even need to worry about that. But, enough theory, let’s get started!
Option 1: ProtonMail
If you’re alright with registering a new email address for your encrypted emails, the easiest solution is to go grab an account at ProtonMail. ProtonMail integrates PGP into their webmail, and email between two ProtonMail accounts is automatically encrypted (ProtonMail fetches the public key of the other user on your behalf – so you don’t need to do anything). While the free tier does have some restrictions (like a 150/messages per day cap) and their default keys are weaker than I’d like, it’s still my recommended option.
ProtonMail can also send encrypted PGP messages to people not using ProtonMail - it’s a little trickier (you’ll need your friend to send you their public key, and you’ll need to give them yours), but ProtonMail’s documentation on this is straightforward; it’s not a hard process.
ProtonMail also has two other nifty advantages. One is their “zero access” policy - if someone sends you a message to your ProtonMail account that isn’t encrypted, ProtonMail will automatically encrypt it against your public key, and delete the unencrypted copy, so there’s no unencrypted data on their server. This limits what is vulnerable in the event ProtonMail is ever hacked.
Second, unlike our other option, ProtonMail is web-based, which makes it a bit easier to work with for most users – you can easily access your mail and send encrypted messages from any machine, as long as you have your password. Now, this does come with a trade-off. If ProtonMail is ever purchased by some malicious actor, they can update their website code to capture your secret keys when you enter your password, and you’d never know. By using ProtonMail, you are trusting ProtonMail to do what they say (keep your keys encrypted and secret), in exchange for increased convenience.
But, perhaps you want to keep your current email address, or you’re not comfortable trusting your private keys to a web service, or you want to be able to handle more messages, but you don’t want to upgrade to ProtonMail’s paid tiers. If so, we turn to our second option.
Option 2: Mailvelope
Mailvelope is a good option if you’d prefer to keep your existing email address. Mailvelope is a browser extension that integrates with sites like GMail, Outlook, Yahoo Mail, etc – when you hit compose on an email, there will be a little Mailvelope icon you can click to write an encrypted message. When you receive encrypted messages, they’re automatically decrypted.
Like with ProtonMail, Mailvelope simplifies things for you. It will happily generate a set of keys on your behalf, and it will (optionally) confirm your email address (you generally will want to do this – as it ensures other Mailvelope users can send encrypted mail to you without asking for your key). Once installed, Mailvelope is unobtrusive and incredibly simple to use.
As with ProtonMail, mailing other Mailvelope users is an easy, friction-free process. Like ProtonMail, Mailvelope will happily accept public keys for non-Mailvelope (and it makes it easy to share your own key) and again, the process is simple. So, if you have a friend using ProtonMail (or some other service), you can still send them secured mail via Mailvelope.
There are two notable drawbacks to Mailvelope, both due to its nature as a browser extension: first, encrypting attachments on Mailvelope is an extra step. You’ll need to click on the extension in your browser bar, hit “File Encryption,” and encrypt the file manually, before attaching it to the email.
Second, and perhaps most critically for many, Mailvelope operates as a local browser extension, not a web-based tool. Because of this, you’ll only be able to encrypt/decrypt emails on the computer where you have Mailvelope installed (while you technically can export your keys and import them onto another computer running Mailvelope, but you can’t seamlessly move between computers like you could with ProtonMail).
Despite these setbacks, Mailvelope is one of the better pieces of encryption software I’ve seen. It’s easy, incredibly user friendly, and well documented. But, as we said in the beginning: there’s a trade, convenience or security.
Slightly More Advanced: Getting Others’ Keys
If you’re sending messages between users on the same platform (Mailvelope-to-Mailvelope, Proton-to-Proton), you never have to deal with keys. But what do you do when you want to start an encrypted conversation with someone else?
First, you need their public key. The easiest way is to simply ask for it, though sometimes reporters, security researchers, and others will post public links to their keys on their blogs, profiles, etc, so you can begin with an encrypted message instead of sending an initial, “Hey, can I get your public key?” That said, it’s also not uncommon to have a “key on request” policy for new contacts (public keys usually contain their associated email address, so if you share a public key, you’re also sharing your email, and some people might not want to have that publicly accessible).
Regardless of how you get their key, just remember, when you send them a message, you need to send them your public key too if you want them to be able to send you a secure reply.
Final Notes
One small warning to everyone: PGP doesn’t encrypt subject lines. While the email body is encrypted by both ProtonMail and Mailvelope, subjects are always sent unencrypted because they don’t want to break existing email standards. Just keep that in mind when sending your super secret messages.
With that said, you should now be set to send your first encrypted emails. While you might not need it now, there’s something satisfying about knowing your messages are safe. It’s not for everyone (no security solution is), but if you want more security, it’s readily available.
And finally, if you want to send me a secure email, you can grab my key here.
(1) Yes, some email servers do encrypt messages between each other via TLS, but that’s both hard to predict as a user, and doesn’t change the fact that the providers themselves have direct access to the messages.
Note: The featured image for this article was shot by Richard Patterson, and is used under a Creative Commons License.