Whole document tree
    

Whole document tree

Gnu Privacy Guard (GnuPG) Mini Howto (English): Using keys 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 questionis 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 therisk 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 keylength 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 this settings later. See Administering keypairs. One should select a longer valid e-mail address, since the complete user identifier is signed. If you modify the address somewhat the signature will not apply under the modified specification. Finally you can enter some comments. You can enter anything there and can be quite usefull.

Finally one has 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:

  • it is long,
  • it has special (non alphanumeric) characters,
  • it is something special (not a name),
  • it is very hard to guess (so NOT names, birthdates, phonenumbers, number of a credit card/checking account, names and number of children, ...)
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 somekind of a certificate containing this information (of course be carefull that nobody gets to your passphrase). See < ref id="GPG-Minihowto-Revoke" name="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 starting contacting you secure. This can be done by publishing it on your homepage, by finger, through a key server 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. The import into the database the command looks like this:

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

3.4 Revoke a key

For several reasons one may want to revoke a 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 certificat 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 systems comes a file that acts as somekind 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 
One wants to see "Fingerabdrücken" 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 one has a wrong public key you can say bye bye to the value of your encryption. To overcome such risks there is a possiblity of signing keys. In that case you place your signature over key 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 one can start encrypting.

Using the gpg --edit-key UID command for the key that needs to be signed you can sing 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 keysigning 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

  • 1 = Don't know
  • 2 = I do NOT trust
  • 3 = I trust marginally
  • 4 = I trust fully
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 seperate file.


Next Previous Contents