I've been planning a key signing party for ages now, but had not managed to writing down the necessary information before now. It's written, and attached to this message.
If you're interested, several copies of your --fingerprint output from GnuPG (or the equivalent from PGP) with you tonight along with picture ID, preferably two forms of it if possible. The best way to get the multiple copies of the output is to copy it into the clipboard and just paste it a dozen times or into a text file, with a few lines of space between each. Then just print the file and and cut the resulting paper into strips. Hope to see everyone tonight, and have lots of keys to sign! -- Joseph Carter <[EMAIL PROTECTED]> Have chainsaw will travel <dpg> americans are wierd.... <xtifr> californians even weirder <Knghtbrd> xtifr has a point ...
This is intended as a gentle introduction to public key cryptography, the
web of trust, keysigning parties, and digital signatures on email. I
didn't get around to the email side of things, but I'll do that later. I
use GnuPG these days, so that's what I'll talk about. I'll try to warn
you about pitfalls with PGP where I know about them, but the last version
of PGP I used was PGP 2.6.3 many years ago and I can only explain what I
actually know something about. That means PGP users are basically on
their own. With that in mind, on to the guide!
Generating a key
----------------
Before you can use a key, obviously you need to generate one obviously.
And before you can generate one, you need to work around a small bug in
GnuPG which has been there for ages:
knghtbrd@galen:~$ install -d -m 700 ~/.gnupg
knghtbrd@galen:~$ touch ~/.gnupg/secring.gpg
knghtbrd@galen:~$ chmod 600 ~/.gnupg/secring.gpg
If you don't do this, GnuPG will create the .gnupg directory for you, but
a bug in GnuPG will keep it from being able to create a secring.gpg for
you. Now on to the key generation:
knghtbrd@galen:~$ gpg --gen-key
[.. harmless stuff ..]
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(5) RSA (sign only)
Your selection? _
You might have different options, but for sure DSA/ElGamal is available.
That's what we want, and it is the default. Then we see:
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) _
Bigger may seem to be better here, but that's not always so. Basically,
512 byte keys (which modern PGP and GnuPG versions do not even support)
have been demonstrated to be crackable in a period of time which is not
measured in some multiple of the age of the universe. 768 is currently
considered marginally safe, and 1024 is considered adequate for most
people who don't have anything to hide really. Therefore, unless you're
running a Pentium 1 or something equally ridiculously slow, I would advise
2048 bit. If you're paranoid (and this is not a bad thing when dealing
with cryptography), the maximum is 4096.
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) _
You can set a key to expire after a given period of time, and you can
change the key's expiration date later on. I can think of two reasons why
a person might want to set a key to expire at some point in the future,
but we'll consider such discussions a more advanced topic for now. Enter
0 and confirm your intent.
Fill in your name, email, and a comment or nickname when prompted (a
comment is not necessary - I don't have one myself) and exit the menu
which comes up afterward if you're satisfied with the results.
You need a Passphrase to protect your secret key.
Enter passphrase:
Repeat passphrase:
This is VERY IMPORTANT. It is possible to enter no passphrase here (note
they say passphrase here - it need not be just one word), but if you do so
you've virtually guaranteed that anyone with a copy of your secret keyring
has effectively stolen your identity. It does not matter whether your key
is 32 bits or 32768 bits if you don't have a good passphrase. If you're
not real good at coming up with solid passwords and things, use the pwgen
program. (apt-get install pwgen or emerge app-admin/pwgen or whatever
you use..)
At this point, your machine will start spitting out +++..+ type stuff.
There's meaning to the various characters, but we don't care what it is
really. ;) The final few lines will include pub/sub lines for your key.
These lines are what you'll need from people and want to give to people
for keysigning.
The options file
----------------
GnuPG doesn't necessarily need an options file, but you should create one
anyway. Before we do that though, we need to know our key DSA key ID,
since that's the one we'll use most often. Look at the pub line from the
above key generation step (gpg --list-keys "email@address" works too),
here is mine:
pub 1024D/DCF9DAB3 1999-03-01 Joseph Carter <[EMAIL PROTECTED]>
The number we want is the one after the /, in my case DCF9DAB3. Use your
own ID in place of mine below. (Note the sub line has a key ID too, that
is your ElGamal sub-key. DSA is used only for signatures, ElGamal is used
usually only for encryption.)
Now, let's make that options file, with the most advanced editor on our
systems:
knghtbrd@galen:~$ cat .gnupg/options << EOF
default-key 0xDCF9DAB3
escape-from-lines
lock-once
no-verbose
no-greeting
keyserver wwwkeys.pgp.net
secret-keyring secring.gpg
keyring pubring.gpg
EOF
If you have an old PGP keyring pair, you can drop them in ~/.gnupg and
simply add more keyring and secret-keyring lines. Just make sure that
your GnuPG keyrings are listed first. The keyserver can be any PGP
keyring server, but wwwkeys.pgp.net is a good choice if you don't have
another keyserver you know you'd prefer to use. The other options are
just my personal preferences, but they are good to have for email.
The revokation certificate
--------------------------
PGP users note: The last time I did this with PGP was in the days of PGP
2.x. At that time you could not do what I'm about to describe without
revoking your key in the process. That may or may not have changed. In
the event it has not, I advise you BACK UP your keyrings before you try to
generate a revokation certificate.
Now, what is a revokation certificate? Well, if you want your key to go
away or become invalid or otherwise not be usable by you or anybody else,
you will revoke that key. This is very important to be able to do if your
key is somehow stolen to keep someone else from impersonating you. It's
also a good idea if you forget your passphrase, especially if you followed
my advice and your key is set to not expire. Just in case, we'll make one
and put it away for a rainy day.
knghtbrd@galen:~$ gpg --gen-revoke 0xDCF9DAB3
It'll ask you some questions, get confirmation from you, and generate a
few lines of stuff delimited by these line:
-----BEGIN PGP PUBLIC KEY BLOCK-----
-----END PGP PUBLIC KEY BLOCK-----
Take this and copy/paste it into a file somewhere on your drive. Don't
forget to chmod 600 the file. Now open a fresh box of shrinkwrapped
floppies and put a copy of the file on the disk. Put the disk in a
ziplock baggie with all of the air carefully removed. Burn a CDR with
just that file on it. Print it out using a very easy to read font. Make
sure there's a copy in a safe-deposit box at a bank. You get the idea,
this file is important - even more important than your keyring itself.
You do NOT want to lose it!
If someone else gets their hands on this file, they can revoke your key,
but that's not nearly as bad as them using your key and you not being able
to revoke it. I actually don't have a copy of my revokation certificate
on my machine, but I do have three copies of it stored in places where
they are not likely to be damaged.
Don't forget to recover your backup keyring if you're using PGP and it
just revoked the key you just created. ;)
Using your keyring
------------------
The first thing you probably need to know is how to extract your own key
for a variety of purposes. To show how to do this, I'll put my key into
the file knghtbrd.asc:
knghtbrd@galen:~$ gpg --export --armor 0xDCF9DAB3 > knghtbrd.asc
knghtbrd@galen:~$ cat knghtbrd.asc
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.1 (GNU/Linux)
BDbbJ2cRBADfx9hETNQKb6fizormclwe00LCcDGC2DlrJHJ+xzE+wPLWCzTo
PNTGvho189No0HrsIYqMxSb7KP5CX7cbRNxRwMy2GLArtsr4QuBvg5AajLjg+fu2
:
UV2uKczC4OAwsYhGBBgRAgAGBQI22ylhAAoJEI/316Pc+dqzzcUAoJ9gj64mtwiZ
OGg6vQxtNrclmTg2AKClp4YBRh/zNFUJKcnXCryLdNFxgw==
=h5gC
-----END PGP PUBLIC KEY BLOCK-----
Keep in mind, although the --armor option is not required to put a key
into a file as we just did, using it makes sure the resulting output from
GnuPG is 7 bit ASCII. That kind of thing matters for emails, and if you
cat a binary file to your screen you can expect bad things. --armor is
your friend. =)
Importing someone else's key from a file is just as easy:
knghtbrd@galen:~$ gpg --import < knghtbrd.asc
gpg: key DCF9DAB3: "Joseph Carter <[EMAIL PROTECTED]>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
No changes obviously since we we're importing a key we just exported. We
used our own key here, but you can (and almost certainly will) import
other keys in the future. And you can export any key you've got on your
keyring, whether it be your own or one you've imported previously.
Messing with files for importing and exporting keys is not necessary these
days though, and that's what the keyserver line in our options file is
for. If I wanted to send a copy of my key to the keyserver, I'd do this:
knghtbrd@galen:~$ gpg --send-key 0xDCF9DAB3
gpg: success sending to `wwwkeys.pgp.net' (status=200)
To get a copy of my public key from the keyserver, I would do this:
knghtbrd@galen:~$ gpg --recv-key 0xDCF9DAB3
gpg: key DCF9DAB3: "Joseph Carter <[EMAIL PROTECTED]>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
Note that everywhere I have used the hex number of my key ID, 0xDCF9DAB3,
I could have instead used some string found in the user ID of my key,
including my name or email address. It's possible, however, to have more
than one key with the same name (I am after all not the only Joseph Carter
in the world, famous baseball players notwithstanding), and even to have
more than one key with the same email address listed, so a key ID is
usually much easier to work with.
You should send your key to the pgp.net keyserver if you did not do so
already.
By the way, do you remember that revokation certificate I had you make
earlier just in case? You can --import that just like a public key if you
ever need to. Once imported, you can --send-key it to the keyserver so
that the world knows not to trust that key anymore.
Key signing
-----------
Key IDs may not be unique, they're relatively short numbers. And since it
is possible to have a key with your name on it which isn't yours, we need
a way as unique as a fingerprint to identify a key, don't we?
knghtbrd@galen:~$ gpg --fingerprint 0xDCF9DAB3
pub 1024D/DCF9DAB3 1999-03-01 Joseph Carter <[EMAIL PROTECTED]>
Key fingerprint = 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9
DAB3
uid Joseph Carter <[EMAIL PROTECTED]>
uid Joseph Carter <[EMAIL PROTECTED]>
uid Joseph Carter <[EMAIL PROTECTED]>
uid Joseph Carter <[EMAIL PROTECTED]>
sub 2048g/3F9C2A43 1999-03-01
Now, let's assume you take that output and either write it down or print
it out on paper? If that person is reasonably sure that you are who you
say you are, they could also be reasonably sure that the above key really
is yours. By reasonably, do I mean that it's still possible for two keys
to have the same information on them, fingerprint and all? Technically,
the possibility still exists, however it's also possible that you'll win
the lottery in thirty-six countries at the exact same time--it's just not
very likely now is it? =) If you're not convinced it's secure, it might
well be time to invest in a tinfoil hat.
A key signing works about like this: You and a person you know each take
the information you got from the fingerprint command and meet eachother
someplace. You'll then need to prove that you are who you say you are,
and they'll need to do the same. Picture ID is the expected way to do
this, and some people will expect you to bring two such forms of ID with
you. They are probably being paranoid, but remember that when a person
signs your key, they're vouching for your identity. If you are found to
not be who you say, you will not be trusted, and they will not be trusted
either. Paranoia in these cases is possibly quite justified.
Once you've both agreed that you know eachother, you exchange pieces of
paper with the information about your key fingerprint, and hopefully agree
on a way to verify the email and person belong to eachother. (People
often do not do this, unfortunately.) So let's assume this person was
Bill Gates, and after Billyboy and I met, he gave me the following key
fingerprint:
pub 1024D/EC52CDCF 2003-01-08 Bill Gates (640 bits oughtta be
enough...) <[EMAIL PROTECTED]>
Key fingerprint = 11E9 D5EB 4441 13A8 9187 AA32 8941 CEFD EC52
CDCF
sub 768g/542962BA 2003-01-08
(Yes, that's a forged key..) Now, I run gpg --fingerprint 0xEC52CDCF to
see that the fingerprint matches what "Bill" gave me. The information
matches, so I'm comfortable signing his key. Remember that a signature
verifies only that a person is who they say, not that you are endorsing
them in any way. To edit the key in question:
knghtbrd@galen:~$ gpg --edit-key 0xEC52CDCF
gpg: checking the trustdb
gpg: checking at depth 0 signed=18 ot(-/q/n/m/f/u)=0/0/0/0/0/2
gpg: checking at depth 1 signed=3 ot(-/q/n/m/f/u)=18/0/0/0/0/0
pub 1024D/EC52CDCF created: 2003-01-08 expires: never trust:
-/-
sub 768g/542962BA created: 2003-01-08 expires: never
(1). Bill Gates (640 bits oughtta be enough...) <[EMAIL PROTECTED]>
Command> _
The first command you will want is probably ? for help. There are a lot
of commands in here, and we won't talk about many of them. The one we
want is sign:
Command> sign
pub 1024D/EC52CDCF created: 2003-01-08 expires: never trust:
-/-
Primary key fingerprint: 11E9 D5EB 4441 13A8 9187 AA32 8941 CEFD
EC52 CDCF
Bill Gates (640 bits oughtta be enough...) <[EMAIL PROTECTED]>
How carefully have you verified the key you are about to sign actually
belongs to the person named above? If you don't know what to answer,
enter "0".
(0) I will not answer. (default)
(1) I have not checked at all.
(2) I have done casual checking.
(3) I have done very careful checking.
Your selection? _
Let's assume that when I met Bill, I didn't like the looks of this seedy
character. I didn't believe a word he said, so I very carefully checked
him out. He showed me two forms of picture ID, his birth certificate,
swore a blood oath, and exchanged secret information I was able to use to
verify that he not only was Bill Gates, but that he really was
[EMAIL PROTECTED] as well. How much do you trust your own research?
Okay, well I decided that Billyboy might still be lying, so we made him
submit to DNA scans and stuff. Unfortunately, I couldn't find anything
else to put him through---er, I mean, I was by this point convinced of his
identity and that he really was who he said, so I felt safe saying that I
did careful checking:
Your selection? 3
Are you really sure that you want to sign this key
with your key: "Joseph Carter <[EMAIL PROTECTED]>"
I have checked this key very carefully.
Really sign? y
You need a passphrase to unlock the secret key for
user: "Joseph Carter <[EMAIL PROTECTED]>"
1024-bit DSA key, ID DCF9DAB3, created 1999-03-01
Enter passphrase:
Command> _
Now I need to ask myself an important question: I have verified this guy's
identity, but if he were to sign someone else's key, do I honestly think
he'd be careful to check other people out much before he went ahead and
signed their keys? If I can answer that question, I should let GnuPG know
the answer:
Comman> trust
pub 1024D/EC52CDCF created: 2003-01-08 expires: never trust:
-/-
sub 768g/542962BA created: 2003-01-08 expires: never
(1). Bill Gates (640 bits oughtta be enough...) <[EMAIL PROTECTED]>
Please decide how far you trust this user to correctly
verify other users' keys (by looking at passports,
checking fingerprints from different sources...)?
1 = Don't know
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision? 3
pub 1024D/EC52CDCF created: 2003-01-08 expires: never trust:
m/-
sub 768g/542962BA created: 2003-01-08 expires: never
(1). Bill Gates (640 bits oughtta be enough...) <[EMAIL PROTECTED]>
Please note that the shown key validity is not necessarily correct
unless you restart the program.
Command> _
Here I have decided that Bill will at least check an ID or something like
that. I chose marginal not because I actually believe that, but because I
wanted to explain it. ;) If you know a person will sign a key because
someone emailed him asking for a signature, you know that person's
signature isn't worth the electrons required to show it to you and their
signatures will never prove a thing. A person signature from a person who
is fully trusted will always be considered to be as good as if you'd made
the signature yourself. Several signatures from people which you
marginally trust will be consiered good enough to validate a key. The
manpage will explain how this works. One command left to enter:
Command> save
Now I'd normally upload this key to pgp.net and send a copy to Bill, but
since this isn't really his key, I'm going to revoke and remove the key.
A paranoid (and therefore good) way to handle key signing and key signing
parties can be found at http://people.debian.org/~jaqque/keysign.html if
you want to really be sure.
I was going to go into details about configuring GnuPG with mutt, but I'll
do that later. =)
msg12368/pgp00000.pgp
Description: PGP signature
