S³'s GPG Guide

GPG

GPG stands for GNU Privacy Guard. It is a very useful encryption tool. You can find instructions on getting and installing it from the official GPG site. I will cover some basic hints for using it. Similar information can be found in Gentoo's GPG guide.

If you are still confused after reading this guide, feel free to e-mail me to ask me questions.

Making your key pair

Asymmetric encryption uses key pairs: a public key and a private key. The public key is considered to be known by everyone. The private key is known only to you. It serves as a form of identity. The first step in using GPG (unless you are only using it to verify signatures) is to generate a key pair.

To generate a key pair, use the command:

gpg --gen-key

It will prompt you which type of encryption you want to use. You can stick with the defaults. Then it will prompt you for the key size. A bigger key will take longer to generate and use, but will be safer from attack. Usually the time needed is not significant on a modern computer, so you can use the biggest length key.

The next step is to pick when the key will expire. Usually you do not need the key to expire, so you can enter 0 for never.

After that, it will prompt you for the basic human-readable information contained in your public key. You can put in your name, e-mail address, and optionally a comment to describe the key, such as if it is your personal key or for secure e-mail at work. Note that you can type anything for your name, as can anyone else. Thus, it is important to tell your friends that your specific key is actually yours, despite that other keys might be similarly named.

The final step before key pair generation is to put a password to use on the private part of the key. If you do this, the private key will only exist in encrypted form on the disk. This will prevent people with access to your disk (such as the system administrator, or your children) from gaining access to your private key. However, if it is encrypted with a password, that means that your will have to enter your password whenever you use it. This makes it unsuitable for scripts. (I have 2 keys that I commonly use: a password protected one for e-mail, and an unprotected one for scripts.)

Now you should have a key pair ready for your use.

Swapping keys

Private keys are a form of identity. Messages can be marked as belonging to a key or being decryptable by a key. The result of this is that you will need to tell your friends your public key and have them tell you their public key.

To see what keys you currently have:

gpg --list-keys

There are several ways to give your friends your public key. You can save it as a text file and give them that file (for example, by attaching it to an e-mail).

To print out your public key as text: (where NAME is the name that you used for the key or the "key ID" number next to the key when you list it)

gpg -a --export NAME

Similarly, to import your friends key, (where the file is named friend.key), you can use the command:

gpg --import < friend.key

If you don't use the --import option, it will just print out the information about the key instead of adding it to your key chain.

To make key exchange easier, you can upload your key to a key server and then tell the key ID of that key to your friends so they can grab it from the server. Note that this key ID can be found from --list-keys.

To upload the key (KEYID) to the key server (HOST):

gpg --keyserver HOST --send-keys KEYID

To get a key given its KEYID from the key server (HOST):

gpg --keyserver HOST --recv-keys KEYID

Now you should have your friends' keys and they should have yours. Now you can start talking to each other securely. As an explicit example, to get my key, you can do:

gpg --keyserver pgp.mit.edu --recv-keys AB4871FB

Note that some places have PGP key swapping parties. If you go to one, afterwards, it is expected that you send out your signatures of other people's keys. I have a script that can simplify this process: Python script (sig)

Signing messages

Now that we have covered the basics, we can start the fun part. One of the most basic tasks is to send signed e-mails. (This is the main purpose that I use gpg for.) This signature allows the recipient of the message to tell that the person who signed the message knew the private key of the key pair using the public key. If the message is altered at all, the signature will not verify (up to a very tiny probability). Since the from field in e-mail headers is trivially spoofed (you can type anything there that you like), this is a good way to show that the message actually came from you instead of someone pretending to be you.

To sign a message: (where message.txt is the original and message_signed.txt is the resulting signed message)

gpg --clearsign < message.txt > message_signed.txt

--clearsign makes sure to leave the message humanly readable for people who don't have gpg. Note that since it is plain text, you can post it just about anywhere. You can send it as e-mail, post it on a forum, or just keep it in a text file. If you know that the recipient has gpg, there are other ways to have a signed message.

For a signed, text-compatible message:

gpg -a -s < message.txt > message_signed.asc

Or, for a signed, binary message:

gpg -s < message.txt > message_signed.gpg

To check the signature:

gpg < message

If the message is not corrupt, it should say "gpg: Good signature".

Sometimes it is not convenient to have the signature as part of the file. For this purpose, there are detached signatures. These are when you have a file named similarly to another file that contains the signature for it.

To create a detached signature for file:

gpg -b file

This will create a file named file.sig that contains the signature for file. So, file can still be used as usual, but can be verified using the signature in file.sig.

To verify the detached signature:

gpg file.sig

Again, this will make gpg say "gpg: Good signature".

Using this, you can do some neat tricks. Often, tar (TApe aRchive) is used for archiving groups of files. You may commonly see tar.gz and tar.bz2 for compressed archives. Using gpg, you can make a compressed archive that also has a signature to verify its integrity. This way you will know that it is the actual archive that you created.

To create a signed archive of a directory:

tar c directory/ | gpg -s > directory.tar.gpg

To extract this archive to recreate the directory:

gpg < directory.tar.gpg | tar x

This will extract the contents of the archive, and, when it is done, tell you whether it is properly signed or not.

Encrypting messages

There are 2 ways to encrypt a message. You can encrypt it with a password (symmetric) and you can encrypt it with someone's public key (asymmetric). If a message is encrypted with a password, you need that same password to decrypt it. If a message is encrypted with a public key, the corresponding private key is needed. Usually, for communication, I encrypt with a public key. To backup the keys themselves, I use a password.

To encrypt file with a password:

gpg -c < file > file.gpg

Then put in your password when it prompts you. This is called symmetric encryption because the same password is used for encrypting as decrypting.

To encrypt a file with NAME's public key:

gpg -e -r NAME < file > file.gpg

Note that these different options can be combined in different ways. So, for example, you can do

gpg -a -s -c -e -r NAME1 -r NAME2 < file > file.asc

which gives you a text version of the file that is signed, encrypted with a password, and encrypted with the public key of 2 different people. Often, you want to specify the intended recipient of a message and yourself, so you can read your own messages after you encrypt them.

Now you should be able to have secure communications and backups using gpg.

Trust

Just seeing that a person's name is on a key does not necessarily mean that that key belongs to that person. When creating a key, I can just as easily type a celebrity's name as my own. Also, names do not uniquely identify a person, so it could be a different person with the same name. To help tell if a key really belongs to the person you're thinking of, GPG uses a "web a trust". Just like how you can sign messages, you can sign keys to show that you trust them. This allows you to estimate how much you can trust an unknown key by how far away from you it is in the graph. If your friend signed the key, chances are it is legitimate. If GPG can't determine that you trust a key, it will issue a warning.

Signing a key means that you have verified the identity of the person. If you have known them for a while or seen their photographic ID, you can sign their key saying that you believe that the key belongs to that person. For key management tasks like this, GPG has an interactive key editing mode.

Signing NAME's key:

gpg --edit-key NAME
sign
y
save

It will prompt you if you really want to sign it. Say yes and save. If the key previously had a trust of "unknown", now it should say "full". There are other trust levels that you can set manually.

Like how you could upload your own key to the keyserver, you can also upload your signatures of other people's keys to the keyserver. This will allow other people to see which keys you endorse, giving them more information for whether they should trust those keys or not. Similarly, when you recieve a key, you will download all of the signatures that it has as well. Note that if you don't want a signature to go to a keyserver, you can use "lsign" (local sign) instead of "sign". This will flag the signature that it is only for the local machine.

Send your signature of KEYID's key to HOST:

gpg --keyserver HOST --send-keys KEYID

If somehow the trusts are not updated properly after signing, you can tell gpg to check through the signatures again and update the trust database.

Check trust database:

gpg --check-trustdb

If the trust still is not at the correct level, you can manually set how much you trust the key.

Manually setting NAME's trust to marginal:

gpg --edit-key NAME
trust
3
save

For example, if you know that a person does not typically check keys rigorously before signing them, you can set their trust to marginal. You can set it to fully if you do trust them to check keys before signing them.

Now you can make reasonable guesses as to if the key is valid even if you do not know the person directly. Of course, this doesn't mean that you shouldn't try to verify the identity of the person once contact is established. There is no substitute for that.

Personally, I prefer this trust model over the certificate authority model used for HTTPS. The certificate authority model usually shows that you paid a company a certain amount of money for a certificate and very little is actually done to verify identity. This way, your friends have verified the identity. I know my friends much better than a random company and thus am more likely to trust their opinions.