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.
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.
In order to do anything, you'll need keys. So we'll start by creating them.
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 <email@example.com> 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 firstname.lastname@example.org 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 <email@example.com> 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.
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
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.
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 <firstname.lastname@example.org>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.
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.
You should receive something like:
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: A revocation certificate should follow iJ8EIAECAAkFAj7HqaYCHQAACgkQLWxdO2N6VjJmvgP+N3m92ZHeAkRca6azGync P5ihzrL+o1JncbHwBGabJdl/S4zc+HhrzGMKnoYTdPo+BQFD5u8TxCrPXAyAiq9N VsJCM6AsJC/jL7f7Rd7rIUORdBdNgL6MDKgjH5WcflKOXFCxSZwkBmhfgxks1T8D ru43YgqWhaYjssaLeHTaB0s= =n7Ox -----END PGP PUBLIC KEY BLOCK-----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.
The identity on these keys shows them to belong to employees of example.com. 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.
You should now see something like this when you type gpg --list-keys greta:
pub 1024D/1BE275BA 2003-06-05 Greta User (Home) <email@example.com> uid Greta User <firstname.lastname@example.org> 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
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 Example.com. 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 example.net rather than example.com. 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
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 <email@example.com> 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.
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.
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.