Next Previous Contents

3. Using keys

3.1 Creating a key

With 

gpg --gen-key
a new key-pair is created (key pair: secret and public key). The first question is which algorithm can be used. You can read more about algorithms in PGP DH vs. RSA FAQ or in Applied Cryptography. You can easily (and maybe you should - since it is used so widely) use DSA/ ElGamal. This is not patented.

The next question is key length. This is something that is very user dependent. You need to choose between security and calculating time. If a key is longer the risk for cracking the message when intercepted decreases. But with a larger key calculation time also increases. If computing time is an issue you still should consider that you want to use the key for sometime. We all know that arithmetic performance increases very quickly, since new processors are getting quicker and quicker. So keep this in mind. The minimal key length GnuPG demands is 768 bits. However some people say you should have at a key-size of 2048 bits (which is also really a maximum with GnuPG at this moment). For DSA 1024 is a standard size. When security is a top priority and performance is less an issue you ought to pick the largest key-size available.

The system now asks to enter names, comment and e-mail address. Based upon the entries here the code is calculated. You can change these settings later. See Administering keypairs.

Finally you have to enter a password (actually passphrase would be more appropriate, since blanks are allowed). This password is used to be able to use the functionality which belongs to your secret key. A good passphrase contains the following elements:

By sometimes using CaPItaLs aNd SOMEtimes NoT you can build in further security. When you make your password make sure that you WILL NOT FORGET it. Since if you do messages are not legible and the use of your secret key has gone. It might be wise to generate some kind of a certificate containing this information (of course be careful that nobody gets to your passphrase). See Revoke.

After everything was entered the systems starts generating the keys. This will take some time. During that time it needs to collect a lot of random data. By working in a different screen you can help the system collecting changing random data. As you understand by now, the key will be always different. If you generate a key now and 5 minutes later with exactly the same data, you'll get two different keys. Now you must understand why you shouldn't forget your password.

3.2 Exporting keys

The command for exporting a key for a user is: 

gpg --export [UID]
If no UID has been submitted all present keys will be exported. By default the output is set to stdout. But with the -o option this is sent to a file. It may be advisable using the option -a to write the key to a 7-bit ASCII file instead of a binary file.

By exporting public keys you can broaden your horizon. Others can start contacting you securely. This can be done by publishing it on your homepage, by finger, through a key server like http://www.pca.dfn.de/dfnpca/pgpkserv/ or any other method you can think of.

3.3 Importing keys

When you received someone's public key (or several public keys) you have to add them to your key database in order to be able to use them. To import into the database the command looks like this: 

gpg --import [Filename]
if the filename is omitted the data will be read from stdin.

3.4 Revoke a key

For several reasons you may want to revoke an existing key. For instance: the secret key has been stolen or became available to the wrong people, the UID has been changed, the key is not large enough anymore, etc. In all these cases the command to revoke the key is: 

gpg --gen-revoke
This creates a revocation certificate. To be able to do this, you need a secret key, else anyone could revoke your certificate. This has one disadvantage. If I do not know the passphrase the key has become useless. But I cannot revoke the key! To overcome this problem it is wise to create a revoke license when you create a key pair. And if you do so, keep it safe! This can be on disk, paper, etc. Make sure that this certificate will not fall into wrong hands!!!! If you don't someone else can issue the revoke certificate for your key and make it useless.

3.5 Key administration

With the GnuPG system comes a file that acts as some kind of database. In this file all data regarding keys with the information that comes with the keys is stored (everything until the Ownertrust values: for more information on that read Key signing). With 

gpg --list-keys
all present keys will be displayed. To see the signatures as well type: 
 gpg --list-sigs
(see Key signing for further information). To see the fingerprints type: 
gpg --fingerprint
You want to see "Fingerprints" to ensure that somebody is really the person they claim (like in a telephone call). This command will result in a list of relatively small numbers.

To list the secret keys you type: 

gpg --list-secret-keys
Note that listing fingerprints and signatures from private keys has no use what soever.

In order to delete a public key you type: 

gpg --delete-key UID
For deleting a secrete key you type: 
 gpg --delete-secret-key

There is one more important command that is relevant for working with keys. 

gpg --edit-key UID
Using this you can edit (among other things) the expiration date, add a fingerprint and sing your key. Although it is too logic to mention. For this you need your passphrase. When entering this you will see a command line.

3.6 Key signing

As mentioned before in the introduction there is one major Achilles' heel in the system. This is the authenticity of public keys. If you have a wrong public key you can say bye bye to the value of your encryption. To overcome such risks there is a possibility of signing keys. In that case you place your signature over the key, so that you are absolutely positive that this key is valid. This leads to the situation where the signature acknowledges that the user ID mentioned in the key is actually the owner of that key. With that reassurance you can start encrypting.

Using the gpg --edit-key UID command for the key that needs to be signed you can sign it with the sign command.

You should only sign a key as being authentic when you are ABSOLUTELY SURE that the key is really authentic!!!. So if you are positive you got the key yourself (like on a key signing party) or you got the key through other means and checked it (for instance by phone) using the fingerprint-mechanism. You should never sign a key based on any assumption.

Based on the available signatures and "ownertrusts" GnuPG determines the validity of keys. Ownertrust is a value that the owner of a key uses to determine the level of trust for a certain key. The values are

If the user does not trust a signature it can say so and thus disregard the signature. Trust information is not stored in the same file as the keys, but in a separate file.

Next Previous Contents