Herein resides a brief (somewhat) tutorial on creating and signing PGP keys with GPG.  I’d originally intended to use this as the outline for a presentation on the subject, but decided to put it on the web so I could point people at it.  The introductory section (Basics) is pretty lean, but should provide enough of a background for simple stuff.  All of this is documented elsewhere on the web.

  • Motivation
    • I think that encryption should be an important part of any email system.
    • Much as I send regular mail in envelopes, not postcards, I prefer to send email encrypted.
    • In general, I think that everyone should be familiar with PGP for personal privacy reasons
    • In specific, I would, ideally, prefer never to send unencrypted personal email.
  • Basics
    • Briefly cover encryption. 
      • Scrambles data so unauthorized people can’t read it.
    • Types of secrets
      • Shared keys
        • Simplest form of encryption.
        • Some secret information (like a password) will both encrypt and decrypt.
      • public key systems
        • There are two keys.
        • Things encrypted with one of the keys can only be decrypted with the other.
        • Cannot tell by looking at one key what the other one is.
        • Keep one key secret and make other public.
        • Anyone can get public key and encrypt stuff for you.  Only you can decrypt.
    • Signing
      • Related to encryption
      • Signing takes some information and creates a “signature” from it.
      • The signature is a block of data that can be used to verify the origins of the signed information, much like a written signature on a document.
      • Usually used in PKC.
      • Example: Send an email, sign with private key.  Someone receives it and checks signature with your public key.  Only your public key can properly decipher the signature, so, if it does, it must have come from you.
    • PGP
      • Stands for Pretty Good Privacy
      • Not perfect, but good enough for most people.
      • Uses a public key system.
      • Keys represent a name and email address.
    • GPG
      • Stands for GNU Privacy Guard
      • Is a Free (open-source) implementation of the OpenPGP standard.
      • Interoperates with PGP 2.x and 5.x.
      • This tutorial will cover gpg.  Concepts will apply to PGP versions, but all the commands are gpg-specific.
  • Making a key. 
    • First, install gpg. 
      • Package in Debian is named gnupg.
      • I don’t know about packages for other distributions (other than that they exist).
      • If you want to compile from source, it’s at http://www.gnupg.org/.
    • As your normal user, run gpg --gen-key. 
      • First question is the type of key to make.  The default choice (DSA and ElGamal) is ok. 
        • [skip for presentation]
        • DSA key is used for signing things.  It cannot be used to encrypt.
        • ElGamal is the encrypting key.  It’s not as good at signing as DSA is because the signatures end up larger and it may be easier to attack an ElGamal signature.
        • Paranoid people may wish to use RSA for signing, because maximum size on a DSA key is 1024 bits.  In this case, the encryption key will have to be added afterwards.
      • Next question is about the size of the ElGamal key.  Again, the default (1024 bits) is decent. 
        • [skip for presentation]
        • The larger the key, the harder it is to brute-force the encryption.  (i.e. try every possible key and see which one decodes the message.)
        • 1024 bits is currently considered a reasonable size.
        • The minimum is 768, which isn’t really recommended for anything other than casual use.  It’s probably not safe from anything larger than a medium-sized business.
        • 2048 is the highest recommended size.  Every bit doubles the keys available, so 2048 is roughly 1.79e309 times harder to crack than a 1024 bit key. 
          • (I wanted to write out that number, but it would have been 17.9 followed by 25 millions (i.e. 17.9 million million million …).)
        • A key size of 2048 would be used for stuff that you would never want to be decrypted, even decades (and quite probably centuries) after your death.  Most people a) don’t need that sort of security and b) are insecure enough in other ways that it wouldn’t matter anyway.
        • Keys larger than 2048 bits are not recommended because using them would be very slow.
      • The next step is to choose the expiration date of the encryption subkey. 
        • The default option (no expiration) is probably the best choice for the average personal key.
        • An expiration is useful to force people to change encryption keys periodically.  This means that even if one of your keys is cracked, only a portion of your communications will be compromised.
        • Note that the expiration only applies to new uses of the key.  Items encrypted with a key before it expires can still be decrypted with the related private key after the public has expired.
      • Next, you must enter your personal information. 
        • “Real name” should be fairly obvious.  This should be at least your first and last names.  Nicknames are often acceptable if they’re unambiguous enough.  Initials will probably not be acceptable to most people who care about the name.  Some uses may require your full legal name.
        • “Email address” should be equally obvious.  Use your the main email address from which you expect to be doing most of your PGP work.
        • “Comment” is a field for further clarifying the purpose of this key.  If, for example, you have both work and personal keys, you could add a comment to each, indicating which is which.
        • Note that any number of these may be omitted.  You can specify an email address with no name or vice-versa, if you feel it’s appropriate.  (Note that some people may be unwilling to sign your key in these cases.)
      • Lastly, you need to enter a passphrase. 
        • The passphrase can (and should) be an actual phrase.  Generally, the longer the phrase is, the better, as it’s harder to guess that way.
        • The passphrase should also, however, be something that you’ll remember and will be able to type easily.  You’ll have to find your own balance between the two.
      • After all of the information is entered, gpg will go about making your keypair.  Under Linux, it uses /dev/random, which is a source of truly random data.  (i.e. there is no way to predict ahead of time what the data will be.)  gpg will probably ask you to generate entropy.  Do as it asks (type on the keyboard, move the mouse).  Network activity (e.g. downloading files) helps, too.
    • When that finishes, congratulations!  You’ve created your own personal keypair.
    • To admire your new key type gpg --list-keys "<your name>". 

      • You should get output looking like this:

        pub  1024D/13C62639 2001-12-07 Bob Transformer <moo@moo.org>
sub  1024g/46AEB2B6 2001-12-07

      • The number after the first slash (13C62639, in my example) is the key ID.  This is a number that uniquely refers to your key.  We’ll be using the key ID for many things in the future.

      • Note: gpg will try its best to find the keys you’re looking for.  If you give it a key ID, it’l use that key.  If you give it a name or an email address, it will use all of the keys that contain the string you gave it.  Whenever possible, use the key ID to ensure that you don’t accidentally use the wrong key.

    • The final step is to send your key to a public keyserver so that other people can easily get it. 
      • The simplest method is just to run gpg --keyserver <keyserver> --send-keys <key ID>. 
        • The best keyserver to use is probably wwwkeys.pgp.net.  The others should synchronize to that one periodically.
        • They don’t always sychronize properly, though.  the best solution is to use recv-keys, a script someone I know wrote to send (and receive) keys from every keyserver.
  • Signing keys
    • Concepts
      • Trust is an issue with keys.  Presumably you put your own name on the key you made, but you could just as easily have used someone else’s.
      • What guarantee do you have that when you get a key claiming to belong to, say, Piper Gold, that it’s really from me?
      • Personal introductions as an example. 
        • Suppose you had never met me before and someone walked up to you and said they were Piper Gold.  Would you believe them?  (You might.  Further suppose that you were going to give me $100.  Would you give the money to this person based merely on their claims about their identity?)
        • On the other hand, if someone you trusted introduced me to you, you’d probably be more likely to believe claims about my identity.
        • Public key signing works much the same way.
      • A signature on a public key works much as a digital signature on some other piece of information—it’s a block of data created with a private key that can only be verified with the corresponding public key.
      • The meaning is a little different, though.  If you sign an email, the signature is an indication that the email actually came from you.  If you sign a public key, the signature is an indication that you will vouch for the identity of the key’s owner.
      • Example:  I wish to converse with Nick.  I get Nick’s public key from a keyserver, but I’ve had no personal verification that the key really belongs to him.  However, I also have Ray’s public key and I’ve verified its validity.  I also trust Ray to sign keys.  If Ray has signed the key I downloaded, then I have a reasonable assurance that the key really does belong to Nick, as it claims. 
        • NB: GPG is really flexible about trust.  It has four settings for your trust of the key’s owner: full, marginal, none, and unknown (which is the same as none).  You can adjust the number of full and marginal signatures needed to trust a key you haven’t yourself signed.  For the record, I use the default settings (one full or three marginal) but am very parsimonious with placing even marginal trust in other people.
    • Actually signing a key
      • When you sign a key, you are declaring to the world that you believe the key actually belongs to the person it claims to.  Be careful, then, in what you sign.
      • Steps for verifying key validity. 
        • Talk to the person in a difficult-to-fake environment.  Face to face is best.  Barring that, a telephone conversation is probably good.  Pretty much anything online is right out.
        • Verify that the person is who they claim they are.  This is easy if you already know them or can be introduced by someone you trust.  Beyond that, you can check things like photo IDs and trust them if you have trust in the issuing institution.
        • Get the person’s key information.  You should get the person’s key ID and fingerprint. 
          • The key ID has been mentioned previously.
          • The fingerprint is a number derived from the key mathematically.  It uniquely identifies the key, much as your fingerprints identify you. 
            • NB: It is theoretically possible for two different keys to have the same fingerprint.  It is, however, statistically very unlikely that this would happen.  In addition, there is no known way to create a key with a specific fingerprint, which is why the fingerprint is a good method for verifying keys.
        • Go home.
        • Once home, if you don’t have the other person’s key, get it from the keyserver, either via recv-keys or gpg --keyserver <keyserver> --recv-keys <key id>
        • Now that you have the key, check its fingerprint

          • The command to do this in gpg is gpg --fingerprint <key ID>.

          • gpg will print something like

             pub  1024D/13C62639 2001-12-07 Bob Transformer <moo@moo.org>
      Key fingerprint = 89F4 5D99 CD48 EC3E 40CA  3D31 F1BF FFE2 13C6 2639
 sub  1024g/46AEB2B6 2001-12-07

          • Again, the key ID is the number after the first slash.  The fingerprint is the string of numbers after the equal sign on the second line.

        • If the key ID and the fingerprint you were given match the ones on your computer, you can be reasonably assured that you have the right key.
      • Once you’ve determined that the key is valid and belongs to its claimed owner, you can actually sign it. 
        • The command to do this is gpg --sign-key <key ID>.
        • GPG will show you the key information, including the key’s fingerprint.  You can double check the information at this point if you’re being paranoid.
        • Next, you’ll be asked how careful you have been in your verification of the person’s identity.  The default answer is probably safe, but using the others as degrees of trust is useful, presuming you have a set policy for signing keys. 
          • If you’re going to use the different levels of certification, you should use a policy URL.  You may look at mine for an example.
        • Finally, GPG will ask you if you’re sure.  If you’re certain you want to sign the key, say yes then enter your key’s passphrase.
      • After you’ve signed the key, you should send it to the OpenPGP keyservers so that when other people get that key they’ll get your signature with it. 
        • Again, use of recv-keys is recommended for sending the key, but gpg --keyserver <keyserver> --send-keys <key ID> will also work.
        • Note that the keyservers are smart about signatures.  When you send a key that the server already has, it will merge any new signatures (and uids and revocations, but I haven’t covered those) into the existing key.  Thus, two different people can grab a key at the same time, sign their local copies, and send them back in and the keyserver will end up with a single key with both signatures.
  • How to use your PGP key. 
    • Command line usage
      • man page—very “detailed”, but the ultimate reference.
      • encrypting files
        • gpg --encrypt <file>
          • Will ask for recipients.
          • If a recipient matches multiple keys, only the first match is used.
          • Result with be in <file>.gpg and will be binary data.  Send that file to the other person.
        • gpg --recipient <person> --armor --encrypt <file>
          • Recipient on command line, so does not ask anything.
          • Again, if more than one match, first match is used.
          • --recipient may be used multiple times to specify multiple recipients.
          • --armor creates file in ASCII text.
          • Result will be in <file>.asc.
      • decrypting files
        • gpg <file>
          • Will figure out file is encrypted and attempt to decrypt.
          • Will ask for passphrase on your private key so it can decrypt.
          • Result will be <file> with .asc or .gpg extension removed.
          • If file is ASCII-armored, gpg will extract the message, even if there’s other text around it.  (So you can give it an entire email and it’ll ignore the email headers and such.)
        • gpg --decrypt <file>
          • Same as above, but decrypted data is send to standard output.
        • gpg --output <other filename> --decrypt <file>
          • Decrypts and puts result into file of your choosing.
      • signing files
        • gpg --sign <file>
          • Asks for your passphrase, then signs the file.
          • Result is in <file>.gpg and is in binary format.
        • gpg --clearsign <file>
          • Leaves text document readable and places signature in ASCII text at the bottom.
          • Result is in <file>.asc.
        • gpg --detach-sign <file>
          • Creates a file named <file>.sig that contains just the signature.
          • Both the original file and the signature file are required to verify the signature.
      • verifying signatures
        • gpg <file>
          • gpg will figure out that the file is a signature and verify it.
          • If the signature was a regular or clear signature, the original file will be created, with a name based on <file>, less the .gpg or .asc extension.
          • If the signature was a detached signature, the original file must exist, with the same name as the signature file (without the .sig extension), and gpg will just tell you whether the signature matches or not.
      • [finding other people’s keys]
    • [~/.gnupg/options]
    • MUAs
      • mutt
        • Support is integrated already.  [in Debian; others need additional stuff?]
      • pine
      • Mozilla/Netscape Navigator
      • Eudora
        • Commercial PGP supports.
      • Outlook
        • Avoid like the plague, if at all possible.
        • Bad support for standards.
  • Further information

That should about cover it.  Please if you have any questions, comments, or suggestions about this tutorial.