ProductsDesktop Server For Scientific Computing For IBM POWER For IBM System z For SAP Business Applications Red Hat Network Satellite ManagementExtended Update Support High Availability High Performance Network Load Balancer Resilient Storage Scalable File System Smart Management Extended Lifecycle SupportWeb Server Developer Studio Portfolio Edition JBoss Operations Network FuseSource Integration Products Web Framework Kit Application Platform Data Grid Portal Platform SOA Platform Business Rules Management System (BRMS) Data Services Platform Messaging JBoss Community or JBoss enterprise
SolutionsApplication development Business process management Enterprise application integration Interoperability Operational efficiency Security VirtualizationMigrate to Red Hat Enterprise Linux Systems management Upgrading to Red Hat Enterprise Linux JBoss Enterprise Middleware IBM AIX to Red Hat Enterprise Linux HP-UX to Red Hat Enterprise Linux Solaris to Red Hat Enterprise Linux UNIX to Red Hat Enterprise Linux Start a conversation with Red Hat Migration services
TrainingPopular and new courses JBoss Middleware Administration curriculum Core System Administration curriculum JBoss Middleware Development curriculum Advanced System Administration curriculum Linux Development curriculum Cloud Computing and Virtualization curriculum
ConsultingStandard Operating Environment (SOE) Strategic Migration Planning Service-oriented architecture (SOA) Enterprise Data Solutions Business Process Management
Issue #6 April 2005
- What's new in security for Red Hat Enterprise Linux 4
- Taking advantage of SELinux in Red Hat Enterprise Linux
- The security dilemma, part 2: Intrusion prevention
- It's 2 a.m., do you know who's reading your email?
- Video: See you at the Summit
- Taking your desktop virtual with VNC
- Video: Open source software licenses explained
- Video: Ticketmaster chooses Red Hat Enterprise Linux and Strongmail
- Open source in the force: One officer speaks
- Red Hat Knowledgebase: Serving apple pie to the masses
- Data sharing with a GFS storage cluster
- Red Hat Training adds Windows®-to-Linux® migration course
From the Inside
In each Issue
- Editor's blog
- Red Hat speaks
- Ask Shadowman
- Tips & tricks
- Fedora status report
- Magazine archive
It's 2 a.m., do you know who's reading your email?
by Rosanna Yuen
- Introducing GPG
- How GPG works
- Starting with GPG
- Using Evolution with GPG
- Revoking your keys
- Further reading
- About the author
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.
- 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.
- 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.
- 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
Once GPG is installed in your system, open a terminal. In your home directory, enter:
This command creates the directory for GPG to put its files.
- If you are using a later version of GPG, you may not need to create this directory. Newer versions will create this directory automatically.
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?
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)
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.
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)
- 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.
- 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
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.
- 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.
- 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 <firstname.lastname@example.org> Key fingerprint = 53E7 401C A221 63CA BE99 B0A5 D6D7 F69C 7B9D A26B sub 1024g/28D1B77E 2005-03-25
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
--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
- 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
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”.
|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.|
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.
- 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
You can import keys with both
.ascextensions 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.
- 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 <email@example.com>
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).
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
and your correspondent's key has been signed.
Using Evolution with GPG
- 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 -> . From the Evolution Settings window, and select Mail Accounts. Select your primary email account from the list, and select . In the Evolution Account Editor window, select the Security tab as shown in 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 Evolution is set up to use GPG.and
To send a signed and encrypted email, in the composition window select Figure 2, “Signing an email”.-> and -> as shown in
- 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.
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.
- 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.
- 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.
- GPG — the main GPG website
- MIT PGP Key Server — a key server to upload your public key and to find other people's keys
- Public-key cryptography — Wikipedia article on public-key cryptography
- Evolution — Documentation for Evolution's handling of encryption