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.
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.
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.
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
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 --output
julien.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 --import
D13A0DCC.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.
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:
--default-cert-level
[0-3]
Sets the default check level. It should be set to 1, which means that the key owner's identity was not verified.
--min-cert-level
[0-3]
Should be left to the default value 2, meaning only imported keys that were correctly checked by verifying the key fingerprint and the owner's identity should be signed.
The default model with its three marginally trusted keys required to trust a new key, or one fully trusted key can be modified:
--marginals-needed
n
Set to n
the minimum number of marginally trusted keys needed to trust a new key.
--completes-needed
n
Set to n
the minimum number of fully trusted keys needed to trust a new key.
These numbers should only be increased from their default value, not decreased, to keep a safe Web of Trust model.
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
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.