Keysigning Event Guide

Table of Contents

What is this? I don’t know any of these words!

PGP (Pretty Good Privacy), and the OpenPGP standard it spawned, are the de-facto standard encryption and digital signature system in use today. It’s used to secure emails, verify the integrity of software releases, prove authorship, establish trust in digital identities, and anything else you can think of that requires one or more of these features:

When a security researcher communicates with a browser vendor about a newly-discovered security flaw, they’ll be using PGP. When a Linux distribution package manager makes new software available, it’ll be secured with PGP. When Edward Snowden contacted Laura Poitras and Glenn Greenwald, he used PGP. When two friends want to talk about their vacation and summer BBQs without the NSA listening in, they can use PGP.

GPG (GnuPG/Gnu Privacy Guard) is a Free Software/Open Source tool for working with OpenPGP. It’s very flexible, and can be used for all of the purposes mentioned above. For email, the most common use, you’ll likely interact with it only indirectly through your mail client or a plugin, but for key signing you’ll probably have to learn how to do a few things directly in the tool.

The OpenPGP system is based on the concept of keys, which are actually specially-chosen massive numbers stored in a file. Everyone will have two of them: a private one that you keep completely secret and well-protected, and a public one that you share with the whole world. When people want to write to you, or read a message from you, or check that something really came from you and hasn’t been modified, they’ll use your public key. When you want to send something securely, you’ll use your private key. The two keys have a mathematical connection that means that they work together in this special way: something encrypted or signed with a particular private key can only be decrypted or verified with the one single corresponding public key, and vice versa.

On their own, keys provide the encryption and secrecy part. They don’t automatically solve the social problem of finding out what someone’s public key is, or whether a public key that you found really belongs to the person it claims to belong to. This is where signatures come in. A key signature is a cryptographic operation whereby the owner of one key attests that they have checked the identity of the owner of another key. Thus, if you trust your friend and have checked his or her key, and your friend trusts me, and has checked my identity and key, you can have some basis for believing that my key really belongs to me, even if we’ve never met. This concept is called the Web of Trust, and is central to the concept of using OpenPGP. It’s also notable and interesting because it doesn’t rely on any centralized authority or server that can be compromised, destroyed, or subverted.

A keysigning event is a gathering of OpenPGP users who take a quick moment to sign each other’s keys, thus strengthening the Web of Trust, and helping newcomers who may not have met many of the people they need to communicate with securely. After participating in a keysigning event you may even be able to directly verify the authenticity and integrity of your favourite Open Source software release, based on your own first-hand knowledge of the authors or their acquaintances!

top of page

Okay, I know some of these words… How do I get started?

The basic thing you need to do is install GnuPG; possibly via a platform-specific version like GPG Suite for Mac or Gpg4win for Windows. With this in place, you’ll need to generate a key. There may be a GUI wizard for doing this on your platform, or you can do it from the command-line with gpg --gen-key. The settings you’ll want are a key of type RSA+RSA; a key size of 4096 bits; your full real name and email address; nothing in the “comment”; and an expiry date about three years from now (we don’t intend to let it expire, so set a recurring yearly calendar event to remind you to extend the expiry date, since it’s editable. The idea is to allow the key to die a natural death if you ever lose access and are unable to revoke it). Consult the linked docs on how to edit the key once it’s created, how to extend the expiry date, and how to make a safe backup of your key (you really should do this!).

In addition to the information on the rest of this page, you may find Ubuntu’s in-depth guide to using GnuPG, or Arch’s equivalent, useful.

top of page

How do I perform the key signing ritual?

There are some tools mentioned below that help automate this and make it much simpler. However, the full manual procedure looks like this:

  1. Receive a written copy of the other person’s full key fingerprint (gpg --fingerprint KEY-ID-HERE). It will look something like “2DC2 9C7F 65BC FC1B 3EBE F8F7 8569 B631 1EE4 85F8”. Also note the full name and email address attached to the key.
  2. Have the owner of the key examine the full fingerprint and confirm that it is correct and belongs to their key. They should also check the key length and type (e.g. 4096/RSA).
  3. Have the owner of the key present at least one piece of official government-issued ID with a photograph. Different people will have different standards for what they require before signing keys. A typical requirement is one piece of ID with photograph, plus one more piece of ID which need not have a photo.
  4. Confirm the ID appears genuine and appears to belong to the person in front of you. Confirm the name on the ID matches the name/identity attached to the key that you received earlier.
  5. If everything is in order, make a note on the piece of paper you received and file it away for signing later.
  6. Repeat with the roles reversed, to get your key signed as well!
  7. After the event, back at your computer, fetch the key in question with gpg --recv-key KEY-ID-HERE. Sign it with gpg --edit-key KEY-ID-HERE, verifying that the information presented matches exactly what you have on the piece of paper from earlier. Export the signed key with gpg --export -a KEY-ID-HERE > PERSON-NAME-HERE.key, and email the resulting file to the email address associated with the key. You can even encrypt it!

The whole process can be made much more convenient by using some "Signing Party" PGP tools; in particular gpg-key2ps for generating paper slips with your email, key fingerprint, and other details on them, and caff to automate signing and sending signed keys to their owners (will require some configuration). These tools are available in Debian-derived Linux distributions through the signing-party package, in Fedora-based ones via the same name, in Arch via AUR’s signing-party-svn, and likely in several other distributions. There is also a similar tool named PIUS.

Debian also has a very good guide to key signing with some details on the exact commands you’ll need to run, as does Ubuntu.

top of page

How do I set up my email to use PGP?

That depends on how you use email! Many popular email clients have plugins or even built-in support for GPG. Here’s a short list of some of them:

Even more tools and integration points are listed on GnuPG’s Frontends page.

top of page

I’m getting the hang of this. How do I use PGP like a pro?

Above all, check out these OpenPGP Best Practices. This is a useful guide to subkeys, which let you split your key into a super-secure part used only for signing, and a less-secure part you can put on your laptop or phone for day-to-day email; there is also Debian’s shorter guide to subkeys that covers some of the same material. Ubuntu also has some docs on using GnuPG in a variety of contexts. If you use Git for version control, you may be interested in signing your tagged releases, or even your commits (less useful).

top of page

I still have questions. Can I talk to someone?

Come on out to the keysigning event, and you’ll find lots of people willing to help. Whether you’re starting from zero or just have questions about the finer nuances of advanced PGP usage, there will be someone to talk to.

If you still have questions, or you can’t make it to the event, or for whatever other reason (like comments or corrections on this page), you’re welcome to email Felix Crux <felixc@felixcrux.com> (0x8569B6311EE485F8).

top of page