How do I send encrypted email?

Home » EMail

You are correct in noting the email is, at it's very core, insecure. An administrator on any of the systems between sender and recipient can quite easily look at any email that traverses their server. Similarly, networks can be sniffed, and email passing by can be easily read.

I'm not trying to scare you, because that kind of reading is very rare, and typically very benign. Let's face it, most people don't really care about your email, I'm sorry to say.

But what if even that small risk is unacceptable?

Then we encrypt.

I want to start by pointing out that there are several ways to encrypt data, and several tools that can be added to mail programs that might even do it for you. There are many good solutions out there. Sadly, not all are compatible with each other. So rather than enumerate a list of add-ons for various mail programs, and include some kind of matrix of compatibility, I'm going to get just a little geeky, and talk about encrypting by hand, using the underlying technology that many, though not all, of those tools use: Gnu Privacy Guard, or GPG.

This technique works with all mail programs.

•

Public Key Encryption

When we talk about encryption, the first approach that typically comes to mind is password or phrase encryption. With those techniques, a password is used to encrypt the data, and then must be supplied again to decrypt it. The data without the password is theoretically useless, but anyone with the password can decrypt it.

Public Key encryption uses a different style of algorithm. To begin with, you'll generate two matching "keys"; a public key, and a private key. The characteristics of these keys is such that data encrypted with one can only be decrypted with the other.

That's important. Make sure you get it. By generating a public/private key pair, someone can encrypt data using the public key that can only be decrypted using the associated private key. If all you have is the public key, you can't even decrypt what you've just encrypted.

As an example, you'll find my public key here. Anyone who wants to encrypt data that only I can decrypt would use that key. I keep the associated private key ... well, I keep that private. When I need to decrypt something that has been encrypted with my public key, I use my matching private key to do so.

Naturally there's a lot more to it, but those are the basics.

•

Getting GPG

GPG is free software, under the GNU General Public License. You can download it, and find documentation for it, on the GnuPG web site. It's available for many platforms, and often comes preinstalled on various Linux distributions. Windows users can download binaries directly from the GPG download page.

GPG is a command-line tool. That means once installed, you'll need to open a Windows Command Prompt and run the tool from there. It's perhaps easiest to simply "CD" to the directory containing the GPG executables. Alternately you can copy all the "G*.exe" executables to a different directory already on your PATH.

Run "gpg" once, and it will create it's storage location for keys, which it refers to as your "key ring".

•

Creating a key pair

The intended recipient needs to generate a public/private key pair.

In the Windows Command Prompt, enter gpg --gen-key. In the following sequence, your responses are in bold:

gpg (GnuPG) 1.4.2.2; Copyright (C) 2005 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Please select what kind of key you want:
   (1) DSA and Elgamal (default)
   (2) DSA (sign only)
   (5) RSA (sign only)
Your selection? ENTER to accept the default
DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) ENTER to accept the default
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) ENTER to accept the default
Key does not expire at all
Is this correct? (y/N) Y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: Leo A. Notenboom (Use your own name)
Email address: example@ask-leo.com (Use your own email address)
Comment: ENTER to accept the default
You selected this USER-ID:
    "Leo A. Notenboom <leo@ask-leo.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.
Passphrase: Enter a passphrase to further protect your private key

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

(Random characters appear here as they key is generated.)

gpg: key 874A3EC1 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
pub   1024D/874A3EC1 2006-03-08
      Key fingerprint = 8A4F 770F D037 D414 F4E6  B95C 6E89 72A3 874A 3EC1
uid                  Leo A. Notenboom <example@ask-leo.com>
sub   2048g/1B917E56 2006-03-08

At this point your secret key and your public key have been generated, and placed on your keyring.

In order to get the public key to the person who wants to encrypt your data, you'll need to export it:

c:\>gpg -a --export example@ask-leo.com >mykey.pub

This created "mykey.pub", a text file that contains your public key. You can now mail this to the person who's going to encrypt data to be sent to you, or post it publicly if you like.

•

Encrypting Data

In order to encrypt data, the sender will have to install GPG as above. They don't need to create their own public/private keypair in order to encrypt your data. All they need is the public key you created above, and made available to them somehow.

They start by "importing" your public key onto their keyring:

c:\>gpg --import mykey.pub
gpg: key 874A3EC1: public key "Leo A. Notenboom <example@ask-leo.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

Now they're ready to encrypt. That looks like this (encrypting the example file "example.xls"):

c:\>gpg -a --encrypt -r example@ask-leo.com example.xls
gpg: 1B917E56: There is no assurance this key belongs to the named user

pub  2048g/1B917E56 2006-03-08 Leo A. Notenboom <example@ask-leo.com>
 Primary key fingerprint: 8A4F 770F D037 D414 F4E6  B95C 6E89 72A3 874A 3EC1
      Subkey fingerprint: 215A 55C8 C88A 2587 4E64  995C 5EFC 7E3F 1B91 7E56

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) y

Note the dire warning about making sure you know who's key you're dealing with. There are ways to confirm and avoid this message, but for now to keep things simple, we'll simply note that the Primary Key fingerprint listed here matches the fingerprint that was listed when you created the key, and answer "Yes".

The result of this example operation is "example.xls.asc". This text file is your encrypted data. You can email it with confidence to the intended recipient, knowing that only they can decrypt it with their matching private key.

•

Decrypting Data

So you've passed your public key to the sender, they've used it to encrypt your sensitive data, and have emailed you the encrypted results. From your mail client, save the encrypted data to a text file - it's ok to leave headers and such in the file, the decryption program will ignore it.

To decrypt, you'll do this:

c:\>gpg -o example.xls --decrypt example.xls.asc

You need a passphrase to unlock the secret key for
user: "Leo A. Notenboom <example@ask-leo.com>"
2048-bit ELG-E key, ID 1B917E56, created 2006-03-08 (main key ID 874A3EC1)

gpg: encrypted with 2048-bit ELG-E key, ID 1B917E56, created 2006-03-08
      "Leo A. Notenboom <example@ask-leo.com>"

The "-o" parameter specifies the name of the decrypted file to create. Note that you still needed to enter the passphrase for your private key. This has nothing to do with the data you are decrypting, but rather is an additional layer of protection on your private key. Without a passphrase (which is possible), anyone who gains access to your private key would be able to decrypt any messages intended for you.

•

Security

It's that last point that is perhaps the most important, and that I want to emphasize. Your private key is this technique's weakest link. If your private key is compromised ... meaning that an unauthorized person gets a copy, and is able to guess or get the passphrase on it ... then your security has been breached.

For simple use cases such as this example, you'd simply generate a new key pair, and instruct your sender(s) to use your new public key. However if your usage is widespread, getting that replacement key "out there" can be a challenge. In fact, GPG includes an entire infrastructure around trust, key validation, key revocation, key expiration and so on dedicated to maintaining the integrity of public and private keys.

But it really all boils down to: key your private key secure.

In this scenario, I've glossed over many of the aspects of public/private key security in order to keep the instructions simple.

I've also glossed over many of the capabilities of this infrastructure, perhaps the most notable is "signing". Signing allows me to "sign" data using my (closely guarded) private key in a way that can then be validated by anyone using my public key. Validation proves that a) I, as sole holder of the private key, sent it, and b) the contents of the message was not altered. Both very powerful concepts that are missing from the basic email structure.

If security, encryption and validation are important concepts that you see a large need for, it would make sense to investigate the alternatives and add-ons available for your email clients and infrastructure, paying particular attention to cross-client compatability.

But in the mean time, the approach above can serve you well.

Related:

• Ask Leo! - Just how secure is email, anyway?

• Ask Leo! - How do I create and use Public Keys with SSH?

• Ask Leo! - Is an https connection really all that safe?