Creating Your Key

You are first asked to select the kind of key you want. Normally, you would just select the default entry, which you can do by pressing the ENTER key. Then you choose the key size, usually the default 1024. You then specify how long the key is to be valid—usually, there is no expiration. You will be asked to enter a user ID, comment, and e-mail address. Press ENTER to be prompted for each in turn. These elements, any of which can be used as the key's name, identify the key. You use the key name when performing certain GPG tasks such as signing a key or creating a revocation certificate. For example, the following elements create a key for the user richlp with the comment "author" and the e-mail address richlp@turtle.mytrek.com:

Richard Petersen (author) <richlp@turtle.mytrek.com>

You can use any unique part of a key's identity to reference that key. For example, the string "Richard" would reference the preceding key, provided there are no other keys that have the string "Richard" in them. "richlp" would also reference the key, as would "author". Where a string matches more than one key, all the matched ones would be referenced.

Protecting Your Key

The gpg program will then ask you to enter a passphrase, used to protect your private key. Be sure to use a real phrase, including spaces, not just a password. gpg then generates your public and private keys and places them in the .gnupg directory. The private keys are kept in a file called secring.gpg in your .gnupg directory. The public key is placed in the pubring.gpg file, to which you can add the public keys of other users. You can list these keys with the --list-keys command.

In case you later need to change your keys, you can create a revocation certificate to notify others that the public key is no longer valid. For example, if you forget your password or someone else discovers it, you can use the revocation certificate to tell others that your public key should no longer be used. In the next example, the user creates a revocation certificate for the key richlp and places it in the file myrevoke.asc:

gpg --output myrevoke.asc --gen-revoke richlp

Making Your Public Key Available

For other users to decrypt your messages, you have to make your public key available to them. They, in turn, have to send you their public keys so that you can decrypt any messages you receive from them. In effect, enabling encrypted communications between users involves all of them exchanging their public keys. The public keys then have to be verified and signed by each user who receives them. The public keys can then be trusted to safely decrypt messages.

If you are sending messages to just a few users, you can manually e-mail them your public key. For general public use, you can post your public key on a keyserver, which anyone can then download and use to decrypt any message they receive from you. The OpenPGP Public Keyserver is located at www.keyserver.net, which is listed in your .gnupg/options file. You can send directly to the keyserver with the -keyserver option and --send-key command. The --send-key command takes as its argument your e-mail address. You need to send to only one keyserver, as it will share your key with other keyservers automatically.

gpg --keyserver search.keyserver.net --send-key chris@turtle.mytrek.com

If you want to send your key directly to another user, you should generate an armored text version of the key that you can then e-mail. You do this with the --armor and --export options, using the --output option to specify a file to place the key in. The --armor option will generate an ASCII text version of the encrypted file so that it can be e-mailed directly, instead of as an attached binary. Files that hold an ASCII encoded version of the encryption normally have the extension .asc, by convention. Binary encrypted files normally use the extension .gpg. You can then e-mail the file to users you want to send encrypted messages.

# gpg --armor --export richlp@turtle.mytrek.com --output richlp.asc
# mail -s 'mypubkey' george@rabbit.mytrek.com < richlp.asc

Many companies and institutions post their public key files on their Web sites, where they can be downloaded and used to verify encrypted software downloads or official announcements.

Obtaining Public Keys

To decode messages from other users, you will need to have their public keys. They can either send them to you or you can download them from a keyserver. Save the message or Web page containing the public key to a file. You will then need to import, verify, and sign the key. Use the file you received to import the public key to your pubring file. In the following example, the user imports George's public key, which he has received as the file georgekey.asc.

gpg --import georgekey.asc

All Linux distribution sites have their own public keys available for download. You should, for example, download the Red Hat public key, which can be accessed from the Red Hat site on its security resources page (www.redhat.com). Click the Public Encryption Key link. From there, you can access a page that displays just the public key. You can save this page as a file and use that file to import the Red Hat public key to your keyring. (Your Red Hat distribution also places the Red Hat public key in the /usr/share/doc/rpm4-1 directory with versions for both GPG and PGP encryption, RPM-GPG-KEY and RPM-PGP-KEY files.) In the following example, the user saved the page showing just the Red Hat public key as myredhat.asc, and then imported that file:

gpg --import myredhat.asc

Validating Keys

To manually check that a public key file was not modified in transit, you can check its fingerprint. This is a hash value generated from the contents of the key, much like a modification digest. Using the --fingerprint option, you can generate a hash value from the key you installed, then contact the sender and ask them what the hash value should really be. If they are not the same, you know the key was tampered with in transit.

gpg --fingerprint george@rabbit

You do not have to check the fingerprint to have gpg operate. This is just an advisable precaution you can perform on your own. The point is that you need to be confident that the key you received is valid. Normally you can accept most keys from public servers or known sites as valid, though it is easy to check their posted fingerprints. Once assured of the key's validity, you can then sign it with your private key. Signing a key notifies gpg that you officially accept the key.

To sign a key, you use the gpg command with the --sign-key command and the key's name.

gpg --sign-key george@rabbit

Alternatively, you can edit the key with the --edit-key command to start an interactive session in which you can enter the command sign to sign the key and save to save the change. Signing a key involves accessing your private key, so you will be prompted for your passphrase. When you are finished, leave the interactive session with the quit command.

Normally, you would want to post a version of your public key that has been signed by one or more users. You can do the same for other users. Signing a public key provides a way to vouch for the validity of a key. It indicates that someone has already checked it out. Many different users could sign the same public key. For a key that you have received from another user, and that you have verified, you can sign and return the signed version to that user. Once you have signed the key, you can generate a file containing the signed public version. You can then send this file to the user. This process builds a Web-of-Trust where many users vouch for the validity of public keys.

gpg -a --export george@rabbit --output  georgesig.asc

The user would then import the signed key and export it to a keyserver.

Encrypting Messages

The gpg command provides several options for managing secure messages. The e option encrypts messages, the a option generates an armored text version, and the s option adds a digital signature. You will need to specify the recipient's public key, which you should already have imported into your pubring file. It is this key that is used to encrypt the message. The recipient will then be able to decode the message with their private key. Use the --recipient or -r option to specify the name of the recipient key. You can use any unique substring in the user's public key name. The e-mail address usually suffices. You use the d option to decode received messages. In the following example, the user encrypts (e) and signs (s) a file generated in armored text format (a). The -r option indicates the recipient for the message (whose public key is used to encrypt the message).

gpg e -s -a -o myfile.asc -r george@rabbit.mytrek.com myfile
# mail george@rabbit.mytrek.com < myrile.asc

You can leave out the ASCII armor option if you want to send or transfer the file as a binary attachment. Without --armor or -a options, gpg generates an encoded binary file, not an encoded text file. A binary file can be transmitted through e-mail only as an attachment. As noted previously, ASCII armor versions usually have an extension of .asc, whereas binary version use .gpg.

Decprypting Messages

When the other user receives the file, they can save it to a file named something like myfile.asc and then decode the file with the -d option. The -o option will specify a file to save the decoded version in. GPG will automatically determine if it is a binary file or an ASCII armor version.

gpg -d -o myfile.txt myfile.asc

To check the digital signature of the file, you use the gpg command with the --verify option. This assumes that the sender has signed the file.

gpg --verify myfile.asc

Decrypting a Digital Signature

You will need to have the signer's public key to decode and check the digital signature. If you do not, you will receive a message saying that the public key was not found. In this case, you will first have to obtain the signer's public key. You could access a key server that you think may have the public key, or request the public key directly from a Web site or from the signer. Then import the key as described previously.

Signing Messages

You do not have to encrypt a file to sign it. A digital signature is a separate component. You can either combine the signature with a given file or generate one separately. To combine a signature with a file, you generate a new version that incorporates both. Use the --sign or -s option to generate a version of the document that includes the digital signature. In the following example, the mydoc file is digitally signed with mydoc.gpg file containing both the original file and the signature.

gpg  -o mydoc.gpg  --sign mydoc

If, instead, you want to just generate a separate signature file, you use the --detach-sig command. This has the advantage of not having to generate a complete copy of the original file. That file remains untouched. The signature file usually has an extension like .sig. In the following example, the user creates a signature file called mydoc2.sig for the mydoc2 file.

gpg -o mydoc2.sig --detach-sig mydoc2

To verify the file using a detached signature, the recipient user specifies both the signature file and the original file.

gpg --verify mydoc2.sig  mydoc2

You could also generate a clear sign signature to be used in text files. A clear sign signature is a text version of the signature that can be attached to a text file. The text file can be further edited by any text editor. Use the --clearsign option to create a clear sign signature. The following example creates a clear signed version of a text file called mynotice.txt.

gpg -o mysignotice.txt --clearsign mynotice.txt