GPG: the Best Free Crypto You Aren't Using, Part I of II
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.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Tech Tip: Really Simple HTTP Server with Python
- Readers' Choice Awards
- BASH script to log IPs on public web server
40 min 29 sec ago
4 hours 16 min ago
- Reply to comment | Linux Journal
4 hours 48 min ago
- All the articles you talked
7 hours 12 min ago
- All the articles you talked
7 hours 15 min ago
- All the articles you talked
7 hours 16 min ago
11 hours 41 min ago
- Keeping track of IP address
13 hours 32 min ago
- Roll your own dynamic dns
18 hours 45 min ago
- Please correct the URL for Salt Stack's web site
21 hours 57 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?