People find cryptography confusing. This isn't surprising; it's hard. Because people get confused, they make mistakes. Making mistakes with cryptography can have really bad consequences. Unlike many computer tasks, there's no `undo' button for sending a copy of your private key to someone. The only way to fix this is practise. I hope these exercises help people become more competent at using cryptography.

These exercises are aimed at someone with basic Unix knowledge who's trying to figure out how to use GnuPG. I also assume a fairly basic level of knowledge of PKI (that there exist public and private keys, and public-key crypto is different from symmetric crypto).

These exercises were written using gnupg version 1.2.2 since that's what I have on my system. They may or may not work similarly for you if you're using a different version.


  1. Prepare an environment
  2. Create a key
  3. Adding and revoking subkeys
  4. Revocation Certificates
  5. Changing identity
  6. Importing and exporting keys
  7. Signing keys
  8. Signing other things
  9. Encrypting things

Exercise 0

Prepare an environment

Create new users on your system. I'll be using greta and harold in these examples. You can use Alice & Bob if you like. Whatever works for you. You don't have to do this, but it helps keeps things separate.

Run gpg as each user to ensure everything is set up. Where it says Go ahead and type your message ..., just press ^D to finish. This step is important otherwise when you come to create your key, it'll fail after going through the whole process.

Exercise 1

Create a key

In order to do anything, you'll need keys. So we'll start by creating them.

  1. As greta, type gpg --gen-key.
  2. Select DSA and ElGamal and a 768-bit keysize for the ElGamal key. There's no point in going larger for these throwaway keys.
  3. Make it expire in 3 days in case these keys ever leave your machine.
  4. Your name is Greta User and email address is ( is reserved by RFC2606). Leave the comment field empty.
  5. Just use greta as your passphrase for this throwaway key. There are many good pieces of advice on the web for choosing a strong passphrase for when you come to create your real key.
gpg should now have spat out something like:
gpg: /home/greta/.gnupg/trustdb.gpg: trustdb created
public and secret key created and signed.
key marked as ultimately trusted.

pub  1024D/52A5860A 2003-05-18 Greta User <>
     Key fingerprint = 03A8 BADD 30E2 DD61 FBCF  BEBD 6C51 CBBE 52A5 860A
sub   768g/4562DCB1 2003-05-18 [expires: 2003-05-21]
The fingerprint and dates will be different for you.

Now do the same thing for Harold. In order to spice things up a little, Harold is going to use an RSA key rather than a DSA key. This is mostly to show that it doesn't matter and we can all play together, no matter what algorithms we choose. A strong RSA key would be 2048 bit so Harold can use a 1024 bit key for this throwaway key.

Again, make the key expire in 3 days time; your name is Harold User , your email addres is and your passphrase should be harold. Note the differences in output:

gpg: /home/harold/.gnupg/trustdb.gpg: trustdb created
public and secret key created and signed.
key marked as ultimately trusted.

pub  1024R/637A5632 2003-05-18 Harold User <>
     Key fingerprint = 13C4 D0E9 E4F8 03C6 4C5B  8193 2D6C 5D3B 637A 5632

Note that this key cannot be used for encryption.  You may want to use
the command "--edit-key" to generate a secondary key for this purpose.

In particular notice the last two lines. We'll deal with that in exercise 2.

If you want to practise some more, create more users and generate keys for them. Or delete the .gnupg directory and start again.

Exercise 2

Adding and revoking subkeys

You're probably wondering what a subkey is. Most cryptographers agree that it's bad practice to use the same key for both signing and encrypting. So in the past many people would have two keys; one for signing and one for encrypting. This was quite a pain to manage, so the OpenPGP spec (RFC2440) includes support for subkeys.

Normally your primary key should be for signing and your secondary key for encrypting since you have to sign your encrypting key. Due to the way GnuPG works, Greta has a primary DSA (for signing) and a secondary ElGamal key (for encrypting). Harold only has a primary RSA key. So let's give Harold a secondary key for encrypting.

As the user harold

  1. Type gpg --edit-key harold
  2. At the Command> prompt, type addkey
  3. Select the RSA (encrypt only) option. Again, this key can be 1024 bits for testing but should be longer for real purposes. Make it expire in 3 days too.
  4. Type save to exit.

Now Harold has an encryption subkey.

It is good practice to not encrypt too much data with the same key. How much is too much and how much data is actually encrypted in a hybrid cryptography system like OpenPGP is an excellent question, but it can happen that people wish to revoke their subkeys.

Now, Greta hasn't yet distributed her key to anyone so she could just delete her subkey rather than revoking it. But in practice, by the time you want to change a subkey, you've already distributed it to people who now need to know not to use it. Deleting it from your key wouldn't tell them they need to stop using it, so you have to send them a revocation certificate instead.

As greta,

  1. Type gpg --edit-key greta
  2. Type addkey to add a replacement ElGamal encryption key. Again, make it 768 bit and expire in 3 days.
  3. Type key 1 to select the first of the subkeys. It should have a * by it to indicate it's selected.
  4. Type revkey to revoke it. You can enter a reason and a description for why you're revoking this subkey.
  5. Type save to exit.

gpg --fingerprint greta still shows the old key but if you type gpg --list-sigs greta, you'll see the new line:

rev         52A5860A 2003-05-18   Greta User <>
which indicates the revocation certificate.

For more practise at this, you can add and revoke more subkeys. You can also use the delkey command to delete keys which you've never sent to anyone.

Exercise 3

Revocation Certificates

It's fairly rare to have just the encryption sub-key compromised. Normally the entire key is compromised or lost. In these situations, you need to revoke the primary key. Of course, you have to generate your revocation certificate in advance; if you lose your key, you can't generate a revocation certificate.

So let's generate one now.

  1. Type gpg --gen-revoke harold
  2. Again, you can specify a reason and a description if you wish.

You should receive something like:

Version: GnuPG v1.2.2 (GNU/Linux)
Comment: A revocation certificate should follow

As the instructions say, this would normally be stored somewhere secure. For the purposes of this exercise, just copy-and-paste it into a file called harold-rev.asc.

Now you want to test it. Since testing it will render Harold's key useless, take a back-up of the .gnupg directory first. Type cp -a .gnupg gnupg-save to save it. Then type gpg --import harold-rev.asc. Just as with revoking subkeys, you need to type gpg --list-sigs harold to determine that the key is revoked.

Before you go any further, you probably want to rm -rf .gnupg and mv gnupg-save .gnupg so you don't accidentally do anything with the revoked key.

For further practise, generate a revocation certificate for Greta.

Exercise 4

Changing identity

The identity on these keys shows them to belong to employees of If Greta or Harold change jobs, they'll need to change the email address on their key. They might also have several email addresses for which they want to use the same key.

User IDs can be added and revoked in a similar way to subkeys. So let's give Greta her second identity.

As greta,

  1. Type gpg --edit-key greta
  2. At the Command> prompt type adduid
  3. Greta's name is still Greta User, but this is her home rather than work address, so enter for her email address and put Home in the comment field to point out to people this is her home address.
  4. Now enter the passphrase to unlock the secret key so it can sign the new identity.
  5. Finally, enter save to give Greta her additional identity.

You should now see something like this when you type gpg --list-keys greta:

pub  1024D/1BE275BA 2003-06-05 Greta User (Home) <>
uid                            Greta User <>
sub   768g/F23D7526 2003-06-05 [expires: 2003-06-08]
Notice that the new user ID is now the primary user ID, and the previous one is now listed as an additional user ID. Maybe this isn't what Greta wants, so go back into gpg --edit-key greta and
  1. Type 2 to select UID 2.
  2. Type primary to make this user ID the primary one.
  3. Enter your passphrase. You're altering your preferences so you need to sign them with the secret key again.
  4. Type save to exit.
Now when you type gpg --list-keys greta, her home ID is the secondary user ID.

You can add as many user IDs as you like. There's no need to add every email address you own, but one for each role is not uncommon.

Harold is fed up of working for He's decided to try his luck at the (completely unrelated) ISP, eXample.NET. So he needs to inform everyone to send mail to him at rather than While he could delete the old userid from his key, this wouldn't be reflected in anyone else's key, so he has to issue a revocation certificate for it.

As harold, type gpg --edit-key harold

  1. Type adduid
  2. Enter Harold User, harold@eXample.NET and Work for Harold's new ID.
  3. Now select the first userID by typing 1.
  4. Revoke it by typing revuid.
  5. In this case, reason is 4.
  6. I chose to enter Changed job as the description.
  7. And finally save to write the changes.

Now when you type gpg --list-keys harold you don't see the revoked UserID:

pub  1024R/2EF2F6F8 2003-06-05 Harold User (Work) <harold@eXample.NET>
sub  1024R/EAE76CB8 2003-06-05 [expires: 2003-06-08]
But if you type gpg --list-sigs harold you see that it's there, just revoked:
pub  1024R/2EF2F6F8 2003-06-05 Harold User (Work) <harold@eXample.NET>
sig 3       2EF2F6F8 2003-06-05   Harold User (Work) <harold@eXample.NET>
uid                            [revoked] Harold User <>
rev         2EF2F6F8 2003-06-05   Harold User (Work) <harold@eXample.NET>
sig 3       2EF2F6F8 2003-06-05   Harold User (Work) <harold@eXample.NET>
sub  1024R/EAE76CB8 2003-06-05 [expires: 2003-06-08]
sig         2EF2F6F8 2003-06-05   Harold User (Work) <harold@eXample.NET>

If you like you can add some more user IDs to Greta and Harold's keys. You can revoke and delete user IDs. Obviously this isn't a task you have to do often, but it's a good idea to make sure the primary user ID is right before you send your key to anyone.

Exercise 5

Importing and exporting keys

Greta and Harold have now set up their keys to their own tastes, but in order to do anything useful, they have to publish the public half of their key. For most people, the keyserver network is the right place to publish public keys, but we don't want to clog the keyserver network with thousands of Greta and Harold keys that should be thrown away. So please do NOT use the gpg --send-keys command with these sample keys.

There are other ways of communicating keys to people. Probably the best-known is email. In order to minimise the chances of corruption over an email link, OpenPGP has the concept of ASCII armour. To export Harold's key, type gpg -a --export harold >harold.asc

Now, put this file somewhere Greta can access it; in my case, the greta user can read harold's home directory, so I can simply type gpg --import /home/harold/harold.asc

Greta now has access to Harold's public key. Now she can encrypt files she wants to send to him and verify his signature on files he sends to her. In order that Harold be able to encrypt files to her and verify her signature, you should now export Greta's public key and have Harold import it.

Exercise 6

Signing keys

Greta and Harold have each signed their own key. You can see who's signed a key by looking at gpg --list-sigs <key ID>. Subkeys (eg ElGamal or RSA encryption keys) are only normally signed by the primary key. When people talk about signing someone else's key, they actually mean signing someone else's user ID(s).

The reason you want to sign someone else's key is to improve the Web of Trust. By signing their user ID(s) you certify that this key belongs to that name and email address. This is an effective protection against Man In The Middle attacks.

Before you sign someone else's key you need to check that you really have got their key and there's no chance that someone tampered with it before it got to you. The best way of doing this is to check their fingerprint. The fingerprint of a key is a secure hash (either SHA-1 or MD5) of the public parts of the key. If the fingerprints of two keys match, you can be sure that either the keys are the same or the hash has been broken.

Exercise 7

Signing other things

Exercise 8

Encrypting things