GnuPG for Daily Use (a Mini How-To...)

This summary is not thought to be a complete description of GnuPG and all its aspect. However, it shall be an introduction and a quick reference, mainly thought for people who have not yet used GnuPG so far or have just started. For more information refer to the listed links.

It is supposed that the reader uses a UNIX-like system and that GPG already has been installed on the system (as this is the case for all tardis-users).

Cryptography has two main tasks: It shall provide secrecy and authenticity. Secrecy means that a message written by a person A can only be read by a person B that is chosen by A. Authenticity, on the other hand, shall ensure that person B who receives a message can be certain that this message has been written by A and not by anyone else.

There are quite a lot systems that fulfill these tasks. However, those conventional systems have the big drawback that A and B have to exchange secret keys in advance. This is not only very annoying, but even sometimes impossible (for example if B lives very far away from A etc.). GPG solves this problem in a very clever way: Instead of having only one key that both, A and B, have to know, every user has two keys, a public one (known to everybody) and a private one (which has to be kept secret). The clue is now that if a message is encrypted by the public key, it can only be decrypted again with the private key, and the other way round.

So, if A encrypts his message with the public key of B, then nobody can decrypt it anymore except B as only he has the corresponding private key. And, on the other hand, if A encrypts his message with his private key, then only the public key of A can decrypt the message again, which is known to B. But as only A can have encrypted the message in such a way that the public key of A decrypts it again, B can be sure that the message has been written by A.

Thus, if A does both, encrypting with his private key and the public key of B, then only B will be able to read the message and B will be sure that it has been A who has sent the message.

In order to get started, you have to create your pair of public and private key, respectively, and you have to make the public key known to as many people as possible. For the latter, there are large key-servers distributed over the whole world that are connected to each other. So, if you send your key to one server, this server will automatically inform all other severs about your key. And if you need the key of anybody, you may "ask" any server for it. The way how to do this will be explained below.

For creating a key-pair, you have to take a free shell and execute the following commands:

Answer of the shell

Your command

>

gpg --gen-key

Choose 1 2, or 5:

1

What key size?

2048 (I recommend to use the longest key size)

Key is valid for:

(press return)

Real name:

Stefan M. Moser (of course use YOUR name...)

Email address:

<stefan.moser@quark.ch> (of course use YOUR email address...)

Comment:

(Any comment you would like to be stated as part of your identity, e.g. "A guy from Switzerland"; you can leave this also empty)

Okay?

o (or correct any mistake you have made)

Enter pass phrase:

(The pass phrase can be any sentence, including all kind of special characters. It shouldn't be too short and simple. However, you will have to type this quite often and you HAVE to be able to remember it...)

Enter again:

(once again...)

We need to generate a lot of random bits...

(If this is asked, just type randomly on your keyboard any characters)

Now you have a new directory, called .gnupg, and a private and public key. To check this, type:

Here, and also in the following chapters, we mean with <description> anything of your name or email-address or part of it. So for example if the User-ID is "Stefan M. Moser <stefan.moser@switzerland.NOSPAM.org>", then <description> could be anything like

This shows that actually you have got two key pairs, but this should not bother you as these keys belong together and can be looked at as only one. The Key-ID (mine is 91AD85E1) together with the finger-print (the 10x4 digits) uniquely determines your key. Furthermore it shows that so far only you have signed this key. What this means, we will see later. As a next step it is very important to generate a revocation-certificate.

Now, you have created a key. But how to destroy it again? Perhaps you think that this is not important at the moment, and basically you are right. However, there is a problem: In a few month or years a lot of people will know your public key. So, in case you do not want to use this key anymore (perhaps because you forgot the secret sentence, or because somebody found it out etc.), you will have to tell everybody. Otherwise you will keep receiving emails that are encrypted with this key. In order to do so, there is a so-called revocation-certificate. If this certificate is sent to the key-servers the key is definitively "destroyed". The reason why I tell you this now, is the following: It is only possible to make a revocation-certificate if you know the secret sentence. So if you forget it, then you can’t use your key anymore, but you can’t destroy it neither. Therefore, it is very important that you prepare this certificate NOW as now you should still know your secret sentence, right?

You have to do the following steps:

Answer of the shell

Your command

>

gpg -a --gen-revoke <description> (the description should be part of your name, like in my case "moser")

Create a revocation certificate for this key?

y

Select the reason for the revocation:

(I guess either 0 or 1 makes sense)

Enter an optional description:

(press return)

Is this okay?

y

Passphrase:

(Give your passphrase)

Now the revocation certificate is generated. It should look something like the following

Now, you have reached the step where you can make your key public. The easiest way of doing so is to use one of the many key-server. Which server you use doesn't really matter as they are connected and update each other at least daily. For example you could use the server at the MIT:

gpg --keyserver=x-hkp://pgp.mit.edu -a --send-keys <key-ID>

As at the moment you only have your own key in your keyring, you may also drop the description. A second possibility is using a web-interface, like for example at the ETH: www.tik.ee.ethz.ch/~pgp. There you will have to copy-paste your key. In order to be able to copy your key, the following command:

Now, your key is already public. We will test this in a second. There is just one small nice feature: instead of every time specifying the keyserver, it is easier if you define it in your config-file. Edit the file .gnupg/gpg.conf: search for "keyserver" and uncomment or add the entry keyserver x-hkp://pgp.mit.edu. If you have done so, you may check, if your key is already available:

You will be presented with a list of possibilities, depending on how specific your description has been (this list can be very long if you just search for a "Peter" or so!). At the moment just type q to quit.

In order to be able to decode and encode mails with the public key of other users, it is important that you have those keys. As it is not very practical to have to ask every time a key-server for such a key, you keep your own key-ring with all keys of those people you often communicate with.

At the moment, I guess the only key in your key ring is the one you just have created. If you are not sure about that, you may check it, as seen above, by:

<description> can be anything of the name or email-address (or part of it) of the key that is not needed anymore. If you try to remove a key where you own also the secret key, then you will have to remove first the secret key by gpg --delete-secret-keys.

As mentioned above GPG solves the problem of the need of exchanging keys in advance. As replacement public and private keys are introduced. However, by doing so a new problem appears: If I receive (by a keyserver, or mail etc.) a public key from somebody, how do I know that this key REALLY belongs to the person it is said that it belongs to? There could be just anybody create a key under my name and use it and nobody would realize that it is not me!!

The only solution to this problem is, that I have to be very careful in accepting other keys, i.e., I have to be sure that key and person belong together. This can be checked by comparing the Key-ID and the fingerprint (see above). This is not really satisfactory, as you will agree. Therefore, one has searched for better ideas - and has found one: I don't need to be able to check if a key and a person belong together, as long as there are a few friends of mine (that I trust) that confirm a certain key! And this is done by the "key-signing". If I sign the public key of another person (by using my key), then I confirm that this key belongs to the person that it should. Or the other way round: If I receive a public key of someone I don't know, but see that his key is signed by several people I do know, then I may be sure that this key also is a correct key that I may use.

Therefore, it is important that your key is signed by as many people as possible, and you will probably also sometimes be asked if you would sign a key. Do so, but only do it if you are really sure that the person you ask for a signature and the key you are signing belong together!

Firstly, you should print out your Key-ID and fingerprint (use gpg -v --fingerprint <description>) and sign this paper by hand. This can be useful whenever you have to prove to someone that this is YOUR public key.

In order to sign a public key, you must have the key in your key-ring. The way how to include a key into your key-ring is described above. When you have the key and you are sure that it is the right key, then you sign it as follows:

After you have signed it, nobody knows about this new signature. Thus, next, the key has to be sent again to the owner of the key or even better back to a key-server. This is done exactly the same way as before:

gpg -a --send-keys <key-ID>

The owner who receives such a newly signed public key only has to include it again into his key-ring. Note: GPG and the key-server realize that the key has been included already once and will only update the signatures of the key!

If you want to be able to decrypt your file afterwards again, then you probably should use your own public key... Choose for example as description your Key-ID (with 0x in front, e.g., 0x91AD85E1). A new file will be generated that is called file.asc. Note that the option -a makes sure the output is ASCII and not binary, if not set you will get a binary file called file.gpg.

To decrypt your file again use the following command:

gpg -d -o newdecryptedfilefile.asc/gpg

You will be asked for your passphrase. The decrypted file is stored in newdecryptedfile.

However, it is not very convenient, if you have to write your mail firstly, then encrypt it, and then finally send it. Thus, it would be easier if the mail-program knew how to deal with gpg. And this is the normally the case. Below follows now the example of the mail-program pine.

Pine offers the option to include additional filers to choose from just after you press Ctrl-x for "send your mail". We will show how to set these up in a second. However there is one small problem we have to solve beforehand: GPG always uses only one interface (gpg and all details are specified in the given options. In pine however you will not see the options, but just the name of the program. So, in order to be able to specify several different filters that you can distinguish, we have to introduce artificially some new names for gpg. First you have to find out where the gpg is situated:

which gpg

You will get an answer that could look, e.g., like /usr/sepp/bin/gpg. Use this path to generate the following aliases in a reasonable directory like, e.g., in your bin/:

With pine you write your mail as usual. When you want to send it, you have to press Ctrl-x (also as usual). However now, you can choose so-called "filters". Normal is "unfiltered". By pressing Ctrl-n or Ctrl-p you can get to "gpg", "encrypt", and "sign". The first filter will encrypt and sign your mail, the second only encrypt and the third only sign. Pine will automatically figure out to whom you send the mail and use this person's public key (if it is in your key-ring, otherwise there will be an error!). Just try it, it is really easy!

Receiving mails with pine is even easier: Everything is done automatically. You only have to read your mails as usual, and in case an encrypted message is coming in, you will be asked for your passphrase automatically.

You will have noticed that the setup of the pine filters is such that every mail is encrypted both with the recipient's key and with your own key. The reason behind this is the following: if you only used the recipient's key then the message that is stored in your "Sent"-folder is encrypted such that you will never be able to decrypt it anymore! So the additional encryption with your own public-key makes sure that you will be able to read your own email also after the encryption process. (Many thanks to Clemens Hofmann for this hint!)

Note that there are several clever programs to simplify the use of gpg with pine even more (see the links below).

GPG is used by thousands of people (up to half a million already). Therefore, it is important that you show a certain care when using it. Mainly, it is really important that you only sign keys where you are absolutely sure that key and person belong together.

However, the most important point one has to remember when using GPG is that one should NEVER enter the pass phrase by remote (rlogin, telnet, etc.; exception: ssh, as ssh encrypts the transmission to the other computer), and never on a computer which one does not know or is not logged in (it is really easy to find out what you have typed, even afterwards when you have left already!).

If you want to "delete" your key on all servers, you have to use a revocation certificate, as described above. If you still know your passphrase, then you can create a such one easily (again see above). If you have forgotten your passphrase, then HOPEFULLY you have created a revocation certificate at the time you created your key, otherwise you are lost... In order to revoke your key, you have to import your revocation certificate into your keyring:

gpg --import <file>

Here, file should contain the revocation certificate. Now, you just have to send your own key on a key-server, as described above.