This chapter is from the book
This chapter is from the book
This chapter is from the book
Working with Keys
Before you can encrypt or decrypt and messages, files, or other data, you'll need to learn to collect, use, and validate GPG keys to ensure the integrity of the data you'll be exchanging.
The primary tools for working with keys which we'll discuss here are listing keys, key importing, key exporting, key signing, and user trust.
Listing Keys
Throughout the rest of this chapter, it will be very helpful to you to be able to list the keys in your own public key database. To obtain a list of keys in your "keyring" and the matching names and e-mail addresses of their owners, use the following:
$ gpg --list-keys /home/joe/.gnupg/pubring.gpg pub 1024D/D9BAC463 2001-01-03 Joe User (PGP Rules!) <joe@mynet.net> sub 1024g/5EE5D252 2001-01-03 pub 1024D/4F03BD39 2001-01-15 Pipi Socks (I'm WIRED) <pipi@hairnet.org> sub 1024g/FDBB477D 2001-01-15 $
Each entry in the list represents a public key that you have on file and which can be used to encrypt data sent to the matching e-mail address.
Importing and Exporting Keys
The process of importing and exporting public keys is the meat-and-potatoes of the PGP world because it is only when a potential recipient has your public key already that you are able to make use of PGP in messages or data sent to him or her. Likewise, any number of potential senders may want you to have their key so that they can send you secure information.
The first step is to learn to export your own key so that you can provide it to others. This is done with the --export argument. For example, if you're joe, you can export your own public key to the file mykey.gpg like this:
$ gpg --export joe@mynet.net >mykey.gpg $
The public key for joe@mynet.net is now stored in mykey.gpg and can be supplied to friends, family, or co-workers that joe may wish to communicate with in a secure way. Unfortunately, the key is not in an easily readable format; it looks like a lot of garbage and isn't pleasant at all. It is therefore common practice to communicate keys and other types of PGP information in ASCII format, suitable for including in an e-mail message. This is done with the -a argument:
$ gpg -a --export joe@mynet.net >mykey.gpg $
The new mykey.gpg is very nicely formatted and contains the same information—joe's public key and general identification strings. Keys can be imported in similar fashion:
$ gpg --import pipiskey.gpg $
Once Pipi's key has been imported, joe can send encrypted messages to Pipi or receive signed messages from Pipi using her public key. The same holds true for Pipi, assuming that she imports the copy of joe's key that joe exported.
Signatures and Trust
If you're following along and experimenting, you may have noticed that GPG isn't so quick to trust an imported key—there's actually quite a bit more output that is shown here. This is because the PGP scheme depends on the validity of public keys. That is to say that if lots of faked public keys start being passed around so that a public key which claims to be from Pipi is really from Joan instead, the whole security model breaks.
Therefore, GPG includes a complex trust system designed to help you decide which keys are real and which keys aren't, based on evidence included with the key. This trust system involves the signing of keys by other individuals who believe the key to be authentic.
When you receive a new public key from someone you know and GPG informs you that there isn't any solid trust information available for the key you've received, the first thing you should do is fingerprint the key. To illustrate, let's suppose that you have just imported Pipi's key, and GPG has informed you that no trust information for this new key exists.
The first thing you need to do is run a fingerprint on the new key:
$ gpg --fingerprint pipi@hairnet.org pub 1024D/4F03BD39 2001-01-15 Pipi Socks (I'm WIRED) <pipi@hairnet.org> Key fingerprint = B121 5431 8DE4 E3A8 4AA7 737D 20BE 0DB8 4F03 BD39 sub 1024g/FDBB477D 2001-01-15 $
This fingerprint is generated from the data in the key and is reasonably unique. You then phone Pipi to ask her two questions. First, has she just sent you a key, and, next, what is the fingerprint of her public key?
If Pipi answers that she has indeed just sent you a key and the fingerprint matches the one you've generated, you know firsthand that the key is valid. You can then sign the key, in effect stating that this key is Pipi's and you trust her.
$ gpg --sign-key pipi@hairnet.org pub 1024D/4F03BD39 created: 2001-01-15 expires: never sub 1024g/FDBB477D created: 2001-01-15 expires: never (1) Pipi Socks (I'm WIRED) <pipi@hairnet.org> pub 1024D/4F03BD39 created: 2001-01-15 expires: never Fingerprint = B121 5431 8DE4 E3A8 4AA7 737D 20BE 0DB8 4F03 BD39 Pipi Socks (I'm WIRED) <pipi@hairnet.org> Are you really sure that you want to sign this key with your key: "Ima User (I'm just ME) <me@mynet.org>" Really sign? y You need a passphrase to unlock the secret key for user: "Ima User (I'm just ME) <me@mynet.org>" 1024-bit DSA key, ID D9BAC463, created 2001-01-03 Enter passphrase: $
This key has now been signed with your private key; anyone holding your public key can verify that the signature is indeed yours. The signature you have added to Pipi's public key will travel with it anywhere it goes, your personal guarantee that this key is indeed Pipi's key.
To get a list of the signatures associated with a public key in your personal keyring, use the --check-sigs argument:
gpg --check-sigs pipi@hairnet.org
The longer the list of signatures, the more valid a key can be assumed to be. It is this system of signatures which provides key verification. Suppose you receive a key which has been signed by Pipi—you will know that it is really her signature because it can be verified with her public key—which you have just signed as authentic. Assuming that you trust Pipi, you can then trust as real any key which Pipi has signed. This web of trust, as it is called, can continue much farther than any one e-mail user can reach, ensuring that people are who they claim to be.
What happens, however, when a key only has a small number of signatures, or even just one signature, from a signer who either is dubious in his or her own identity or is too lax with his or her signatures, simply signing any key that passes through?
To combat this potential for trust dilution, GPG includes one additional resource, the trust level. With it, you can indicate the degree to which you trust the owner of any key you have. For example, suppose that even though you know Pipi's public key is authentic, you don't actually trust her judgment when it comes to signing other keys. You think that Pipi may just sign a few keys without checking them out. You can set the trust level with the --edit-key command.
$ gpg --edit-key pipi@hairnet.org pub 1024D/4F03BD39 created: 2001-01-15 expires: never trust: -/f sub 1024g/FDBB477D created: 2001-01-15 expires: never (1) Pipi Socks (I'm WIRED) <pipi@hairnet.org> Command> trust 1 = Don't know 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully s = please show me more information m = back to the main menu Your decision? 2 Command> quit $
By using the trust command in the key editor and selecting trust level 2 ("I do NOT trust"), you have invalidated any trust chain which must pass through Pipi's signatures.
Of course, when GPG asks you about a questionable key, you will always be able to force GPG to use it, regardless of the degree to which it can be trusted. The trust system provides a way for you as a GPG user, however, to know which keys are certainly valid, which keys may be valid, and which keys are almost certainly not valid.