As part of an ongoing series, we’re helping to explain the various steps to encrypt and protect your most valuable data. Follow along each week for practical privacy how-tos.

Over the past two weeks, we’ve walked through encrypting your primary machine’s hard disk and protecting the user data on your mobile device. These steps are vital for protecting your static information, but don’t go very far in terms of protecting your communication. This week, we will focus on protecting the information you send and receive over email.

Though you might visit a webmail client (i.e. Gmail) in the browser securely over HTTPS, and though the messages might be encrypted at rest on your host’s servers, email itself is inherently insecure. Messages are frequently exchanged in plaintext between multiple servers as they make their way from a sender to a recipient. An attacker who can intercept – or worse, manipulate – messages in transit would gain access to huge stores of your personal information.

Why It Matters

Unlike disk encryption, the idea of email encryption is to protect data in transit. This means that someone intercepting a message can’t read the secret information it contains or corrupt the data before the recipient reads it.

Unfortunately, email encryption is fairly technical and isn’t universally supported by hosts. Google, for example, makes email incredibly easy to use with Gmail. However, Google also aims to index your conversations so they can provide more meaningful services elsewhere throughout their platform:

Our automated systems analyze your content (including emails) to provide you personally relevant product features, such as customized search results, tailored advertising, and spam and malware detection.

(source: Google’s Privacy Policy as of 16 December 2016)

Sometimes you might need to exchange information with a friend, family member, or colleague of a sensitive nature. If you’re using Gmail, Yahoo, or another hosted provider and sending messages in plain text, those hosts (or other entities) can make themselves party to the conversations.

Getting Started

As already mentioned, maintaining secure email is fairly technical. Most webmail clients won’t support encrypted email, so you’ll instead likely need to depend on a desktop client when handling sensitive messages. There are options available at the end of this article, but let’s start with a walk-through of key set-up.

GPG Keys

Installing GPG

If you don’t already have a GPG key, you’ll need to set one up. First, install some format of GnuPG on your machine. On Mac, it’s easiest to run:

$ brew install gnupg2

On Windows, you’ll want to install GPG4Win.

Once GnuPG is installed, you’ll have access to either gpg2 or gpg from the command line (gpg2 is preferred as it refers explicitly to the version of GnuPG that we just installed. Older versions of the tool might also be installed on your system).

Creating the Keys

In this walk-through, we will create a strong master key with no expiration and two sub-keys that will each expire in one year. The expiration isn’t required, but ensures that the keys will wear out in the event that you ever lose them and want to move on.

To create the master key, start with:

$ gpg2 --gen-key

In the prompts that follow:

Select option 4 to create an RSA key used for signing only

Set the key size to 4096 bits

Set the expiration to infinity (0)

Enter your real name so others can identify you

Enter your email address

Optionally enter a comment to identify the key

Select a strong passphrase – this will be used later

Keep track of your key’s ID (the 8 character string that’s presented when it’s created) as we will need this later on.

Creating the Sub-Keys

To add a sub-key, we need to edit the key that was just created. Make sure you substitute your key ID from above when you see KEYID in the steps that follow.

To begin:

$ gpg2 --expert --edit-key KEYID gpg> addkey

On the menus that follow:

Select option 4 to create an RSA key for signing only

Set the key size to 4096 bits

Set the expiration to 1y

This created your first signing key. To create an encryption key:

gpg> addkey

On the menus that follow:

Select option 6 to create an RSA key for encryption only

Set the key size to 4096 bits

Set the expiration to 1y

Now we have a second key for encryption. Close out of the menu with:

gpg> save

Add Other Identities

If you use multiple email identities and want to use the same keys for all of them, this is easy to do by adding those various personas to the keys themselves.

$ gpg2 --expert --edit-key KEYID gpg> adduid

On the menus that follow, provide your name, email address, and an optional comment. There is no limit to the number of identities you can add, but be sure to only add your personal identities and not email addresses you share with others. Once you’re finished, commit the changes with:

gpg> save

Publish the Keys

No one can send you a private email unless they know your public key and can verify it’s yours. You can upload your private key to a public keyserver and make yourself searchable:

$ gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --send-key KEYID

It’s a good idea to generate a revocation certificate for your keys at this point, too, in the event that they’re ever stolen or compromised. Remember, if you lose your private key there is no way to revoke it on the server; keeping an offline revocation certificate is an insurance policy that proactively protects your security.

Generate the key easily with:

$ gpg2 --output KEYID.asc --gen-revoke KEYID

Specify the revocation reason as “key has been compromised” and store the generated certificate in a safe place. You might not ever need this certificate, but if you do, having it in a trustworthy location is critical.

S/MIME Certificates

An alternative to GPG protection is S/MIME – Secure/Multipurpose Internet Mail Extensions. Rather than generating a key on your own and conveying its ID to other parties directly, a certificate authority can generate and sign a certificate on your behalf that then authenticates your messages. The advantage here is that you don’t have to spend time at key signing parties to lend credibility to your online identity – the certificate authority does that for you.

The setup for S/MIME in Thunderbird is similar to that of GPG – you have to create a public and private key. The advantage, though, is that the majority of the work takes place in the browser and you don’t have to install additional command-line utilities.

The certificate authority Comodo has a form for requesting a free certificate – the private key is created in your browser and the signed certificate is sent directly to the email address being configured. You can export the new key and its matching certificate as a .p12 (Personal Information Exchange) file that can be imported into Thunderbird.

Once set up, be sure to sign the messages you send. This will distribute your public key, allowing others to send you encrypted messages.

Mail Client

While there are other desktop clients capable of sending and receiving encrypted mail, Mozilla’s Thunderbird is one of the easier ones to configure and use. It runs uniformly on both Mac and Windows, handles any email account, and supports a variety of useful plugins and extensions – for encryption, Enigmail is the first plugin you should install.

Once set up, Thunderbird (and Enigmail) will automatically integrate with the GPG toolset you installed while generating keys. This allows you to digitally sign messages using either protocol, verify the signatures on incoming messages, and both encrypt or decrypt as needed.

Under the Hood

Both GPG and S/MIME work under the same relative principle: the world knows your public key and only you have the matching private key. Any messages sent by you can be signed with your private key (the signature then verified against your well-known public key). Likewise, anyone else can use your public key to encrypt a message that can then only be read with your private key.

The difference between the protocols is trust.

Anyone can create a GPG key claiming to represent any email address and publish it to a public keyserver. Knowing whether or not a particular key really matches a particular person requires either exchanging the key holder’s ID out of band, or depending on signatures from parties you trust. This is know as the “web of trust” and is crucial to ensuring you are securely communicating with the correct party.

Likewise, anyone can request a certificate authority-signed S/MIME certificate for any email address, but only the owner of that email address can retrieve the certificate. If the email owner and the person initializing the request aren’t the same, the certificate is useless. S/MIME alleviates the trust concerns that challenge GPG.

The disadvantage of S/MIME is that public keys are not independently discoverable. GPG keys can be searched in public databases whereas S/MIME keys are exchanged directly. Both systems definitely have their upsides and downsides; you can, of course, set up both so they’re available in the different contexts that require them.

What’s Next

If you’d prefer to use a webmail client over a desktop installation, there are tools available to help. Mailvelope is a solid extension for Chrome that powers GPG encryption, signing, and decryption in the browser for clients like Gmail. It’s just another tool available for your security arsenal – just be sure you only use it on a trusted, secure machine.

Another step you can take for security is to transfer your GPG keys from the hard disk to a more secure platform, like a GPG smart card or a YubiKey. These hardware platforms allow you to write a private key in, but you can never extract the private key once its in place. Even if an attacker were to steal your physical key, it would be useless to them without your private passcode (so your email would stay safe and secure).

These are optional steps, and even without them, your email can now send and receive completely private messages!

Come back next week to learn how to further protect your communication: Encrypt Everything – Internet Access.