GPG (GNU Privacy Guard) exercise
Update GPG
If you don't already have GPG install it (e.g., with the yum updater).
The exercise below calls on you to operate variously as users tom, dick, and harry. To
first create them you will need to be root. Thereafter, I ask you to log in to virtual terminals 1, 2, and 3 respectively as tom, dick, and harry. To leave those terminals free, and yet have a graphical interface with which to view these instructions, you should launch the GUI from terminal 4. So press ctrl-alt-F4 to reach terminal 4 (having just booted with no GUI running-- you maybe are in one right now if you are reading this and will need to get out?) thence login as user student. Then:
startx &
to get your graphical desktop. You can now reach terminals 1, 2, 3, and this GUI by key-combinations ctrl-alt-F1, -F2, -F3, and -F7 respectively. Run Firefox and bring up these instructions. Run a terminal window in which:
su -
to become root within that window. Now you can create the three user accounts.
On the chance they already exist, check:
id tom
id dick
id harry
If they aren't there, create them, as root, as follows:
useradd tom
useradd dick
useradd harry
Give them each a password.
passwd tom
Supply password "password" (ignore the complaint that it's a dictionary word, you're root so you can assign it).
passwd dick
Supply password "password".
passwd harry
Supply password "password".
Log the new users tom, dick, and harry in on virtual terminals 1, 2, and 3 respectively. Control which virtual terminal you're in by keystroke, pressing ctrl-alt-F1/F2/F3 to enter virtual terminal 1/2/3 respectively. (If in VMware it may be necessary to include the spacebar in this key sequence, as follows. Hold ctrl-alt, then tap and release the space bar then press the desired Fn key. Another way, once logged in command "chvt n" flips you into virtual terminal n.) In the following exercise, when called upon to operate specifically as a particular user, go to his virtual terminal to do so.
Create keys
Operate as Tom (ctrl-alt-F1). Create a key for tom. Commands below are color coded according to user.
gpg --gen-key
This command option is interactive. Accept the defaults (or the key might not work!) until asked for user-specific information. Then, answer the Real name, Email address, and Comment prompts with Tom Smith, tom@bogus.com, and "first among equals" respectively. Enter "passphrase" when asked for a passphrase. Let the program generate keys for tom. When it's finished, examine the results:
cd
ls -la (note the presence of new directory .gnupg)
ls -l .gnupg
gpg --list-keys
Now operate as Dick (ctrl-alt-F2) and do the same thing.
gpg --gen-key
Answer the Real name, Email address, and Comment prompts with Dick Jones, dick@bogus.com, and "second among equals" respectively. Enter "passphrase" when asked for a passphrase. Let the program generate keys for dick. When it's finished, examine the results:
cd
ls -la
ls -l .gnupg
gpg --list-keys
Now operate as Harry (ctrl-alt-F3) and do the same again.
gpg --gen-key
Answer the Real name, Email address, and Comment prompts with Harry Brown, harry@bogus.com, and "third among equals" respectively. Enter "passphrase" when asked for a passphrase. Let the program generate keys for harry. When it's finished, examine the results:
cd
ls -la
ls -l .gnupg
gpg --list-keys
GPG created a pair of (public-private type) keys for each user and stored it in a key database under his home directory for his particular use.
Exchange keys
For a user to employ GPG in communicating with others, he needs to obtain and store the others' public keys. First the other users must "export" their keys, that is, extract relevant info from the key database and package it for somebody else to import. Then they must deliver the resulting "package." Then the recipient must "import," that is, extract from the received package and enter into his local database. The set of keys stored in a user's key database is called his keyring. Currently Tom, Dick, and Harry, on their keyrings, have their own keys only. Beyond that we want Dick and Harry to have one another's keys; and Tom to have both of the other guys', as follows:
Tom' keyring Dick's keyring Harry's
keyring
Tom's key Dick's
key Dick's key
Dick's key Harry's
key Harry's key
Harry's key
The steps below will achieve that.
As Dick, experiment with exporting. You can export in either a binary or ascii-encoded format. The counterpart "import" option accepts either type. Try both; the output will appear on the screen.
gpg --export dick
(this command garbles some screens; if so, issue the command
"reset" at the prompt)
gpg --export -a dick
Now save the binary version to a file:
gpg --export -o dickkey dick
"Publish" the exported key by copying its containing file to a publicly accessible directory.
cp dickkey /tmp
As Harry, import Dick's key to your key database (keyring):
gpg --import /tmp/dickkey
Check the keys on the keyring:
gpg --list-keys
noting the presence of Dick's, just imported, along with Harry's own. Now export keys for Tom's and Dick's consumption. We want to give Tom both keys, but Dick only Harry's. Let's use ascii formatting this time.
gpg --export -a -o harryskeys
(defaults
to output all keys)
gpg --export -a -o harrykey harry (outputs just the specified key)
cp harryskeys /tmp
cp harrykey /tmp
As Tom and Dick, pick these keys up. First, as Tom:
gpg --import /tmp/harryskeys
gpg --list-keys
Note the --import option detects keys that were either binary- or ascii- exported, with no need for any distinguishing option on the command line. Note also that by default it imports all the keys in the file.
As Dick:
gpg --import /tmp/harrykey
gpg --list-keys
Now that each user has some keys in place let's use them for their intended purposes. GPG's intended purposes are two: encrypting (for confidentiality) and signing (for authentication and data integrity).
Encrypting and decrypting
A user encrypts for consumption by another user, by applying the other user's public key to the plaintext. The result is decryptable by that particular other user only. Let Dick encrypt a file to be read by Harry. As Dick, first use an editor and create a file named fromdicktoharry containing the line, "This is a message for Harry to read, from Dick."
gpg --recipient harry --encrypt
fromdicktoharry
ls -l from*
file from*
Note the presence of the newly created file fromdicktoharry.gpg. It contains the data encrypted with Harry's public key. Publish it, to give Harry and Tom access. When they try to decrypt and read it, Harry will succeed and Tom will fail.
cp fromdicktoharry.gpg /tmp
Now issue the following command twice, first as Harry then as Tom:
gpg --decrypt /tmp/fromdicktoharry.gpg
gpg --decrypt /tmp/fromdicktoharry.gpg
Harry is able to produce "This is a message for Harry to read, from Dick." because he has the private key (Harry's) for which is was encrypted. Tom is unable, because he does not.
Signing
Signing, like encrypting, can produce binary or legible ascii output. As Dick:
gpg --clearsign fromdicktoharry
ls -l from*
file from*
Note the appearance of fromdicktoharry.asc. Note also it's contents:
cat fromdicktoharry.asc
cp fromdicktoharry.asc /tmp
fromdicktoharry.asc holds the original content of fromdicktoharry, with an appendage. The appendage is the result of boiling the original content down to a corresponding digest, then encrypting it with Dick's private key. With Dick's public key anybody can recover Dick's digest; plus they can generate their own digest (using a standard command) from the received message itself. If their digest matches the one sent, Dick must be the sender. And so he must be the sender of the message too. Because whoever is the sender of the message is also the sender of the encrypted digest (they came together). So, either Harry or Tom should be able to verify that the guy who manufactured /tmp/fromdicktoharry.asc is Dick. Have them do so. Issue the following command twice, first as Harry then as Tom:
gpg --verify /tmp/fromdicktoharry.asc
gpg --verify /tmp/fromdicktoharry.asc
Note there is no encryption in this scenario. So the file is as legible to Tom as to Harry. Note also that because it's in ascii, due to --clearsign, it is eminently distributable by ascii transport mechanisms. (For example it could be embedded in an email message. The validity of the message origin could then be established without reference to the mail header's unreliable "from" field.) Manually, you might cut and paste it into a file and apply gpg --verify. Alternatively, mail clients sometimes support doing the verification automatically, or have installable add-ins to perform it. For example, Enigmail is such an add-in for the Thunderbird mail client. But its cryptography engine is gpg, which it installs and to which it is a front-end.
Let Tom sign something, for Dick to verify as coming from Tom. As Tom:
cd
echo Hello Dick > fromtomtodick
gpg --sign fromtomtodick
cp fromtomtodick.gpg /tmp
As Dick:
gpg --verify /tmp/fromtomtodick.gpg
Tom verified that the earlier file came from Dick; so what's the difference? Why isn't it working in reverse? Why can't Dick verify that this one came from Tom?
Encrypting and signing, together
You can do both. As Dick:
gpg --sign --recipient harry --encrypt fromdicktoharry
cp fromdicktoharry.gpg /tmp
Then as Harry:
gpg --decrypt /tmp/fromdicktoharry.gpg
Both the readable message should appear, plus a screen message assuring Harry that it is indeed from Dick ("Good signature...").
"Publishing" keys
This system relies on easy mechanisms for users to put public keys at one another's disposal. It's done in this exercise merely by placement, in a publicly accessible directory. In a network it can be done by file exchange or generating keys in ascii then using email or any method at all that gets data from one person to another. There are key servers dedicated to the purpose, where you can deposit your public key for anyone to get. Here are a couple of them:
As with many linux command-driven subsystems, graphical front ends to GPG can be found. There is one called gpa. If you use one of them you will unmistakably recognize the correspondence between features in their interface and the underlying gpg software you've just learned.
Clean up
Log everybody out of their terminals:
exit
exit
exit
And as root remove the users and also their home directories (taking keys and all with them).
userdel -r tom
userdel -r dick
userdel -r harry