GPG Keysigning Party HOWTO (en)

This document describes the protocol and methods for holding and participating in a PGP Key Signing party using the GNU PGP implementation, GnuPG. It gives an explanation of key signing protocols, answers frequently asked questions, and explains how to go about generating your own keys as well as signing other's keys.

A key signing party is a get-together of people who use the PGP
encryption system with the purpose of allowing those people to
sign each others keys. Key signing parties serve to extend the web
of trust to a great degree. Key signing parties also serve as
great opportunities to discuss the political and social issues
surrounding strong cryptography, individual liberties, individual
sovereignty, and even implementing encryption technologies or perhaps
future work on free encryption software.

Key signing is act of digitally signing a public
key and a userid packet which is attached to that key.
Key signing is done to verify that a given user id and
public key really do belong to the entity that appears
to own the key and who is represented by the user id
packet.

You can digitally sign your own public key and an associated
id on that key, or another entity's public key and associated
public key packet.

In a sense, key signatures validate public keys. They are
an endorsement of validity of a public key and associated
id by a third party. This is the way in which key signing
builds the web of trust.

A web of trust is a term used to describe the trust
relationships between a group of keys. A key signature
is a link, or strand if you will, in the web of trust.
These links are called Trust Paths. Trust paths can be
bidirectional or only one way. The ideal web of trust
is one in which everyone is connected bidirectionally
to everyone else. In effect, everyone trusts that every
key does in fact belong to its owner. The web of trust
can be thought of as the sum of all the trust paths, or
links, between all key holding parties. As a visual
example, here is a graph of a web of trust
that I belong to.

As an example, let's say that Alice and Bob generate PGP
Keys with GPG and hold a PGP key signing party. At the party
Alice and Bob go verify each others' key information and later
sign each others' keys. GPG by default automatically signs the
public key of every pair it generates with the associated
private key. So, Alice and Bob both now have at least two
signatures validating that their keys belong to them. Alice's
key was signed by Alice herself and Bob and Bob's key was signed
by Bob himself and Alice. In the future Alice and Bob meet Cathy.
Cathy generates a key pair and tells Alice and Bob that she will
send them her key. Alice doesn't like Cathy and doesn't want Bob
to exchange encrypted communications with her. Both Alice and Cathy
generate PGP keys which they claim belong to Cathy. They both send
them to Bob. Both keys have one signature, the signature of the
associated private key. Bob does not know which key is really
Cathy's. Cathy hears that Bob got two keys, and suspects Alice.
Cathy, now angry, wishes to gain information that she can use
against Alice. In order to acquire this information Cathy must
compromise the encrypted communications between Alice and Bob. In
order to do this, Cathy decides to forge an email to Bob from
Alice telling him that Alice has generated new keys. In the forged
email, Cathy includes Alice's "new" public key (which is in fact a
fake key generated by Cathy). However, Bob knows for sure this is
a trick because even though Bob now has two keys for Alice, one of
the keys has been signed by multiple people (himself and Alice)
verifying that it does indeed belong to Alice, while the other
key - Cathy's fake key - only has its own signature.

The above example is very simplified and things can get a lot
more complicated than that. You can read through the PGP FAQs
or a good book on PKI for more information and a more detailed
explanation. The above example does clearly explain the basics
of key signing and its value. Cathy was not able to introduce
a fake key pair for Alice because of the web of trust interconnections
between Bob and Alice.

However, signatures and webs of trust do not
guarantee trustable keys. For example, when Bob and Alice
first met Cathy, lets say that a friend of Cathy's, Donald, had
been with Cathy. Donald could have generated fake key pairs for
Alice and Bob, signed them with his key and signed both pairs
of keys with the other pairs resulting in three signatures on
each key and sent them to Cathy. Cathy would be facing a
series of bad keys and signatures. How could key signing help
Cathy resist such an attack? Well, let's say that all the
people involved where exchanging keys through a key server.
If Cathy searched the key server for Alice and Bob's keys,
she'd find two sets for both Alice and Bob. If Alice and Bob
collected twenty key signatures at the keysigning party, it's
obvious that Cathy can better trust the public keys signed
twenty times than the ones signed only three times. Cathy
should know something's up from the existence of the extra
public keys - so she can look for closely at the generation
dates and the trust web behind the public keys. The twenty
keys from the party signatures should all be signed twenty
or more times and have widely varying generation times, most
likely all the keys which signed Alice and Bob's keys where
also signed by other keys. That would not be the case if
Donald had generated twenty faked key pairs and generated a
faked web of trust.

There are three primary reasons to hold as many key signing parties
as you possibly can.

First, and perhaps most importantly, you should hold as many key signing
parties as possible in order to expand the web of trust. The more deep and
tightly inter-linked the web of trust is, the more difficult it is to
defeat. This is of special significance to the Free Software Community,
both developers and users alike. Members of the community rely upon PGP
technology to cryptographically protect the integrity of their software
packages, security advisories, and announcements. The strength and
robustness of the web of trust is directly proportional to the strength
of the protection PGP provides the community.

Second, key signing parties help others get integrated into the security
culture and encourage them to gain an understanding of PGP and related strong
cryptography technologies. In order to get the benefits of strong cryptography,
people must use strong cryptography, and use it properly.

Finally, key signing parties help build communities. They help
techies get together to get to know each other, network, and discuss
important issues like civil liberties, cryptorights, and internet
regulation. Discussion is important because discussion is not only the first
step, but also the step before action. At the time I'm authoring this document
there are not very many complex webs of trust in the world. If you work
to build a web of trust in your local area, it is very likely that the
first participants in that web will be the leaders and policy setters of
the internet community in your area. They are the individuals who can
choose to build secure strong cryptographic technology and protocols into
the local infrastructure if they so choose. The integration of such
technology and protocols could make issues like the FBI's carnivore
system technologically infeasible and therefore moot.

It's not very difficult to organize and coordinate a key
signing party. However, aside from the regular tasks of inviting people,
picking a location and setting a time, the Coordinator does
have some other key signing specific responsibilities. Those
usually include providing a key list for each participant and
determining the structure of the party.

There are two primary ways that a PGP key signing party can be
structured -- in a centralized way or in a decentralized way. The best
approach to the key signing can be determined by the number of people
that will be attending and the atmosphere of the location where you're
holding your party. The basic requirements of the party are that the
participants are able to verify each others' keys and that the the
participants are able to verify each others' identities. Given that
those basic requirements are met, the coordinator can come up with some
variation of the two types.

A centralized party would be a more organized affair which would
work well with small to medium numbers of people. The participants
would send their key information to the coordinator who would compile
it into a list. Each participant, upon arriving at the party, would
be given a copy of the key list. Each participant would then be called
on by the coordinator. The participant would then check their key fingerprint
against the fingerprint on the sheet that the coordinator gave them. If
the participant is sure that their key is the same as the key on the
sheet then the participant would read their fingerprint aloud so that the other
party participants can make sure they also have the correct matching fingerprint.
If they do in fact have the correct matching fingerprint, they check it off on their
sheet. This is necessary to make sure that the coordinator has not made a
mistake in the generation of the sheet or has not slipped a sheet with
faked key information to one or more of the participants. After everyone has checked
off the participant's key, the coordinator then calls on the next participant,
and so on. After all of the keys have been verified, the participants and
coordinator are asked to form a long single file line while holding their
IDs in front of them. The person at the head of the line walks down the line
and checks each person's ID. If their ID is correct and the person walking
down the line has a check next to the individual in the line's key verifying
that they had said it was their key at the beginning of the party, he places
a second check mark on his list. Once a key has two check marks it can be signed.

A decentralized party would basically be every man for himself. Participants
are expected to mingle informally and find other participants who's keys
they have not signed yet. Upon meeting they verify their keys on
each other's lists and validate each other's ID. Decentralized parties
allow many more people to be easily included but also have the down side
of making it easy for some participants not to validate each other's
keys for future signing. At a decentralized party, it is important for
the coordinator to encourage everyone to make sure that they do meet
with everyone else for key validation. While a list of keys and fingerprints
does not necessary need to be produced for a decentralized party,
it is still good practice.

Centralized parties are great for key signing parties at conferences
during lunch, informal quiet meetings at some one's home or a restaurant
etc. Decentralized key signing parties are much more practical for
parties that will include a very large number of people, take place
in a bar or other noisy area, or parties including particularly rowdy
and difficult to control geeks.

The larger the party the better. You can announce your party to
your local LUG email list, other computer related lists you're on
in the area, even place an ad in the news paper or issue a press
release.

If you're just starting to build the web of trust in your
area, it's a good idea to try and get other active PGP users
involved because they are the ones who are most likely to
hold key signing parties of their own in the future. Good ways
find such people are to talk with others who've sent email to lists
you're on with PGP signatures, or by searching the keyserver
networks for keys with email addresses specific to your local
area. For example, email addresses that end in the domains of
a university or large company which are located in your area often
yield very high numbers of interested parties.

If you're going to use a party structure that calls for
the participants to have lists of the keys of everyone
attending the party, the coordinator needs to generate such
a list. This list should be compiled in a format similar to
this:

A copy of the key list should then be printed out for each of
the people who will be attending the key signing party. The
coordinator can print the copies of the list himself, or he
can email the list or place it on the web for the attendees
to print.

Nothing gets people's interest peaked like colorful graphics.
Therefor, graphing the web of trust in your local area as you build it
can help motivate people to participate as well as giving everyone a
clear sense of what's being accomplished as things progress.

You can very easily create a graph of all of the keys and signatures
in your web of trust by converting that information into a dot file which
can be fed into a graphing program like dot or neato. A perl script which
converts the keys and signatures in a keyring to a file in the dot
format was written by Darxus and is also available under the terms of
the GPL. In order to graph the web of trust you'll
need to download Darxus' sig2dot.pl script and the
graphviz
package from AT&T Research. You may not be able to graph a web of
trust with more than a few hundred nodes due to the amount of memory
needed to perform such an operation.

Instructions for graphing the web of trust in a gpg keyring are
included in the sig2dot.pl script, or can be found on the Debian
keyring graphing page. Again, here is a link to view a graph of
a web of trust which was produced with the sig2dot.pl script and
the neato graphing program. More information is available from the
Debian keyring
graphing page.

You should not bring a computer to the party because
binary replacement or system modifications are very
easy ways to compromise PGP systems.

If someone where to bring a portable computer and
everyone used that computer to sign the other keys at
the party, no one would know if the machine had been
running a key stroke logging utility, a modified version
of GPG,a modified version of the Linux kernel, or a
specially modified keyboard, any of which could be used
to capture the secret keys of those who used the computer.

The use of a computer at the party would also leave
you open to more simple attacks like shoulder-surfing,
or more complex attacks like weak secret key generation,
secret key modification, or even infection with virii
that modify your GPG binaries to leak future secret keys
discretely.

The process of generating a key pair is rather simple. Basically,
you just need to run gpg --gen-key. However, I recommend
that you also generate a revocation certificate for your key in case
you ever loose access to your secret key (i.e. loose your passphrase
or loose your secret key). The instructions for generating a revocation
certificate can be found in section 3.7 of this document.

The step-by-step instructions bellow where written with
practical usage and sufficient security in mind. For example:

the keys are generated with the largest possible keysize
to make them more resistant to brute force attack

a revocation certificate is generated to allow the public key
to be revoked in the event of a compromise or key loss

Some people may be comfortable with out taking all of these
security precautions. For example, if you have a portable
computer or a home computer which you read all of your email
from, you may feel comfortable enough to store your key on
the hard drive of that computer. You may also feel comfortable
generating a key pair which never expires which you can use for
identification and most communications - then generating
additional key pairs for extremely sensitive communications
(should you have any). Again, the step by step instructions
bellow where written with best practice security in mind. You
don't necessarily need to follow them, you just need to
generate a keypair. On the other hand, if you are an extremely
paranoid security freak like me following the directions bellow
will temporarily provide you with that swiftly fleeting sense of
calm that you so need to feel right now.

The step-by-step instructions bellow where written with
best practice security (severe paranoia) in mind. For example:

the keys are generated with the largest possible keysize
to make them more resistant to brute force attack

the keys are generated with a limited lifetime to prevent
their eventual compromise by advancing computer technology

the keys are stored on a floppy disk to prevent their theft
should someone gain access to your computer (remotely or physically)

a revocation certificate is generated to allow the public key
to be revoked in the event of a compromise or key loss

1) Go to www.gnupg.org and download the latest version of gnupg: gnupg-x.x.x.tar.gz

Warning: Make sure you're running at least version 1.0.6 of GnuPG. Versions prior to 1.0.6
had at least one significant security weakness in them.

If you share the system you're install GnuPG on with others, you may
also want to make gpg setuid root so that it can use secured memory. If
you do choose to do this, you should take precautions such as checking
your archive with the md5 signature and the pgp signature to make sure
you're not installing a tojan horse.

4) Get a floppy to store your keys on and format it.

bash$ /sbin/mkfs.ext2 /dev/fd0

4a) Mount the floppy and make a directory on it owned by you
for your keys:

DSA keypair will have 1024 bits.
About to generate a new ELG-E keypair.
minimum keysize is 768 bits
default keysize is 1024 bits
highest suggested keysize is 2048 bits
What keysize do you want? (1024) 2048<return>
Do you really need such a large keysize? yes<return>

5e) Choose a pass phrase. You need to pick a good one. It should be
long and very difficult to guess. It should be something you won't
forget. If you forget your pass phrase, you cannot recover your key.

5f) Move the mouse and hit some keys maybe update locate in the
background or run a big find. GPG is reading from /dev/random
to get some randomness for your key generation. /dev/random is
populated in part by interrupts.

6) Modify your key if you want. For example if you have multiple email
addresses and you want to list them as valid on your key:

It's important to note here that some people believe that
keeping their public key secret adds an extra degree of security
to their encrypted communications. This is true, because a keyserver
could be broken or compromised and return the incorrect public key
when queried. Further, the key on a given public keyserver may not
be the most up to date version of the key. For example, additional
signatures may have been added to the key which have not been propagated
or uploaded to the keyserver. It is also true because the public key
of a key pair is needed to carry out certain types of attacks against
the public key cryptosystems which pgp uses. While many people expect,
with reasonably large keysizes, that these attacks are so extremely
unlikely to be successful that is does not matter if the public key
is broadcast, keeping the public key secret does in fact strengthen
the key pair.

I don't recommend that you keep your public key secret as it
will discourage others from using PGP in their communications
with you. To address the issue of the possibility of a
compromised or broken keyserver returning an invalid key
you can take steps to protect yourself from having messages
sent to you encrypted with invalid keys, such as publishing
your key's fingerprint in your .signature file or on your web
page. To address the concern about the attacking of your
key pair though your publicly available public key, I would
say that if you are very concerned about the strength of your
keypair or truly paranoid about the secrecy of your communications,
you could generate additional keypairs (which expire in a matter
of hours or days) for each communication and exchange the public
keys of those keypairs though encrypted communications with the
individual you'll be communicating with.

If you don't wish to have your key on a public keyserver, you
should skip this step and instead email your public key to the
keysigning party coordinator with a message stating that you don't
want your key on a public keyserver. The coordinator can then extract
your public key information and forward your key on to the other
participants via encrypted e-mail, or some other method, along with
a note stating that the key should be returned to its owner after
signature rather than uploaded to a keyserver.

The generation and storage of a revocation certificate will allow
you to revoke your public key even in the event that you loose access
to your private key due to compromise, seizure, forgotten passphrase,
or media failure. If you want to have the ability to revoke your
public key when you do not have access to your private key, you should
generate a revocation certificate and store it a secure and safe place.
You should also print out a copy of your revocation certificate so that
it can be entered and used in the event of the failure of the media it
is stored on.

If you revocation certificate is compromised, the individual who
compromises your revocation certificate will be able to circulate the
certificate thereby disabling your key. However, the individual will
not be able to compromise your secret key through his access to your
revocation certificate. Therefor, they will not be able to generate fake
signatures, decrypt messages encrypted with your keypair, or otherwise
misrepresent themselves as the owner of your keypair. Since the only
negative outcome possible from the compromise of a revocation certificate
is the disabling of your keypair, it is a generally safe and good thing
to do.

9) Email your info to the Coordinator telling him that you're coming
to the key signing party. The command bellow will print out the information
that you want to need to send to the coordinator if you're using a keyserver.
You can then send that information in an encrypted email message to the
coordinator.

bash$ gpg --fingerprint <Your_Key_ID>

10) Unmount the floppy and eject it:

bash$ umount /mnt/floppy

Note: You can carry the floppy around with you for additional security,
or you can just leave it in a safe, locked desk drawer etc. You DO NOT
want to have your .gnupg directory containing your keys in a location
accessible over the internet.

Normally, you'll be working from a keyserver. However if
you are signing the key that is not available on a keyserver,
you can use simply import the key with gpg --import.
If you are working with a keyserver, the following command will
download the key from the keyserver into your public keyring.

bash$ gpg --keyserver <keyserver> --recv-keys <Key_ID>

If you get a read error, it means the keyserver is overloaded. Please,
try again in a few seconds.

Step 2: Fingerprint and Verify the key

bash$ gpg --fingerprint <Key_ID>

GPG will print out the fingerprint of the Key with <Key_ID > (the key
you just downloaded). Check the fingerprint against the checklist
that you where given at the party. Note: Don't check the fingerprint
on your checklist against the fingerprint on the web page as the server
may not send you the same key it displays on the web page.

Step 3: Sign the key

bash$ gpg --sign-key <Key_ID>

If you have multiple private keys, you can specify which of your private
keys to sign the other persons public key with like this:

bash$ gpg --default-key <Key_to_use> --sign-key <Key_ID>

If you have trouble dealing with RSA keys, you're probably using an old
version of gnupg. Versions of GnuPG older that 1.0.3 do not include RSA
support. Note: You may have to uninstall an older version if your
distribution installed it with package management software.
You can check the version you're executing like this:

bash$ gpg --version

Step 4: Return or Upload the signed key

If you are working with an entity which does not want their
key on a public keyserver, you should at this point you should
return their signed key back to them by their method of choice
- normally encrypted email. You should not send a public key to a keyserver
with out the permission of the key's owner. Publicizing a public
key slightly reduces the security of a key pair, therefor it is
considered rude to make a key more public than its owner desires.

Most likely you are working with a keyserver. If that is the
case, you can send the signed key back to the keyserver like this:

bash$ gpg --keyserver <keyserver> --send-key <Key_ID>

You should see a success message like this:

gpg: success sending to `<keyserver>' (status=200)

Congratulations, the signature of the other entity's key is
now complete and your signature has been incorporated into
their public key. A trust path has been established.

In the event that you suspect that your secret key has been compromised, you should
revoke your public key immediately. Key revocation takes place by the addition of a
Revocation Signature to a public key. The revocation of a key suggests that a key is
no longer valid (secure) and should not be used. One a revocation certificate is issued,
it cannot be withdrawn.

Since your PGP key is distributed (read circulated) to people rather than distributed
from a central point every time it is accessed, you must circulate or distribute your
revocation certificate in the same manner that you distributed your public key. The circulation
of the revocation certificate in the same manner as the distribution of your public key would
usually mean uploading the revocation certificate to the keyserver networks. If you had not
uploaded your public key due to security considerations, you may still want to upload your
revocation certificate to the keyserver. In this case you would be making a trade off between
the slight reduction in security which results from having your public key publicly
available, and the reduction in security which could occur from having someone potentially
not realize that your key has been revoked.

In review, the gpg command to generate a revocation certificate is:

bash$ gpg --output revcert.asc --gen-revoke <key_id>

If you have an idea about how or when you key was compromised and you
generated a revocation certificate during key generation, you will still
likely want to generate a new revocation certificate to revoke your keypair.
This is the case because the openPGP standard will allow you to specify the
reason why you are revoking your keypair and even provide some free text
comments about the reason for revocation. The circulation of a revocation
certificate with this type of information is likely advantageous and preferable
to the circulation of a generic certificate created during key generation.

Key - One or more bits of data used in the encryption or description process.

Key Fingerprint - If PGP, a value used to identify a key which is generated
by performing a hash of key material.

Key Pair - In public key cryptography, a pair of keys consisting of a public
and private, or secret, key which interrelate.

Keyring - A collection of keys. Most often this term is used in relation to PGP,
where a keyring consits of a collection of one or more key packets.

Key Server - A system which stores key material in a database. These servers may
be queried by users who wish to acquire the public key of a recipient they have not had
prior contact with.

Keysigning Party - A get-together of people who use the PGP
encryption system with the purpose of allowing those people to sign each others public keys. Keysigning parties serve
to extend the web of trust.

openPGP - An open standard which defines a version of
the PGP security system.

Pretty Good Privacy [PGP] - Privacy software developed by Phil Zimmermann,
which includes public key cryptography, a standard packet and key format, and symmetric encryption
as well.

Public Key - In public key cryptography, the key of a key pair which is
shared.

Public Keyring - A keyring consisting of Public Keys. This term is most often used in
relation to PGP.

Radix - A method of encoding data so that it may be transmitted
over a channel which only support 8 bit characters. For example, such a channel could be
email or the Usenet.

Secret Key - In public key cryptography, the key of a key pair which
is kept secure.

Secret Keyring - A collection of secret keys. Most often this term is used in relation
to PGP where it defines a collection of secret key packets.

Trust Path - A route by which trust is extended from one entity to
another. In PGP, this is a link of trust between two public keys.

Web of Trust - The collection of signatures upon keys and resultant
trust paths in a user centric trust model which provide for authentication.
Collectively, the trust relationships between a group of keys.