PGP/GnuPG Howto =============== This document is not intended as a replacement for the manual pages of GnuPG or PGP. Instead, it aims to explain what key-signatures, the web-of-trust and the OpenPGP implementation are all about, and how to use the keyservers. In order to understand why these things are potentially the case, you first need to understand some of the properties of the various types of cryptosystems involved. Symmetric Cryptotgraphy ----------------------- Until Whitfield Diffie and Martin Hellman's paper in the mid 1970s, the only way for a civilian to communicate data in a secure fashion was to meet in advance, and arrange a key. This key obviously needs to be arranged in such a way that noone else would be able to eavesdrop on the arranged key, otherwise the communication channel is not secured. The Diffie-Hellman Paper ------------------------ The paper entitled "New Directions in Cryptography", and published in 1976 in the IEEE Transactions on Information Theory claimed to solve the Key Distribution Problem above, by using a new type of cryptosystem, the public-key cryptosystem. In a public-key cryptosystem, one party has a "public key" for the other, and the other party has a corresponding "private key". Encryption operations made with the public key can only be decrypted using the private corresponding part of this key. In this way, Diffie and Hellman foresaw the use of a public directory of keys, so that when you wanted to communicate with someone, you'd pick out their public key from the directory, and send them data encrypted with that key, and only they'd be able to decrypt it. The Identity Problem -------------------- In fact, this "directory" doesn't quite solve the Key Distribution problem on its own, instead it raises another problem. This problem boils down to: "how do I know that this public key belongs to the person it claims to belong to?". In the agreed key cryptosystems described above, it was easy, you arranged keys with the person, and you knew that you were going to be talking to them. In the public-key case, you could meet, and he could give you a copy of his key. This is better than the previous case, because the contents of the meeting can still be open, but you still have to meet. Digital Signatures ------------------ Out of the public key cryptosystems came a slight modification, where still a part of the key is public, and the other part is private, but in this case, the private key is used for encryption, and the public for decryption. It is not immediately obvious that this is useful, until it is realised that everyone can verify (using the public part) that the private part created a given ciphertext.[1] Message Digests --------------- This is the third part of the cryptosystem. All that really needs to be considered is that a Message Digest function reduces a plaintext to a fixed-size ciphertext. This transformation is one-way (ie. it is not possible to determine what the original message was from the digest), and that there is not a linear dependence on the plaintext (so that a given transformation on the input will not produce a predictable transformation on the output, that is, you can't manipulate the message in such a way as to get a chosen ciphertext). Key Signatures -------------- Since in the identity problem, meetings are often a problem, we can use the property of the Digital Signatures mentioned above. I can have a meeting with someone, and sign a plaintext consisting of (their public key, some identity credentials). Thus anyone who believes me can believe that this identity is theirs, because only I could have created the signature. It is important that what I am signing is the _association_ between the key and the identity, and not either thing on its own. In the case of X.509 and SSL, this signature, and the plaintext are called a "certificate", and I'll use that term. It follows that if A certifies (B's key, B's credentials) and B certifies (C's key, C's credentials), then it is possible for A to believe the association signed by B, depending on how much she trusts B to do the verification. Similarly for someone believing A's key belongs to her. Certification Infrastructures ----------------------------- There are several obvious infrastructures of signing chains to come out of the possibility of key certificates. The first is what is often incorrectly referred to as "PKI" (this in fact covers all possible infrastructures), which consists of certification keys which sign that the next level in the hierarchy can certify things within that hierarchy, and so forth. This means that there will only tend to be one certificate on a given public-key, and has the disadvantage of needing a root Certificate Authority. Another fairly standard method is known as the PGP web-of-trust. In this model, everyone certifies as many keys as they can, and then in trying to evaluate the trustworthiness of a (key, credentials) binding, a user looks at what possible signature paths there are to the key. This means that each key has to have multiple independent signatures on it. PGP and The OpenPGP Specification --------------------------------- When Phil Zimmerman wrote PGP in 1991, he opted for the latter model. In order to achieve this he wrote a format for the keys to be in which are based on "packets" of data. Important packet-types in modern PGP keys (found by doing a gpg --with-colons --fixed-list-mode --list-sigs using GnuPG) are "pub", "uid" and "sig". A large number of keys will have a "sub" too, but this is for primary keys which can only sign (in the case of DSA keys) to be able to have data encrypted to them too. pub is the public key packet, and contains the actual numbers used for encrypting data. uid is an identification credentials packet. It normally contains a name and an email address. There are other types of identification credentials packet, but "uid" is by far the most common. sig will tie the previous uid packet to the pub packet as a certificate by the person making the signature. Since packets can be added at any time, to any point within the key, a uid packet needs a "self-signature" which certifies that it was added by someone who had access to the private key too. The PGP Keyservers ------------------ As a consequence of the random-access database necessary to add keys, the keyservers are an open directory. It is important that anyone can upload to their key, as key/uid bindings are protected by their own self-signatures. The keyserver's job is to merge in packets that have just been uploaded, with the packets that it already has. Thus a key may only grow in size. Note that they have to be open for anyone to upload anything they want, because there is no way of stopping an attacker just by limiting the ability of a particular binary. Revocation Certificates ----------------------- The problem of revocation is a non-trivial one to solve. The current method in OpenPGP is to make a second signature, surpassing the first, which includes as part of the message that the certificate is no longer valid. So to terminate a public-key/uid binding, you issue a revocation certificate on the binding. (this will go in as a "rev" packet in the listing). Keysigning Parties and the Verification of Identity --------------------------------------------------- It's worthwhile noting that in general the certification on a key is not for the certifier's benefit, because often all that they care about is that this person's key belongs to the same person that they were talking to yesterday. Since it's a lot of effort to reliably communicate 1024 bits, what actually happens is that a message digest is taken of the public key, and that this is the thing that is communicated, so that when a key is fetched from the keyservers, if it digests to the same thing, it is regarded to be the same key. A lot of the pgp-using community go to "keysigning parties". The idea of such a thing is that one takes some (non trivially-fakeable) piece of identity, such as a passport, and that you hand out the message digest of your public key. The other people there are all doing them, and when you come out, you've got mutual trust in the identities of the attendees. The problem with such a "keysigning party" is as follows: If my name is John Smith, and I want to pretend to be a different John Smith, then I can generate a fake key, and uid: uid John Smith I then hand out cards with my name on it, and of course, show my passport, which prooves that I am John Smith, but not necessarily the John Smith with that email address. I have done a social engineering attack on the people there who don't know me to sign an identity that I'm not. Some people mitigate this problem by attempting to send a mail which is PGP encrypted to the user with the key, and including a unique string in it. This is a reasonable thing to do, given that this ties the key with the email address, the most useful binding that other people will rely on your signature for. Certifying Keys Using GnuPG --------------------------- So far this has all been relatively abstract, but when you actually want to sign a key, it's worth thinking about what the procedure should be. You should get two things to identify the key, a "key ID" and a "key fingerprint". On newer keys, the key ID is just the last 32bits (or 64 if you use long key IDs) of the fingerprint. The identity credentials are separate. 1. Download the key as it stands from a keyserver gpg --keyserver wwwkeys.uk.pgp.net --recv-keys 0x This imports the key into our local "public key ring", which is, effectively our own miniaturised keyserver database. 2. Go into "key editing" mode gpg --edit-key 0x This allows us to go into the mode where we will be able to sign it. Once you do this, you'll be presented with an interface with all the identity credentials. Select all the ones you want to use by typing their number in at the prompt. 3. Go into the signing mode (at the "Command> " prompt in gpg's edit-key mode) sign This will come up with some text with the fingerprint, the uids you have selected and some text asking if you really want to sign this key. At this point, you say "yes", and it will ask you for your passphrase. When it has done this, it will have made a signature, but it won't have saved it back into the public keyring. 4. Save the key (at the "Command> " prompt in gpg's edit-key mode) save This will quit the key-editing mode, and saves the new packet to the local public keyring. 5. Upload your changes on the key to the keyserver gpg --keyserver wwwkeys.uk.pgp.net --send-keys 0x This will send the updated key, and the keyserver will merge in any packets it has not already got (which will include the signature you have just made). ------------------------------------------------------------------------------- [1] In fact this is not quite how digital signatures work, in general you keep the plaintext available, and sign a message digest of the plaintext.