GPG: the Best Free Crypto You Aren't Using, Part I of II
GnuPG is, as I mentioned at the beginning, now a standard package in most Linux distributions. As is true of all security software, it's particularly important that you keep current, so even if your distribution includes gpg you'll want to check http://www.gnupg.org/ from time to time so you know when new versions are released.
Naturally, this web site is where you can also obtain the latest source code release of GnuPG. Should you need or wish to build GnuPG from source, simply download the tarball to the directory of your choice (/usr/src is good), and execute the commands below:
cd /usr/src tar -xzvf gnupg-1.0.6.tar.gz cd gnupg-1.0.6 ./configure make make check make install
Note that your tarball's name may be different; as of this writing GnuPG v1.0.6 was current, but by the time you read this it may not be. The same applies to the directory extracted from the tarball.
Note also that the make check command is optional and somewhat time consuming, but I think it's useful: it prints out some interesting information about supported encryption algorithms and runs a battery of tests that let you know immediately whether gpg built properly. If any of these tests fail, there's no point in running make install until you've fixed the problem. In the unlikely event of a failed test, refer to the files INSTALL and README for clues as to why.
You may be aware that in general, running programs with their SUID (set user ID) bit set is to be avoided. The SUID bit, which can be set for each file using the chmod command, causes an executable program to run with its owner's privileges regardless of who runs it.
For example, if a program has an s instead of an x in the user portion of its file permissions (as displayed by s -l), and if that program is owned by root, then any time that program is executed it will have the same rights on the system as root; it will be able to do all the things root can do.
Sometimes programs are installed with this bit needlessly set and with ownership assigned to root. This, however, is not one of those cases. You really should run gpg SETUID (SETUID=root, since root owns gpg) in order to mitigate the risk of a hostile user reading memory containing a gpg private key or its passphrase.
After make install finishes, I recommend that you set this bit with the following command:
chmod u+s /usr/bin/gpg
After you've installed gpg (whether from source as described above or from your Linux installation media), you're ready to create a personal key pair and start building your own little corner of the Web of Trust. But I've already reached the end of this month's column, so instead let's do something that doesn't require us to have a key pair of our own: verifying a signature created by someone else.
As I mentioned earlier, digitally signing a software package has become a popular means of providing end users with a means of verifying that the software they download is the same software its developer put on-line.
The command to verify a detached signature (a PGP signature can either be attached to the file it was created for, or it may be stored separately in its own file) is gpgv. If we invoke this command on a signature but don't have a copy of the signer's public key, gpgv will return an error. In Listing 1 we see a session in which this occurs.
Let's dissect Listing 1. There were three commands invoked:
gpgv gpa-0.4.1.tar.gz.sig gpg --keyserver pgp.mit.edu --recv-keys 621CC013 gpgv --keyring pubring.gpg gpa-0.4.1.tar.gz.sig
The first time I ran gpgv (which you may recall is a stripped-down version of the gpg command used for verifying signatures) I simply supplied the name of the detached signature I wished to verify. Had I had the appropriate public key on gpgv's keyring, $HOME/.gnupg/trustedkeys.gpg, this command would have succeeded, but I didn't, and it didn't.
In the second command, therefore, I ran the regular gpg command with the --recv-keys directive followed by the ID of the key I had been told by gpgv had been used to create the signature. I also specified that gpg should look for this key on the keyserver pgp.mit.edu. The key was there, so this command succeeded.
In the third command, I realized I'd just downloaded the key to my default keyring, $HOME/.gnupg/pubring.gpg, so I used the gpgv's --keyring parameter when I reran it. And this time it worked!
There's only one thing I left out in the example, of course, and that was verifying that the key I took the trouble to download was actually from its alleged owner, Werner Koch. And I did do this—it took all of 20 seconds to do a search on www.google.com for “621CC013 werner koch” that turned up a number of mailing-list postings and web sites on which Werner had included this key ID in his e-mail signature.
Were someone to succeed in hacking the web server from which I downloaded, replacing the file with a Trojan horse or virus and a signature created with a bogus key, and then posting the bogus key on pgp.mit.edu, their skulduggery would be easily detectable by a quick web search like the one I did. I doubt very much that even the most intrepid evildoer would succeed in removing or altering all web sites, Usenet archives, etc., linking his or her victim's name to keys other than the bogus one. So you see, the Web of Trust can work, provided one bothers to do a little follow-up now and then.
I'm already out of space for this month, but there are plenty more useful things to do with GnuPG that we'll discuss in-depth next time. I hope you won't wait until then to try them out!
Mick Bauer (email@example.com) is a network security consultant in the Twin Cities area. He's been a Linux devotee since 1995 and an OpenBSD zealot since 1997, and he enjoys getting these cutting-edge OSes to run on obsolete junk.