How to Participate in a GNU Privacy Guard (GPG) Keysigning Party

Introduction

We discuss some basic concepts about GPG and then move onto holding a GPG keysigning party. This document is quite superficial, and in no way an exhaustive guide to GPG.

GPG is a powerful tool, and can do more harm than good if used without proper understanding. If you haven't used GPG before, please take some time to go through The GNU Privacy Handbook before you continue with this document.

WARNING Do not under any circumstances sign someone's key until:

• You have thoroughly verified the person, key and e-mail address
• You totally know what you are doing.

What is GPG anyway?

GNU Privacy Guard (known affectionately as GPG, or sometimes GnuPG) is a tool for enabling (a) secure and (b) non-repudiable communications over the Internet. In simple terms this means that using GPG you can do the following:

• Write messages that only your intended recipient can read. Anyone else who intercepts the message will not be able to decipher it.
• Digitally sign a message so that everyone who reads it can be sure that it came from you, not someone who faked your e-mail address.

GPG comes installed by default on most modern Linux/Unix systems. Versions for other operating systems (e.g. Winduhs) are also available.

What is a key?

Every GPG user has one (or perhaps more) key. The key identifies a GPG user uniquely, and consists of two parts: the private key and the public key. The private key is accessible only to the key owner, while the public key is, er, public.

You use your private key to sign outgoing messages and to decrypt encrypted incoming messages. In contrast, you use your correspondent's public key to verify her signature on a message that she sent you. You also use her public key to encrypt messages that you wish to send her that only she can view.

Getting someone's public key

Of course, in order to send encrypted messages to someone (or to verify their signature on an incoming message) you need her public key. While it is possible to get it directly from the individual concerned, wouldn't it be easier if someone took everyone's public keys and kept them in one place? Then whenever you needed someone's public key all you would do is connect to that repository, find that person's name and get the corresponding key.

Key servers

Well, that's exactly what the nice people who run public key servers do. If you want people to find your public key you just upload it to one of the key servers. Since the major key servers share their databases regularly, within a day or two your public key would be available from all the key servers. Then anyone who wanted it would just get your public key from any of the key servers.

Trusting a GPG public key

Ah, but now we come to the catch! Say you want to securely communicate with ram@some.domain. You get ram@some.domain 's public key from a key server, but how do you know that it actually belongs to ram? Anyone could have generated a GPG key, said it belongs to ram@some.domain and uploaded it to the key server -- the key servers do no validation of keys on their own. So now you need to figure out how to trust a public key.

Fingerprint-based trust

One way of generating trust for a key is through its fingerprint. Each GPG key has a unique fingerprint, a string of bits that is much shorter than the key itself. This is usually written out as a string of hexadecimal digits which looks like perfectly meaningless babble. For instance, my key fingerprint is:

78D4 FC67 367F 40E2 0DD5  0FEF C968 D0EF? CC68 D17F?

So when you want to find out if the key that you got with e-mail ID ram@some.domain actually belongs to ram@some.domain, you can call him up and ask him, ``Dude, what's your GPG key?''. And instead of giving you his whole key, ram@some.domain just tells you, ``My GPG key fingerprint is *babble* *babble* *babble*'', which you compare with the fingerprint of the key that you got from the key server. If the two match, then you know that the key you have belongs to ram@some.domain; if they don't match then some mischievous person is trying to masquerade as ram@some.domain, and you throw that key away.

Signature-based trust

While the above method works fine when you can just call up everyone whose GPG public key you want to use, it fails when the owner and user of the public key don't know each other. Obviously, they cannot use e-mail to exchange key fingerprints (if they could trust their e-mails they wouldn't need to use GPG In the first place . This is where key signatures come in.

Suppose you have a GPG public key for rahim@other.domain, and you know rahim@other.domain is a reliable person where it comes to security matters. When you get ram@some.domain 's key, you cannot trust it as it is. However, what if rahim@other.domain verifies that the key you have actually belongs to ram@some.domain? Since you trust rahim@other.domain 's judgement in these matters, you can be sure that the key you have actually belongs to ram@some.domain.

In GPG this is called signing a public key and in our case above rahim@other.domain would have signed ram@some.domain 's key. When you sign someone's public key you are effectively saying, ``I testify that this key actually belongs to this person.''. People who trust you and your judgement will then accept the validity of that public key.

The above is a very brief description of GPG key signatures and does not cover levels of trust and reasons for trusting signatures at all. Please take some time to read more about this at Validating other keys on your public keyring

Keysigning parties

When a number of people get together to verify and validate each others' GPG keys, the event is called a Keysigning Party. Keysigning parties are well suited to public events where a number of people (who otherwise would not be in one place together) meet up.

Verifying a public key before signing it is a 3-stage process:

1. Verify the identity of the person
2. Verify the key
3. Verify the e-mail address in the key

A keysigning party lets you do the first two steps for a number of people at the same time. The third step can be done at any time afterwards.

How to participate

This section outlines the actions you have to perform to participate in the keysigning party. The detailed commands for each action are available in The GNU Privacy Handbook.

Before the keysigning party

To participate, first make sure that your GPG key is available to the organiser(s) of the keysigning party.

Generate your key (keypair)

Skip this part if you have already generated your GPG keys.

Read Generating a new keypair and then use gpg --gen-key to generate a new public and private key (keypair).

Generate a revocation certificate

Skip this part if you have already generated and saved your key revocation certificate.

Generate and save a key revocation certificate http://www.gnupg.org/gph/en/manual.html#REVOCATION.

Upload your public key to a key server

If you haven't done so, upload your public key to a key server. I use wwwkeys.pgp.net (which is actually multiple machines). Keys submitted to any key server will propagate to the others within a day or two.

Send your public key to the keysigning party organisers

The organiser(s) of the keysigning party would have made some arrangement for collecting public keys of all the participants. In the case of freed.in 2007 this is the Biglumber coordination site. Upload your public key there.

Get stuff ready for the party

Carry the following with you to the party:

• Proof of ID. Passport, driving licence, PAN card, etc are fine.
• Key fingerprint. Carry your own GPG key fingerprint with you. Extract it using gpg --fingerprint and print it out.

During the keysigning party

The organiser(s) of the keysigning party will make printed copies of all the key IDs, fingerprints and associated names and e-mail addresses to all the participants. As a participant, you must:

• Verify other peoples' proofs
• Provide other people with proof of your identity and key

Verify other keys

Each person will provide proof of ID and read out his/her fingerprint in turn. If you want to sign someone's key, verify (using her ID proof) that she is who she claims to be. Then check the fingerprint that she reads out against her key fingerprint in the printed list of fingerprints that the organisers gave you. If the two match, you can be certain that the given key actually belongs to the named person. Make a tick against the key in the list to mark that you have verified this person and her GPG key.

Provide proof and key

Important Carry some proof of ID with you to the party. Passport, driving license, PAN card, etc. are fine.

Important Carry a printout of your own key fingerprint with you.

When your turn comes, hold out your ID proof and let anyone who wants examine it. Once everyone is satisfied that you are who you claim you are, get your fingerprint printout and read out your key fingerprint. Now everyone present can validate that the given key actually belongs to you.

After the party

After the keysigning party you must verify the e-mail addresses in the keys that you are going to sign. For each key that you plan to sign, send an e-mail encrypted with that public key to each address in the key. If you get a meaningful reply, then you know that the e-mail address in that key is correct.

For instance, my key (http://pgp.mit.edu:11371/pks/lookup?search=0xC968D0EFCC68D17F&op=index) has 3 addresses associated with it (one is a duplicate so I'm not counting that). 2 of them are active, and one (the palcom one) isn't. So if you wanted to sign my key you would send encrypted mails to all 3 addresses. You would get valid replies from me on 2 of those addresses, and then you could proceed to sign those 2 addresses in my key, while ignoring the inactive one on which you didn't get a response.

Signing keys and sending

Once you are satisfied with the response you get from an address you sent mail to, sign the address in the key and upload it to one of the public key servers. Yes, you are allowed to upload other peoples' public keys to a key server. If the key is already present there, your signature will be added to it. It is courteous to send the owner of the key an e-mail informing her that you have uploaded a new signature to the key server. You could also send her her key signed by you and let her upload it to the key servers herself.

Use gpg --edit-key with the sign option to sign a key in your keyring.

NOT signing keys

If the reply to your encrypted e-mail is not acceptable to you (e.g. the reply does not contain a decrypted version of the mail you had sent) then there is a problem and you should not sign that address in the key. Remember, you are not obliged to sign anyone's key. If you have any doubts at all about a key you should just avoid signing it.

Handling signed keys

The easiest way to handle public keys and signatures is through the key servers. When you sign a key, upload it to a key server. When someone else signs your key, she will upload the signed key to a key server too.

If you download your own key from a key server, the new signatures in it will get merged with the signatures already present in your key. It is safe to upload and download the same key multiple time to/from a key server.

-- RajMathur - 21 Sep 2007