Issue #6 April 2005

It's 2 a.m., do you know who's reading your email?

Introducing GPG

Email is inherently insecure. Messages can be intercepted or read by people other than the intended recipient. As anyone that has received spam can attest, they can also be forged to look like they come from someone else.

GPG (GNU Privacy Guard or GnuPG) is a suite of tools to address these issues. It implements the OpenPGP standard, making GPG compatible with all other applications that follow this standard.

Note:
The OpenPGP standard was originally based on PGP (Pretty Good Privacy).

GPG can secure your email in two distinct ways:

  • Encrypt email such that only the intended recipient can read it
  • Sign email so that recipients can verify both the sender's identity and the integrity of the message

How GPG works

Although it is not necessary to completely understand the inner workings of GPG, knowing the basics can prevent some common mistakes that could compromise your email security.

Introducing the keys

GPG uses public-key cryptography. This means that every user has their own pair of keys, the public key and the private key. These two keys work in tandem as both are necessary for GPG to work. They are created at the same time and complement each other like adjacent pieces of a jigsaw puzzle.

The public key is shared and given to your correspondents. These correspondents can use your public key to encrypt email meant only for you.

Once you receive an email encrypted with your public key, you can decrypt it with your private key. Keeping your private key secret guarantees that you are the only person who can decrypt this email.

Important:
Never give anyone access to your private key. It should be kept as safely as your passwords and PINs.

Your pair of keys are also useful for digitally signing your outgoing email. This signature proves two things:

  • You are the sender.
  • The message has not been altered in transit.

The recipient of your email would use your public key to verify your digital signature. If it matches, they know that those two points are true.

Note:
Signing an email does not encrypt the message. Encrypting a message with your private key is useless as your public key is available to everyone.

Now that you know what the keys are for, let us create some of our own.

Starting with GPG

Creating your keys

Fedora Core and Red Hat® Enterprise Linux® have the gnupg package installed by default. If you do not have it on your system, package locations and installation instructions can be found at the GnuPG website. Fedora Core 3 and Red Hat Enterprise Linux 4 both contain GPG version 1.2.6. This is the version I am using, but most recent versions should behave similarly.

Once GPG is installed in your system, open a terminal. In your home directory, enter:

mkdir ~/.gnupg

This command creates the directory for GPG to put its files.

Note:
If you are using a later version of GPG, you may not need to create this directory. Newer versions will create this directory automatically.

Next, enter:

gpg --gen-key

The command will show output similar to Example 1, “Generating keys”, where homedirectory is your home directory.

gpg (GnuPG) 1.2.6; Copyright (C) 2004 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.

gpg: keyring `/home/homedirectory/.gnupg/secring.gpg' created
gpg: keyring `/home/homedirectory/.gnupg/pubring.gpg' created
Please select what kind of key you want:
   (1) DSA and ElGamal (default)
   (2) DSA (sign only)
   (4) RSA (sign only)
Your selection?
	
Example 1. Generating keys

Select (1) to choose both the signature and encryption capabilities. Next, it asks what size you want your key to be as shown in Example 2, “Key size prompt”. The default size of 1024 bits is generally thought to be a good size. Press enter.

DSA keypair will have 1024 bits.
About to generate a new ELG-E keypair.
              minimum keysize is  768 bits
              default keysize is 1024 bits
    highest suggested keysize is 2048 bits
What keysize do you want? (1024)
	
Example 2. Key size prompt

The computer outputs Requested keysize is 1024 bits to verify your choice. The next question asks how long until you want the key to expire as shown in Example 3, “Expiration setting”. The default action is for it to never expire. For most people, this choice is the best. Select it. You are prompted again to make sure your choice is accurate. Enter y.

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)
	
Example 3. Expiration setting
Note:
Although it is relatively easy to change the expiration date at a later time to renew the key, it is hard to propagate this information. Others may not know that your key has been renewed making it useless.

The next set of prompts ask for your name and email address. Enter your information. The prompt for a comment is optional. This field allows you to enter a small description of your key. If you have more than one key (one for work use and one for personal use, for example) you can use this field to state that.

Caution:
Remember that this key you are creating is to be used to authenticate your identity. There is no point in creating a pair of keys that do not have your real name and email address attached.

You are then prompted to make sure that these fields were entered correctly. If so, enter O to continue.

The next prompt asks you to enter a passphrase. This passphrase can be as long as you like it to be. You need to enter it in twice to limit the chance that you mistyped.

Warning:
This passphrase allows you to access your private key. Make sure to keep it in a safe place. However, be careful not to forget this passphrase, as you cannot use your key without it.
Note:
For security reasons, your private key is not actually stored on disk. That way, if someone obtains access to your computer, your private key is not compromised. What your computer keeps is a file which when combined with your passphrase, remakes your private key.

As the keys are being generated, it asks you to move your mouse around or type something in another window to generate random data. When it is done, the computer outputs lines similar to those shown in Example 4, "GPG output". The front part of your email address (the part before the '@' sign) is considered your username in GPG.

gpg: /home/homedirectory/.gnupg/trustdb.gpg: trustdb created
public and secret key created and signed.
key marked as ultimately trusted.

pub  1024D/6A39B08B 2005-03-25 Firstname Lastname <emailaddress@example.com>
     Key fingerprint = 53E7 401C A221 63CA BE99  B0A5 D6D7 F69C 7B9D A26B
sub  1024g/28D1B77E 2005-03-25
	
Example 4. GPG output

Success! Your GPG keys have been generated. In this example, 6A39B08B is the key ID. This key ID is a way to identify the key. If you do not remember your key ID, you can enter gpg --list-keys. Your key ID is the eight digit alphanumeric token listed on the line with your name.

Creating a revocation certificate

Because you may at some point forget your passphrase, it is a good idea to create a revocation certificate right away. This certificate is only to be used in an emergency. Either you have lost your passphrase and would not be able to read any email encrypted with your public key or someone has discovered your passphrase and your private key has been compromised. Either way, having a revocation certificate handy is a good thing.

To create a revocation certificate, enter the following with your key ID instead of keyID:

gpg --output revoke.asc --gen-revoke keyID
Tip:
If your username is unique in your keyring, you can use that instead of the key ID.

You are prompted for a reason. As you currently do not have a reason to revoke your keys, enter 0. Leave the description blank as well. Next you are prompted for your passphrase. Enter that correctly and your revocation certificate is created as the file revoke.asc. Put this file in a safe place. Hopefully you will never need it.

Sharing public keys

Now that you have your own pair of GPG keys, you need to let people know. You have a choice of either sending your public key directly to your correspondents or to post it to a key server. Although a key server is convenient, it does have its detractions. Positives and negatives are shown in Table 1, “Pros and cons of uploading your public key to a key server”.

Pros Cons
Upload once and anyone in the world can find it. You cannot control who has access to your public key.
Ability to find your public key when away from your computer. Your name and email address are widely available for anyone to see.
Once a key is in a key server, it cannot be removed.
Table 1. Pros and cons of uploading your public key to a key server

Sending your public key to a key server

If you decide to send a key to a key server, enter the following in your terminal substituting in your key ID:

gpg --keyserver pgp.mit.edu --send keyID

Here we are using the MIT PGP public key server. There are others available, but as most major key servers synchronize their data on a regular basis, it does not really matter which one you choose.

Giving your public key to a correspondent

Even if your public key is easily accessible on a key server, you may want to have your key available elsewhere. You could place it on your personal website, send it to your friend in an email, or even put it in your email signature.

Note:
To be perfectly safe, public keys should be transferred in person. That way, the parties involved know for certain that the public key is valid and can be trusted. However, that is often impractical, leading many to share their public keys via email or on a key server.

Although it is possible to give someone your public key in its regular format, it is much easier to handle when it is converted into ASCII. To do that, enter the following in a terminal:

gpg --armor --export keyID > filename.asc

The resulting file filename.asc is a short ASCII file that can be easily transported.

Getting public keys

If a correspondent sends you a copy of their public key, and you want to add it to your GPG keyring, you can add it to your keyring with the following in a terminal by replacing keyname with the name of the file with the key:

gpg --import keyname
Note:
You can import keys with both .gpg and .asc extensions in this manner.

Upon successfully adding a key to your keyring, the first thing you need to do to use it is to sign it. Signing your correspondent's public key tells GPG you trust that this key belongs to your correspondent.

Important:
GPG is only useful as long as only trusted keys are signed. When in doubt, do not sign the key.

To sign a key, enter the following:

gpg --edit-key keyID

This command produces output similar to Example 5. “Signing a key”.

gpg (GnuPG) 1.2.6; Copyright (C) 2004 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.


pub  1024D/D8D464DC  created: 2001-07-22 expires: never      trust: -/-
sub  2048g/52ACFCBD  created: 2001-07-22 expires: never
(1). Firstname Lastname <username@example.com>
	  
Example 5. Signing a key

If the key contains multiple email addresses and you only want to sign one of them, enter uid 1 (or whatever the number to the left of the email address is). Enter sign at the next prompt. You are next asked how much you trust this key. If you are certain, select 3. GPG once again asks you if you are certain you want to sign this key. Agree and enter your passphrase at the prompt. Enter save and your correspondent's key has been signed.

Using Evolution with GPG

Note:
At times, Evolution refers to GPG as PGP. Within Evolution, consider these terms as interchangeable.

Setting up Evolution to use GPG is straightforward and easy. In the Evolution menu, select Tools -> Settings.... From the Evolution Settings window, and select Mail Accounts. Select your primary email account from the list, and select Edit. In the Evolution Account Editor window, select the Security tab as shown in Figure 1, Evolution security settings.

Evolution security settings
Figure 1. Evolution security settings

In the first text entry, enter your key ID. If you want your digital signature on all your outgoing mail, select the first checkbox. If you have correspondents who use Outlook, you may want to select the second checkbox as well.

Selecting the third checkbox would mean that Evolution encrypts the copy of the email in your sent folder (with your own private key) when you encrypt the original with your correspondent's public key. This option is useful if your mailbox is not as secure as you would like.

The fourth checkbox should remain unchecked as it defeats the purpose of signing public keys. Of course, if you trust every key you put in your keyring, you can select this option and not bother signing any of the keys, but if you ever need these keys for anything other than Evolution, you would have a lot of signing to do.

Select OK and Evolution is set up to use GPG.

Sending securely

To send a signed and encrypted email, in the composition window select Security -> PGP Sign and Security -> PGP Encrypt as shown in Figure 2, “Signing an email”.

Signing an email
Figure 2. Signing an email
Note:
Make sure that you have the recipient's public key in your keyring. If you do not have the key, Evolution gives you an error message.

For correspondents that do not have accessible public keys, you can send signed but unencrypted email.

Receiving signed email

When you receive a signed email from a correspondent and you have their public key in your keyring, Evolution lets you know by stating this at the bottom as shown in Figure 3, “A signed email”. Clicking on the icon brings up a Security Information window with the details on the digital signature.

A signed email
Figure 3. A signed email

Reading encrypted email

When you receive an encrypted email, trying to open it causes Evolution to prompt you for your passphrase. Once entered, the email is shown just like any other email. However, closing this message and reopening it causes Evolution to prompt you again for your passphrase before you can view the message.

Caution:
Evolution allows you to have it remember your passphrase until you exit the application. For security reasons, never select this option unless you know for certain you will not leave your computer until you do so.

Revoking your keys

If your private key has been compromised or you have forgotten your passphrase, you need to revoke your key. Remember the revocation certificate we created in the section called “Creating a revocation certificate”? You need that file now.

Warning:
Revocation is not reversible. Do not use the revocation certificate unless absolutely necessary.

In a terminal, enter:

gpg  --import revoke.asc

Regardless of whether you originally placed your public key in a key server, you want to send the revoked certificate to one. The point is to let as many people know that this certificate has been compromised. Send it to the key server by entering with your key ID as keyID:

gpg --keyserver pgp.mit.edu --send keyID

Even after a key pair has been revoked, you can still decrypt old emails associated with that key with the passphrase. However, make sure you create a new key pair and send your new public key to your correspondents as soon as possible so that they can continue to send you your email securely.

Further reading

About the author

Rosanna Yuen is an avid computer user who often finds herself surrounded by computer programmers. She co-wrote AisleRiot and is a dabbler in the GNOME project. In her spare time, she reads, knits, and experiments in her kitchen.