• Home
• About me
• Publica-
  tions
• IT-Scripts
• Lectures
• Software/
  Manuals
• Links
• Private
•  
•  
• 
  
•  

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.

Contents

1. What is GPG?
2. To get started
   1. To create a new key pair
   2. Revocation-Certificate
   3. To make your public key public
3. Your Personal Key-Ring
   1. Adding a key to your personal key-ring
   2. Removing a key from your personal key-ring
4. The Whole Story of Trusted and Untrusted Keys and Signing Keys
   1. How to sign a public key
   2. Keep your key-ring updated
5. Encrypting and Decrypting
   1. How to set up pine for use with GPG
   2. Sending emails with pine
   3. Receiving emails with pine
   4. A comment about pine
6. Security Tips
   1. How to use the revocation certificate
7. Links to Other Websites about GPG

1. What is GPG?

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 different systems that fulfill these tasks. However, many 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). 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 except B, because 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 (which is known to everybody). But as only A can have encrypted the message in such a way that the public key of A decrypts it, 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.

2. To get started

In order to get started, you have to create your own pair of public and private keys 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.

2.1 To create a new key pair

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

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

gpg --list-keys <description>

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

Stefan
Moser
stefan
stefan.moser
stefan.moser@switzerland.NOSPAM.org
stef
oser

etc. If you want to list all your keys just give no argument, i.e.,

gpg --list-keys

In my case the answer of the shell looks as follows:

	    /home/smmoser/.gnupg/pubring.gpg
	    --------------------------------
	    pub  1024D/91AD85E1 2004-03-10 Stefan M. Moser (Blabla) <moser@quark.ch>
	    sub  2048g/A19D8175 2004-03-10
	  

Actually, you will get more info if you include the option -v in your command, and even better is the following:

gpg -v --fingerprint <description>

which gives an output like:

	    smmoser@tardis-a04:~>gpg -v --fingerprint
	    /home/smmoser/.gnupg/pubring.gpg
	    --------------------------------
	    pub  1024D/91AD85E1 2004-03-10 Stefan M. Moser (Blabla) <moser@quark.ch>
	    Key fingerprint = 8530 BA60 156A EF97 2616  189B D573 397C 91AD 85E1
	    sig 3       91AD85E1 2004-03-10   Stefan M. Moser (Blabla) <moser@quark.ch>
	    sub  2048g/A19D8175 2004-03-10
	    sig         91AD85E1 2004-03-10   Stefan M. Moser (Blabla) <moser@quark.ch>
	  

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.

2.2 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 either. Therefore, it is very important that you prepare this certificate NOW as now you should still remember your secret sentence, right?

If you have used the --full-generate-key option above, then the revocation certificate actually might have been generated already. Check the output in your shell! You should find it in .gnupg/openpgp-revocs.d or similar.

You can manually start the generation of a revocation certificate as follows:

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

	    -----BEGIN PGP PUBLIC KEY BLOCK-----
	    Version: GnuPG v1.2.3 (SunOS)
	    Comment: A revocation certificate should follow
	    
	    iEkEIBECAAkFAkBQW9oCHQAACgkQ1XM5fJGtheGdYgCdGLN32ck9F3CL3lb2Rbef
	    weZOg00An3gedAc9chK5aSAAnjCwRC0Vftsv
	    =luxm
	    -----END PGP PUBLIC KEY BLOCK-----
	  

Copy these few lines into a file and store it in a safe place. Best on a floppy disk or print it out and keep the paper somewhere safe.

2.3 To make your public key public

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.

Warning: Keyservers do never allow you to delete keys in it. If you don't want a particular key anymore, you can revoke it using the revacation certificate, but the key will still be on the server and will be stored there “for ever”.

Which server you use doesn't really matter as they are connected and update each other at least daily. The easiest is to use the default keyserver that is given by gpg directly:

gpg --auto-key-locate keyserver -a --send-keys <key-ID>

Or you could manually specify the server, e.g., 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 where you will have to copy-paste your key. In order to be able to copy your key, type:

gpg -a --export <description>

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:

gpg --search-keys <description>

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.

3. Your Personal Key-Ring

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:

gpg -v --list-keys

3.1 Adding a key to your personal key-ring

If you have a file with a public key then you may add this key to your key-ring in the following way:

gpg --import <file>

However, it is even easier to get the keys directly from a key-server: use again the command

gpg --search-keys <description>

and choose in the list the wanted key. And that's it.

3.2 Removing a key from your personal key-ring

Of course you can also remove any key from your key-ring:

gpg --delete-key <description>

<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.

4. The Whole Story of Trusted and Untrusted Keys and Signing 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 who asks for a signature and the key you are signing belong together!

4.1 How to sign a public key

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!

4.2 Keep your key-ring updated

As you normally don't know when someone is signing a public key that is also inside your key-ring, it is important to update your key-ring from time to time. This is done by the following command:

gpg --refresh-keys

Then all your keys in your key-ring are compared with those on the key-server and if necessary they are updated.

5. Encrypting and Decrypting

You can encrypt any file using the following command:

gpg -e -a -r <description> file

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 newdecryptedfile file.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.

5.1 How to set up pine for use with GPG

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/:

cd yourhomedirectory/bin
ln -s /usr/sepp/bin/gpg encrypt
ln -s /usr/sepp/bin/gpg sign
ln -s /usr/sepp/bin/gpg gpg

Of course use the path you have found above for the path of gpg! Now, you can set up pine by copying the following lines into .pinerc at the right place:

	    display-filters=_LEADING("-----BEGIN PGP MESSAGE-----")_ yourhomedirectory/bin/gpg --decrypt,
            _LEADING("-----BEGIN PGP SIGNED MESSAGE-----")_ yourhomedirectory/bin/gpg --decrypt
	    
	    sending-filters=yourhomedirectory/bin/sign --clearsign,
            yourhomedirectory/bin/encrypt -a --encrypt -r _RECIPIENTS_ -r moser@quark.ch,
            yourhomedirectory/bin/gpg -a -s --encrypt -r _RECIPIENTS_ -r moser@quark.ch
	  

yourhomedirectory/ has to be replaced by the path to your home-directory, and moser@quark.ch with your own key description. Now everything should work.

5.2 Sending emails with pine

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!

5.3 Receiving emails with pine

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.

5.4 A comment about pine

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).

6. Security Tips

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!).

6.1 How to use the revocation certificate

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.

7. Links to Other Websites about GPG

This introduction is quite short and of course does not contain all information about using GPG, neither about GPG itself. If you like to read more, here are a few links:

• The official GnuPG Homepage
• The GnuPG Manual
• MIT PGP Key Server
• Pine Privacy Guard
• PGP Envelope

Furthermore, the man-page is also very helpful:

man gpg

In case you know some more useful links, or have even written a site about GPG, please mail to !

This page is completely new. Therefore, I would be very happy to hear of you! Please, send any comments, suggestions about paragraphs that are not clear, any mistakes or also positive feedback to !

-||-   _|_ _|_     /    __|__   Stefan M. Moser
[-]     --__|__   /__\    /__   Senior Scientist, ETH Zurich, Switzerland
_|_     -- --|-    _     /  /   Adjunct Professor, National Yang Ming Chiao Tung University, Taiwan
/ \     []  \|    |_|   / \/    Web: https://moser-isi.ethz.ch/

Last modified: Sat Jul 23 08:26:59 UTC 2022