Create Your GPG Keys

Once GPG is installed, you must create your keys. Follow these steps:

[julien@asus ˜]$ gpg --gen-key
gpg (GnuPG) 1.4.2.2; Copyright (C) 2005 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)
   (5) RSA (sign only)
Your selection? 1
DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits

The choice of proposed keys may be different. A DSA key for signing and an ElGamal key for encryption are the default choices and the best options. Other versions of GPG can offer the possibility to use the same ElGamal key for both signing and encryption. If ElGamal is used to create the digital signature, this signature is much larger than a DSA signature. To have the same level of security, the ElGamal key must be twice as long as the DSA key because it is easier to attack.

Warning

RSA used to be patented and might not be offered to you. If you choose it, your signatures cannot be checked by older GPG versions. If you prefer to use an RSA key for signing, use option 1 and then add a new RSA key after this process is complete.

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)
Key does not expire at all
Is this correct? (y/N) y

You can set an expiration date if the key is only used temporarily. Once the expiration date is chosen, it is not possible to change it. Any key can be manually revoked at any time (see the section "Revoke a Key," later in this chapter).

A good policy is to set an expiration date on your keys. This avoids the common problem of having a valid key sitting on public key servers when its private key and the revocation certificate have been lost.

Warning

If you choose to use a key with an expiration date, you may create a new key before the current one expires and then sign it with your current key to keep your Web of Trust. Or you can simply extend the expiration date with the expire command.

You need a user ID to identify your key; the software constructs the user ID from the "Real name," "Comment," and "email address" in this form:

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

Real name: Julien Sobrier
email address: address@domain.com
Comment:
You selected this USER-ID:
    "Julien Sobrier <address@domain.com>"

You must provide your real name and real email address. Your name is used by other users to verify your identity while the email address is used to match a key with the sender account when encrypting an email.

It is possible to add multiple email addresses to a key (e.g., if you share the same key for work and home):

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

You should not share your private key with anyone. If somebody gets access to it, your keys are compromised and must be revoked. To avoid writing the private key in plain text on the computer, it is encrypted with a passphrase. A passphrase should be a phrase rather than a single word password to ensure better security. This passphrase is usually required every time GPG needs to access your private key. It can also be cached for a short period of time if you so prefer.

[...]
gpg: key D13A0DCC marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:   2  trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1  valid:   2  signed:   0  trust: 2-, 0q, 0n, 0m, 0f, 0u
pub   1024D/D13A0DCC 2006-08-07
      Key fingerprint = 9219 DD61 4AE3 D5E2 4FC9  A6D8 4B1A 6D12 D13A 0DCC
uid                  Julien Sobrier <address@domain.com>
sub   2048g/79D37518 2006-08-07

Using this procedure, the keys are now created. The main key is the 1024-bit DSA key with the fingerprint DD61 4AE3 D5E2 4FC9 A6D8 4B1A 6D12 D13A 0DCC. Each key has a key ID (D13A0DCC for the DSA key, 79D37518 for ElGamal). The key ID is not necessarily unique.

Tip

If you received a warning message Using insecure memory, it means that the memory pages cannot be locked; therefore, the keys may be written on the hard drive, so your secret key kept in memory could end up on your hard drive in clear text.

To lock memory, GPG must either be run as root, or setuid root on GPG:

sudo chmod u+s /usr/bin/gpg

GPG displays the rules for the Web of Trust. In this example, three paths are needed if the key owner is marginally trusted, or one path if the user is fully trusted. Your own key is marked as fully trusted.

To prevent anybody from modifying the user ID of your keys, your keys must be signed before you export them to a public keyserver. This is done automatically.

There are other important things to consider before exporting your keys to a keyserver. First, you should back up your private key. You should make a hard copy of your encrypted key and put it in a safe deposit box in case you forget your passphrase or lose your private key file.

To list your private keys, type the following command:

[julien@asus ˜]$ gpg --list-secret-keys
/home/julien/.gnupg/secring.gpg
-------------------------------
sec   1024D/D13A0DCC 2006-08-07
uid                  Julien Sobrier <address@domain.com>
ssb   2048g/79D37518 2006-08-07

Then, the private key can be printed out:

[julien@asus ˜]$ gpg --armor --export-secret-keys D13A0DCC | lpr

Warning

Do not use a network printer! They usually use an unencrypted protocol, so anybody could intercept your private key.

The --armor argument is used to display everything in plain text instead of binary. The --export-secret-keys argument to save the output to a file should not be used because it would save the secret key unencrypted on the hard drive, especially if it is an SMB or NFS shared volume. All private subkeys should be printed the same way.

Finally, you must create a revocation certificate. It is required to revoke the key in case it is compromised. Do not save this certificate to a file, print it out and place it in a safe deposit box. If someone was able to access it, they could revoke your key.

[julien@asus ˜]$ gpg --armor -gen-revoke D13A0DCC | lpr

You can now send your public key directly to your correspondents:

[julien@asus ˜]$ gpg --outputjulien.gpg --export D13A0DCC

Or it can be sent to the default keyserver:

[julien@asus ˜]$ gpg --send-key D13A0DCC

The ElGamal key was added as a subkey. Other subkeys and other users could be added:

[julien@asus ˜]$ gpg --edit-key D13A0DCC
[...]
pub  1024D/D13A0DCC  created: 2006-08-07  expires: never       usage: CS
                     trust: ultimate      validity: ultimate
sub  2048g/79D37518  created: 2006-08-07  expires: never       usage: E
[ultimate] (1). Julien Sobrier <jusob@free.fr>

Command><tab>
addcardkey clean    fpr     nrsign   revuid   trust
addkey   delkey   help    passwd   save    tsign
addphoto  delsig   key     pref    setpref   uid
addrevoker deluid   keyserver  primary   showphoto
adduid   disable   keytocard  quit    showpref
bkuptocard enable   list    revkey   sign
check    expire   lsign    revsig   toggle

Command> adduid
Real name: Julien Sobrier
email address: address@work.com
Comment: Work address
You selected this USER-ID:
    "Julien Sobrier (Work address) <address@work.com>"

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

You need a passphrase to unlock the secret key for
user: "Julien Sobrier <address@domain.com>"
1024-bit DSA key, ID D13A0DCC, created 2006-08-07


pub  1024D/D13A0DCC  created: 2006-08-07  expires: never       usage: CS
                     trust: ultimate      validity: ultimate
sub  2048g/79D37518  created: 2006-08-07  expires: never       usage: E
[ultimate] (1)  Julien Sobrier <address@domain.com>
[ unknown] (2). Julien Sobrier (Work address) <work@address.com>

Command> add<tab>
addcardkey  addkey      addphoto    addrevoker  adduid
Command> addkey
Key is protected.

You need a passphrase to unlock the secret key for
user: "Julien Sobrier <address@domain.com>"
1024-bit DSA key, ID D13A0DCC, created 2006-08-07

Please select what kind of key you want:
   (2) DSA (sign only)
   (4) Elgamal (encrypt only)
   (5) RSA (sign only)
   (6) RSA (encrypt only)
Your selection? 5
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
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)
Key does not expire at all
Is this correct? (y/N) y
Really create? (y/N) y
[...]
pub  1024D/D13A0DCC  created: 2006-08-07  expires: never       usage: CS
                     trust: ultimate      validity: ultimate
sub  2048g/79D37518  created: 2006-08-07  expires: never       usage: E
sub 2048R/F168B82E created: 2006-08-07 expires: never    usage: S
[ultimate] (1)  Julien Sobrier <address@domain.com>
[ unknown] (2). Julien Sobrier (Work address) <address@work.com>

Command> save

You must repeat the last step of 15.11 to export the new keys to the key server.

One key can be mapped to more than one email address. However, you may need different keys for different email addresses. For example, you could have a key used at home on a secure machine and a different key for work on shared disks.

You have the choice to create different primary keys or different subkeys. The best solution is to create your primary and a subkey at home, on a secure machine, rather than on a machine you don't control completely and may not belong to you forever. Then export the private subkey on a moveable storage device, such as a USB key, and import the subkey at work:

[julien@secure ˜] gpg --armor -export-secret-subkeys D13A0DCC >
/usb_key/ D13A0DCC.gpg

The subkey can now be imported on the insecure machine:

[julien@unsecure ˜] gpg --importD13A0DCC.gpg
[...]
gpg: key D13A0DCC: secret key imported
gpg: key D13A0DCC: public key "Julien Sobrier (Work address)
<address@work.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1

[julien@unsecure ˜] gpg --list-secret-keys
[...]
sec# 1024D/D13A0DCC 2006-08-07
uid                  Julien Sobrier <address@domain.com>
uid                  Julien Sobrier (Work address) <work@address.com>
ssb   2048g/79D37518 2006-08-07
ssb   2048R/F168B82E 2006-08-07

The same thing must be done to import the public key. Now you can cancel a subkey at any time and keep the primary key secured.

The # in sec# indicates that the primary secret is not present in the machine. This prevents anybody, including you, from signing new keys. Any subkey can be revoked with the primary key. So, if you do not have access to your insecure machine at work, you can still revoke the subkey from your home computer.

Warning

If you choose to use different subkeys, associate them with different email addresses. GPG email plug-ins use the recipient email address to choose the public key. If different keys are associated to the same email address, you can receive emails encoded with a subkey that is not present on your computer.

It is possible to change the Web of Trust model with the -trust-model option. It is not safe to change this value, except for the direct model. This skips validating the key through the Web of Trust to ask you if the key was validated.

When a public key is imported, a certification level is set that indicates how much it can be trusted and depends on how well the owner identity was verified. The current Web of Trust model can be finetuned with the cert-level options:

The default model with its three marginally trusted keys required to trust a new key, or one fully trusted key can be modified:

You can list the keys already imported from a file or from a keyserver.

To import a public key from a keyserver, use the following commands:

[julien@asus ˜]$ gpg --recv-keys DBC967BA
gpg: requesting key DBC967BC from hkp server wwwkeys.eu.pgp.net
gpg: key DBC967BC: "A Friend <friend@company.com>" 8 new signatures
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:   2  trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1  valid:   2  signed:   0  trust: 2-, 0q, 0n, 0m, 0f, 0u
gpg: Total number processed: 1
gpg:         new signatures: 8

The output explains that the eight keys signed by A Friend were also imported. Before the key is signed, we must get the fingerprint in order to verify it with its owner:

[julien@asus ˜]$ gpg --fingerprint DBC967BA
pub   4096R/DBC967BC 2005-05-11
     Key fingerprint = 47ED 22F9 51D9 BA85 E235 265F 8448 D230 DBC9 67BC
uid                  A Friend <friend@company.com>
sub   4096R/B69AF904 2005-05-11

After careful verification, the key can be signed:

[julien@asus ˜]$ gpg -sign-key DBC967BA

At any time, you can see the list of keys you have signed:

[julien@asus ˜]$ gpg -list-keys

You can revoke your own key either by uploading a revocation certificate directly to a key server or by using the revkey command:

[julien@asus ˜]$ gpg --edit D13A0DCC
[...]

Command> revkey
Do you really want to revoke the entire key? (y/N)y

Your passphrase is required to revoke the key or its subkey.

The keyring is the list of public keys you have imported. To delete a key from your keyring, use the following command:

julien@asus ˜]$ gpg -delete-key D13A0DCC

Warning

My version of GPG has 298 command-line options. It is hard to remember all of them. I recommend installing the package bash-completion (also available with Cygwin). Once it is installed, the Tab key used for filename completion can also be used to complete options. For example, typing gpg --delete<tab> gives all the options starting with --delete.

The limitation of bash-completion is that the list of options for each tool is hardcoded. The version of bash-completion and GPG should be synchronized by your distribution, but this is unfortunately not always the case.