An introduction to the underappreciated, 100% free utility you didn't know you needed (but do)--GnuPG.
Ten years after Phil Zimmermann released PGP v.1.0 (Pretty Good Privacy), PGP has evolved from an underground tool for paranoiacs to the gold standard, even an internet standard, for e-mail encryption. GnuPG, the GNU Privacy Guard, is a 100% free alternative to commercial PGP and is included in most Linux distributions. And yet, not nearly as many people who need it (and already have it) use it.
Are you among the many GnuPG procrastinators of the world? Hopefully you won't be after this and next months' columns. After you've generated your personal keys, sent your first encrypted e-mail and finally verified the security signature of that cool software package you downloaded, you'll be glad you took the trouble to master the multifunctional marvel that is GnuPG.
This month we'll begin with PGP/GnuPG background, concepts and quick-start. Next month we'll dig deeper into file and e-mail encryption, key management and graphical user interfaces.
Back in 1991, when the US Congress appeared to be on the brink of outlawing all private use of cryptographic software, Phil Zimmermann released PGP v.1.0. This originally free tool allowed ordinary users of consumer-grade computer systems to encrypt their personal data and communications effectively enough to thwart even determined and well-financed eavesdroppers (such as, for example, the US government).
Phil Zimmermann's story is important and compelling and can be read in Simson Garfinkel's book and on Phil's own home page (see Resources). But for now suffice it to say that despite government investigation, patent complications and the tribulations of corporate assimilation, PGP has continued to improve and grow in serving Zimmermann's vision of protecting people's and organizations' privacy worldwide.
When I say that, however, I really mean PGP in the broadest sense, including OpenPGP and GnuPGP. The emergence of the latter have, respectively, resulted in PGP's key and message formats becoming an internet standard in RFC 2440, and in providing users worldwide with a completely free and unencumbered (by patents) implementation of PGP.
Although Mr. Zimmermann is, by any reasonable standard, one of the true pioneers of and contributors to open-source software, Network Associates Inc.'s (NAI) product PGP is problematic for Linux users in specific and open-source adherents in general. First and most obviously, commercial PGP runs only on Windows and Mac OS.
Second, even PGP Freeware is free only to noncommercial users, that is, users in educational and nonprofit settings. Third, NAI has decided to reduce greatly the amount of PGP source code it makes available for peer review and public scrutiny, even for Freeware PGP.
This last development apparently contributed to Phil Zimmermann's resignation from PGP Security and has cast doubt on the advisability of fully trusting NAI's version of PGP. Considering the US government's hostility toward PGP and various governmental efforts to require “back doors” in cryptographic software (including key-escrow), it's all too easy to imagine NAI quietly bowing to governmental pressure and creating such a back door. Without public scrutiny of PGP's full source code, we have no means of validating assertions by NAI that this is not and will never be the case.
GnuPG, on the other hand, is a 100% open-source and 100% free package that does most of what PGP does (it lacks certain features such as virtual private networking and disk-volume encryption that are included in PGP Desktop). In a short time, GnuPG has become the preferred e-mail and data encryption tool for Linux users and is packaged with most current Linux distributions. The GnuPG Project is headed, and its code primarily developed, by Werner Koch.
GNU Privacy Guard consists of a single-binary executable, gpg. Actually there's an additional binary, gpgv, but since gpgv merely provides a convenient subset of gpg's functionality you can still think of gpg as essentially self-contained. Therefore, it's perfectly okay to use the terms GnuPG and gpg interchangeably—I'm going to do so for the remainder of this article. I'm also going to be loose with the term PGP—rather than the specific commercial product by Network Associates, I'll henceforth use PGP to refer to the protocols, mechanisms and Web of Trust common to PGP, OpenPGP and GnuPG.
GnuPG performs four basic functions to which all of its other functions are supplemental: encrypting data, decrypting data, cryptographically signing data and cryptographically verifying digital signatures. It is also used to create and manage keys, activities that, although subordinate to the four listed above, are absolutely essential in performing those functions securely.
In real terms, this means that people generally use GnuPG to encrypt files, especially e-mail; decrypt mail or files that have been sent to them; digitally sign documents, source code distributions and other electronic files; validate others' digital signatures to determine whether a given file matches its accompanying signature (i.e., wasn't tampered with at any point) and whether the file was verifiably signed by the person who claims to have signed it; and maintain keyrings (key databases) containing their personal key or keys (their secret keyring) and the public keys of their friends, colleagues, business partners, etc., (their public keyring).
Obviously, then, you need GnuPG if you wish to exchange encrypted messages and files with other GnuPG users (and users of other OpenPGP-compliant software). It's also one of your options if you wish to encrypt data that is stored locally but in a not-altogether trusted place, e.g., the hard drive of a laptop computer you travel with and are resigned to the possibility of being stolen.
But even if none of your friends use GnuPG or PGP, and even if you feel that none of your data is worth protecting with encryption, there's still one very compelling reason to learn at least a little about using GnuPG: software-distribution signing. Thanks to several high-profile break-ins at public FTP sites on the Internet in which software packages were replaced with compromised (Trojaned) versions, it has become common practice for developers of security software to distribute digital signatures of their software distributions.
We already covered the basics of public key cryptography (PK crypto) in “The 101 Uses of OpenSSH, Part II of II” (February 2001 LJ). But this is such an important and fundamental topic that it's worth discussing as it applies to GnuPG.
Remember that the premise is simple: in PK crypto, everyone has a pair of keys, one public key and one private key. A public key is used to encrypt data intended for the public key's owner and to verify digital signatures created with the bearer's private key. A private key is used to decrypt data encrypted with the corresponding public key and to create digital signatures.
Public keys, unsurprisingly, are meant to be distributed hither and yon; anybody should be able to send you encrypted data, and anybody should be able to be verify whether a digital signature was created by you. Conversely, a private key must be truly secret and closely protected from unauthorized copying or use; only you should be able to decrypt data intended for your eyes only, and only you should be able to create a digital signature purporting to be from you.
Public keys may be distributed any number of ways. It's their integrity, not their secrecy that matters. But you must protect your private key by storing it in a safe place, such as a directory that only you have read-privileges on, and also by locking it with a long and strong passphrase that must by entered prior to using the private key (I'll tell you how to do this shortly).
All PK crypto systems have that much in common. It's in the distribution and authenticating of public keys that SSH and PGP/GnuPG (and other PK applications) differ. This is important stuff; no matter how effectively you protect your private key, you've still got problems if nobody can distinguish between your real public key and fraudulent public keys distributed by your enemies. (See the Sidebar, “The Need for Meaningful Trust”, for examples of the kind of problems I mean.)
In SSH the problem really isn't addressed. If your friend Bob wants to be able to log in to your server using his DSA key pair and sends you his public key via e-mail, it's up to the two of you as to how to verify that the key you receive in your inbox is the same as the one he sent. (Most likely, you'll simply call Bob on the phone and read part of the key back to him.)
In GnuPG and PGP, there are mechanisms for validating keys, but it's up to you to use them. These mechanisms comprise the Web of Trust.
The Web of Trust isn't hard to understand. If Bob knows Ted and vouches for him, anyone who knows Bob can trust Ted. Accordingly, if Bob signs Ted's public key with his own (Bob's) private key, then Ted can distribute this signature along with his (Ted's) public key so that anyone with Bob's public key can, by verifying this signature, see that Bob vouches for the validity of Ted's public key.
The more people who vouch for Ted and sign his public key, the more likely that someone who receives Ted's public key for the first time can check it against a public key they know to be good.
This even extends to the keys of Ted's signing pals. If Ted sends me his public key, but I know neither Ted nor Bob, then Bob's signature doesn't impress me one bit. But if Bob's key is signed by my good pal Alice (whose public key I possess and trust), then I can trust Bob's key and therefore Ted's. Hence the “Web”.
By the way, this is a radically different model than that behind public key infrastructures (PKIs) such as Entrust and VeriSign in which a single trusted entity vouches for all public keys. The Web of Trust, while certainly imperfect, has no single point of failure; trust is distributed. (See the Sidebar for an example of VeriSign's trust model failing.)
The Web of Trust's main weakness is that unless large numbers of users take the trouble to sign each others' keys and to check the validity of other keys' signatures, there's no web. Sadly, the phenomenon of solo (unsigned) keys is all too common. But your keys won't go unsigned, will they? (Of course not! Just by reading this article you're already on the road to helping strengthen the PGP/GnuPG Web of Trust.)
By the way, since I mentioned PKI I should point out that while there are PGP keyservers that are used as public key repositories, these are strictly a convenience. Unlike in PKI, in which by definition any key obtained from a certificate authority (keyserver) can be trusted, in the Web of Trust this is not the case at all. Think of a PKI certificate authority as the county courthouse and PGP keyservers as a club newsletter; you can find out somebody's birthday from either one, but they serve two very different purposes and thus differ greatly in their trustworthiness.
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.
Listing 1. Sample Signature-Verification Session
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!