How to use GPG

This page is a brief overview of how I use gpg on a regular basis. It’s mostly a brief introduction to signing keys and then setting up the Evolution email client to sign your emails automatically. Further information can be found in the man / info pages for gpg.

Signing Another Person’s Key

After you have performed sufficient verification that the name and email address(es) belong to the person who claims them, it is time to sign the key. It is important to emphasize that signing a key indicates that you have performed careful checking of the identity and verification that the information is correct! Please don’t weaken the global web of trust by arbitrarily signing keys without doing your research! Most people have some sort of a key signing policy – you can view mine here.

The first step is to get a copy of the person’s public key. It may be on a public key server, or the person may send you a copy. Please respect the person’s decision on whether or not to post their key on a server. That is, if they sent you a copy, don’t go and upload it yourself to a key server. If the public key is on a server, use this command to import it:

gpg --recv-keys <key id>

Otherwise, if a copy was sent to you, use this:

gpg --import <key file.asc>

Next you need to verify that the key you just imported matches the information that you have previously verified:

gpg --fingerprint <key id>

You must make sure the full key fingerprint and the uid(s) listed match exactly the information you have. If they don’t, double check that you’ve got the right key and then contact the person whose key you’re trying to sign if the information still doesn’t match.

Now you can sign the key! If the key only has one uid, or you don’t mind signing all the uids (in my opinion, this is a very bad idea!) you can just issue a command like this (make sure to change the URL to point to your own signing policy, if you have one – otherwise, remove the option):

gpg --sign-key --cert-policy-url "https://calenhad.com/about/gpg-signing" --ask-cert-level <key id>

Then follow the prompts and enter your secret key’s passphrase when asked. Export your new signature with this command:

gpg -a --export <key id> > <signed key.asc>

However, if there is more than one uid that you need to sign, the process is a little more complex. Use the same command as above to start the signing process:

gpg --sign-key --cert-policy-url "https://calenhad.com/about/gpg-signing" --ask-cert-level <key id>

You will see this prompt Really sign all user IDs? to which you should answer no. You will be brought to a prompt which asks you to select which uid you wish to sign. For example, if you want to sign the first uid, type “1” and press enter. (Notice that there is now an asterisk next to that uid, showing that it has been selected.) Then enter the sign command and follow the prompts, entering your secret key’s passphrase when asked. Finally, type save to save and exit gpg. Then export your new signature:

gpg -a --export <key id> > <signed key - uid address.asc>

Here’s the difference compared to signing just a single uid. You need to now delete and re-import the key you are signing to erase the signature you just made and then exported. This is because if you were to sign the next uid and export it, that exported key would contain both the first and second uid’s signatures, not just the one for the second uid. Use this command to delete the key and the above steps to re-import it:

gpg --delete-key <key id>

Having completed the signing process, you now need to send your new signature(s) back to their owner. I recommend encrypting your signature(s) (gpg -a -e -r <uid's email> -o <encrypted signature.asc> <exported signature.asc>) and sending them back to the email address corresponding to the specific uid. This ensures that the owner of the key has access to both the email address and the secret key. They can then upload your signature to a public key server after importing it (gpg --send-key <their key id>), if they wish. Of course, you could directly upload the signature yourself, but I advise against it.

More details about what signature level to use and how to prove identity are covered in my signing policy.

Signing Emails in Evolution

If you use the Evolution email client, you can easily configure it to sign and encrypt emails automatically. (This is partially why I use it.) Go to Edit->Preferences and click “Mail Accounts”. Select your email account and click “Edit”. Open the “Security” tab. What needs to be modified is under the “Pretty Good Privacy (PGP/GPG)” header. If you have more than one private key, you’ll need to tell Evolution which one to use for signing by entering its key id. If you’ve just got one secret key, you can leave this field blank and it will automatically be selected. For the signing algorithm, select at least SHA256 and tick “Always sign outgoing messages” and “Always encrypt to myself”. Optionally, tick the last option “Always trust keys” if you want to encrypt to people whose key you haven’t yet signed / marked as trusted. Save the settings, and now your emails will be signed automatically!

Creating Cool Graphs with sig2dot

After you’ve been using gpg for a while and collected some signatures, you may want to see a visualization of your web of trust. A quick Google search will report several options, but the one I’ve chosen to use is sig2dot. Once you’ve downloaded it, just run this command to create a postscript image of your web of trust which you can then convert to any format you desire:

./trustgraph.sh <key id>

This is how I create the image for my key signing policy page, though I have modified the script somewhat to suit my fancies. As a bonus, you can also practice your graph theory on your very own unique graph!

Revision History