Generating Keys

Before you can use GPG, you must generate a key. The first time you ever run GPG, it will probably say this:

  [bubba@mars bubba]$ gpg gen-key

  gpg (GnuPG) 1.0.1; Copyright (C) 1999 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: /home/bubba/.gnupg: directory created

  gpg: /home/bubba/.gnupg/options: new options file created

  gpg: you have to start GnuPG again, so it can read the new options file

Unless your system administrator has a .gnupg directory set up for new accounts automatically, GPG must create a .gnupg directory and set it up with default configurations and empty private and public keyrings. A keyring is simply a file that stores keys. The default is to have two: pubring.gpg and secring.gpg. Your private keys are kept in secring.gpg, and your public key and the public keys of any of your correspondents are in pubring.gpg.

The other file in the .gnupg directory is options. This file may be modified to change the default settings for GPG. In its default state, it is configured to interoperate with the commercial PGP 5 software. I recommend leaving these defaults alone until the whole world wakes up and starts using GPG instead!

Once the .gnupg directory is set up, you generate a key as follows :

  [bubba@mars bubba]$ gpg gen-key

 gpg (GnuPG) 1.0.1; Copyright (C) 1999 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.

 Please select what kind of key you want:

 (1) DSA and ElGamal (default)

 (2) DSA (sign only)

 (4) ElGamal (sign and encrypt)

 Your selection? 1

I can't think of any reason not to generate both key types. You will then be prompted for key length:

 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

 Do you really need such a large keysize? yes

 Requested keysize is 2048 bits

I'm not certain why they object to large keysizes. The truth is, all of these keysizes are more than adequate to protect you against any reasonably resourced attacker. The default 1024 keysize is such that a brute-force attack, assuming geometrically increasing computational power, should take you well past the expected life of the universe. That's pretty good. Besides which, most secrets need only be kept for a short time. Many business secrets, such as new product names and quarterly financial disclosures, need be kept only for days or weeks. After that, they need not be secret. Other secrets may need to last one or two human generations. A very few secrets must be kept indefinitely. It is certainly true that the minimum GPG keysize is more than adequate for most purposes. Even so, I elected to use a large key to show how GPG behaves. Note that 2048 is not an upper limit; you may use an even larger keysize than this. I would suggest the default keysize for most purposes.

The key-creation dialog continues thusly:

 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) 10w

 Key expires at Tue 12 Sep 2000 04:29:02 PM CDT

 Is this correct (y/n)? y

Here you have the option of expiring your key. Once a key expires, it may no longer be used to encrypt, sign, decrypt, or verify messages. Having a key expire is probably a good idea. We set this key to expire in the realtively short period of ten weeks.

The process continues:

 You need a User ID to identify your key; the software constructs the user ID

 from Real Name, Comment, and E-mail Address in this form:

 "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

 Real name: Leroy Macmillian

 E-mail address: leroy@flatbush.nonesuch.org

 Comment:

 You selected this User-ID:

 "Leroy Macmillian <leroy@flatbush.nonesuch.org>"

 Change (N)ame, (C)omment, (E)-mail or (O)kay/(Q)uit? o

So we gave the fictitious Leroy a user ID consisting of his name and his e-mail address. You may also add a comment. We chose not to here.

Finally, we have to protect the private key. To do this, we use a passphrase. A pass phrase is much like a password, but the length is much greater. Just as in passwords, I recommend mixing upper- and lowercase letters and some nonalphabetic characters as well. Here's what the dialog looks like:

 You need a passphrase to protect your secret key.

 Enter passphrase:

Having entered the passphrase once, you are prompted again:

 Repeat passphrase:

The program now starts generating your keys. In order for a key to be secure, it must be unpredictable. There are many pseudo-random algorithms, many of them rely on the nonrepeating decimal places of irrational numbers. These numbers appear random, but if you know the algorithm they are entirely predictable. Such "random" sequences are useless for generating keys.

The GPG program on Linux makes use of a rather nifty feature of our favorite operating system. Linux maintains an entropy pool. Linux times the clock ticks between various interrupts, such as keystrokes, disk drives , serial ports, and network interfaces. It uses these to maintain an ever-growing pool of random bits. Though in a strict mathematical sense these bits are not necessarily random, they are complex, asynchronous, and very difficult to predict. This is as close to random as you are likely to find this side of the Heisenberg principle.

As these keys are generated, this pool of random bits is depleted. It is possible that the pool could become exhausted during the key-generation process. If that happens, the key-generation process stops until user activity on the system raises the pool size to a level sufficient to continue. The user at the console may help the process along by typing or moving the mouse. Don't worry about "mixing up" the time between your keystrokes. At the speed at which the system counts things, you will never have the same value for two keystrokes no matter how hard you try.

In our example, our "random pool" was not quite large enough to do the job without stopping:

 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, utilize the

 disks) during the prime generation; this gives the random number

 generator a better chance to gain enough entropy.

 ++++++++++++++++++++++++++++++.++++++++++++++++++++.+++++.+++++++++++++++

 ++++++++++++++++++++++++++.++++++++++.+++++++++++++++.++++++++++.........

 ....>++++++++++

 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, utilize the

 disks) during the prime generation; this gives the random number

 generator a better chance to gain enough entropy.

 +++++.+++++...+++++++++++++++++++++++++++++++++++.++++++++++....+++++++++

 ++++++++++++++.++++++++++++++++++++++++++++++++++++++++....++++++++++++++

 ++++..++++++++++>++++++++++++++++++++>+++++.>+++++.......................

 ........................................................+++++^^^^^

 public and secret key created and signed.

 [bubba@mars bubba]$

If you look now, your keyrings are no longer empty.

To extract your public key so you can share it, use the following command:

 [bubba@mars bubba]$ gpg --export --armor leroy

 -----BEGIN PGP PUBLIC KEY BLOCK-----

 Version: GnuPG v1.0.1 (GNU/Linux)

 Comment: For info see http://www.gnupg.org

 mQGiBDliXhYRBACPy47P0e71DUe+SvSSepRxi23KpM3xhLu3BsjQmKK5oNwShcPx

 LivsXB3WZZpdQ0TCPbf4DiihYOCo6FtPvPqFKqlLr/xiJq4SJ0syJFIivGKgiEx2

 EHApzxwxOwBuhR+Qb80/aquBpN5sQwCGolAlPN6Vawd9gut8kCXBQkBpEwCg91CO

 mUEMjXa50BfYDEkABkg9J/UD/0XaXz0yny5t9pKZvzXLuuI+7ZkXSbxt3jiaJfnM

 sBNro2ZmXGSWx25Fr1mz5h49TKlmgvm1/icJ9qym8b1v336xt+7lN9ZZfjOgx9A8

 C+t77wPIy3ADc5hkFh70RiduylQjs3EKafqMB5ZFtXYqLqvmyZO3vp6CPtgJXirF

 f6IhA/9nPBOyxD7tHNGWA7cm3VhQieVbQKbQzYmFVaMVKz62KYB6mJvOIs0EZsR9

 E75CuikJ52eJwzbuZKP+sfSjzUW3PDnnKrI4ER2hnfl/p+rqtJZ4VE/jgC9PWGgZ

 Ljju9W0tsXbFoxFxPDlFIKPqlyIFUxmUotYsMuqeCrLC71MdN7QuTGVyb3kgTWFj

 bWlsbGlhbiA8bGVyb3lAZmxhdGJ1c2gubm9uZXN1Y2gub3JnPohcBBMRAgAcBQI5

 Yl4WBQkAXEkABAsKBAMDFQMCAxYCAQIXgAAKCRCLHoAxDo+rZGf5AJ9ktBHkXffB

 bQLo/ax/LwWjQBMUYQCbBxhUNJJzg07RjlVhAHfKVCDtuGC5Ag0EOWJemhAIANSs

 TUaG69ly2lDbVenNLYLo4ydog8RU7GC5kLcLLwtlbDCZVd35puk9G2RzZgwmnCOc

 120bGFDtgW2dC/qixspojwgxPf002tf61BAJdQyVVJzm1n7D4mdXuP+j28OGlVh+

 NOZv9ImFiObUmQ2xdKnCSDBow9edbGH9IvMTNcDhkeCP87uWe3Sr6AexKx8jufOU

 FedQH0ZoQHzDtGcalmpK8DMXGT1oU8+KJBYMgJ2vz6L6hYsmFHUCCmwIIteafGkl

 No8VEy3/vntap45iaOYMGosgEg1dcCAs9drykFiyZ18JJh0n528w5gQfORciHM8d

 W8KqE2aTy3cueQLp+H8AAwcH/1KOIOmejQADrpgDs0tC8LrwgG7hpwKXhNop6EG1

 HRO6jxCkX/DVQNazfsTGkNPCDxgiNEZ+ejlR5w7i1zB67IIqAhVuFxOZ17H4FJIf

 Hj7p6B5zndhX272x2ZVHNvuKiHDbqkPe4MzAC6Ju8dJCjRSbvUbSol/DANtudP5H

 ndiBaxcFzSHM6ftQpGI2/ba7/d92C/7vXj0Rnpz2o0AQJ/vT327zVdIWpbtOdL+C

 dpxlrC3Vp9RdFi7Do/R+DgrDJT7Hvuw+17JDe0sctFeZsm+uxmCQigo4TkCzz5gK

 0WzZuKYMwoJRwNCQLLWpcOC0+UuDF2/OvlNpds17msiBV52ITAQYEQIADAUCOWJe

 mgUJAFxJAAAKCRCLHoAxDo+rZIlrAJ4gzhD8Z70r4dTcY3xQFc1fMttULACgmunL

 J/68lWMGBkNVrn4HEGOJMic=

 =qiUY

 -----END PGP PUBLIC KEY BLOCK-----

  [bubba@mars bubba]$

So there it is. The "--armor" option causes the key to be extracted in a "text" form, suitable for e-mail. Without the "--armor" option, the key is in a binary form that will neither display nor e-mail successfully.