GPG: the Best Free Crypto You Aren't Using, Part I of II

An introduction to the underappreciated, 100% free utility you didn't know you needed (but do)--GnuPG.
How Public Key Cryptography Works (Abridged Version)

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.)

The Need for Meaningful Trust

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

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.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

gnupgp

Anonymous's picture

werner koch did not soley write the code...

Link to part II

Anonymous's picture

The article is continued in the second part,
GPG: the Best Free Crypto You Aren't Using, Part II of II

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState