Summary: Creating your PGP key takes just a minute, and is the first step to PGP security.

Jumping right in, let's create our PGP public/private key pair. I'll use GnuPG, the Gnu Privacy Guard, available at http://www.gnupg.org, and which is very likely already available with your Linux distribution. If you want to use older free or commercial PGP versions, the commands are very similar. Any GUI front end will also have the same functionality.

We'll create our key as follows. I'll intersperse comments as we go along.

  $ gpg --gen-key
  gpg (GnuPG) 1.2.3; Copyright (C) 2003 Free Software Foundation, Inc.
  This program comes with ABSOLUTELY NO WARRANTY.
  This is free software, and you are welcome to redistribute it
  under certain conditions. See the file COPYING for details.
  
  gpg: WARNING: using insecure memory!
  gpg: please see http://www.gnupg.org/faq.html for more information
  gpg: /home/jdoe/.gnupg: directory created
  gpg: new configuration file `/home/jdoe/.gnupg/gpg.conf' created
  gpg: WARNING: options in `/home/jdoe/.gnupg/gpg.conf' are not yet
       active during this run
  gpg: keyring `/home/jdoe/.gnupg/secring.gpg' created
  gpg: keyring `/home/jdoe/.gnupg/pubring.gpg' created

First the warning about insecure memory will appear if your gpg binary does not have the suid bit set. If you want to set it, then do the following:

  root# chmod u+s /usr/bin/gpg

GnuPG is exceedingly paranoid, so to protect your passphrase it wants to snag a chunk of secure memory[1], and it can only do this if it is running as root or with the suid root bit set. It drops root privs very very early on, so it's pretty safe to do this. If you do, you'll never see the warning again. I recommend you set this bit - paranoia is healthy.

The rest of these lines just show it creating various configuration and personal files in your home directory - you won't see these warnings in the future.

  Please select what kind of key you want:
     (1) DSA and ElGamal (default)
     (2) DSA (sign only)
     (5) RSA (sign only)
  Your selection?

Next we get to choose which type of public/private cryptography we want to use. The original PGP only supported RSA, which was unfortunately patented at the time. Later versions supported DSA keys as well. There's no reason to prefer RSA or DSA based on patents or licenses any more, and most PGP software supports either nowadays. Thus, unless you have a reason to choose one over the other, choose the default.

  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)

You're now given a choice of how strong you want your key to be. The bigger the number, the more secure it is, and the longer it will take when encrypting, decrypting, or signing messages. The security afforded by the key length is exponential - a key of 1025 bits is twice as hard to crack as one that is 1024 bits. Thus a 2048 bit key is 2^1024 times harder to crack than one that is 1024 bits - that's a real lot!

Most folks use 1024 bit keys currently. This strikes a decent balance between strength and speed. If you want a very secure key, for example if you want to create a key that does nothing but sign your other keys, then you may want to use a 2048 bit key.

  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)   0

You can have your key expire at a specific time in the future if you wish. For example, I create a new key every year, so each key is set to expire about a year after I create it. Once a key expires, no one can encrypt to it without ignoring warnings about the fact it's expired. We'll see later that there's a difference between a key expiring (allows the key to become invalid at a very specific time in the future, as declared at key creation time) and a key revocation (a way for you to say that the key is no longer valid immediately, for example if it was compromised.)

  You need a User-ID to identify your key; the software constructs
  the user id from Real Name, Comment and Email Address in this form:
  "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
  
  Real name: John Doe
  Email address: jdoe@example.com
  Comment: My First PGP Key
  You selected this USER-ID:
      "John Doe (My First PGP Key) <jdoe@example.com>"
  
  Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?   o

Real Name

Your real name. Include your preferred name here, for example if you go by 'J. Henry Doe' then use that, rather than 'John Doe'.

Email Address

Your email address, obviously.

Comment

Not necessary, but helpful if you may create multiple keys for different purposes so folks can differentiate them. For example I have a 'Key-Signing-Key', and that's the comment I use for it.

These bits of info are used when folks want to search for your key when they encrypt files/email to you, so be accurate. We'll see how to create additional user-ids later, for example if you have multiple email addresses and want them all listed.

Next comes the all important part - creating a passphrase:

  You need a Passphrase to protect your secret key.
  
  Enter passphrase: passphrase
  Repeat passphrase: passphrase

Lastly, gpg creates the key itself. This involves a lot of number crunching to find big prime numbers and perform some mathematical wizardry, so it takes a while. As it works, it shoots characters across the screen so you don't think it's locked up:

  We need to generate a lot of random bytes. It is a good idea to perform
  some other action (type on the keyboard, move the mouse, utilise the
  disks) during the prime generation; this gives the random number
  generator a better chance to gain enough entropy.
  ++++++++++++++++++++++++++++++.++++++++++++++++++++.++++++++++
  +++++++++++++++++++++++++++++++++++.+++++.+++++++++++++++..+++
  +++++++.+++++....+++++>.+++++..........+++++
  
  Not enough random bytes available.  Please do some other work to give
  the OS a chance to collect more entropy! (Need 299 more bytes)
  We need to generate a lot of random bytes. It is a good idea to perform
  some other action (type on the keyboard, move the mouse, utilise the
  disks) during the prime generation; this gives the random number
  generator a better chance to gain enough entropy.
  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  +++.++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  +++++++>...+++++<.+++++......>+++++...>.+++++.....<+++++.
  ..<+++++........>+++++.+++++^^^^^^^^^^^^

gpg needs to create a secure key - that means it should be very different than keys created by others. It needs to rely on a good sampling of random numbers in order to be secure. If it is unable to get enough random data, it will wait until it can get more. It even suggests things you can do to help create more random data in the kernel.

  gpg: /home/jdoe/.gnupg/trustdb.gpg: trustdb created
  public and secret key created and signed.
  key marked as ultimately trusted.
  
  pub  1024D/D5D3BDA6 2003-12-14 John Doe (My First PGP Key) 
       Key fingerprint = 0E43 DC31 C484 431C 5B07  3875 7B2D D3D8 D5D3 BDA6
       sub  1024g/26F8D783 2003-12-14

Finally, GnuPG is all done. It created another file, the trustdb which we'll see later. It ends by showing us the information associated with our new key.

NOTES:

[1] Here, 'secure memory' means memory that cannot be swapped out to disk if the system gets low on physical memory. It's not bullet proof - it could still be swapped out if you did a suspend on a laptop, for example.

Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. He's having twin girls in January, and you can help shape them for life! Go to http://www.ifokr.org/bri/name-the-twins.cgi to pick your favourite name from the possibilities! Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2003

This is the December 31, 2003 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Security-request@lists.onsight.com.