I need to have a client send me some very sensitive
information. Really really sensitive. I know that email is fundamentally
insecure, so I want the email to be encrypted. What’s the best way to do that.
Did I mention it’s sensitive?
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.
Become a Patron of Ask Leo! and go ad-free!
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.
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
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
In the Windows Command Prompt, enter gpg –gen-key. In the
following sequence, your responses are in bold:
gpg (GnuPG) 188.8.131.52; 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) <firstname.lastname@example.org>" Real name: Leo A. Notenboom (Use your own name) Email address: email@example.com (Use your own email address) Comment: ENTER to accept the default You selected this USER-ID: "Leo A. Notenboom <firstname.lastname@example.org>" 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 <email@example.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 firstname.lastname@example.org >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.
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
They start by “importing” your public key onto their keyring:
c:\>gpg --import mykey.pub gpg: key 874A3EC1: public key "Leo A. Notenboom <email@example.com>" imported gpg: Total number processed: 1 gpg: imported: 1
Now they’re ready to encrypt. That looks like this (encrypting the example
c:\>gpg -a --encrypt -r firstname.lastname@example.org example.xls gpg: 1B917E56: There is no assurance this key belongs to the named user pub 2048g/1B917E56 2006-03-08 Leo A. Notenboom <email@example.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
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
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 <firstname.lastname@example.org>" 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 <email@example.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.
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
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.