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. SeeAdministering 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:
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.
The command for exporting a key for a user is:
If no UID has been submitted all present keys will be exported. By default the output is set to
gpg --export [UID]
stdout. But with the
-ooption this is sent to a file. It may be advisable using the option
-ato 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.
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:
if the filename is omitted the data will be read from
gpg --import [Filename]
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:
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.
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
all present keys will be displayed. To see the signatures as well type:
(see Key signing for further information). To see the fingerprints type:
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:
Note that listing fingerprints and signatures from private keys has no use what soever.
In order to delete a public key you type:
For deleting a secrete key you type:
gpg --delete-key UID
There is one more important command that is relevant for working with keys.
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.
gpg --edit-key UID
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.
gpg --edit-key UID command for the key that needs to be signed you can sign it with the
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