Lurking with PGP
If the possibility of a forged posting on the comp.os.linux.announce newsgroup doesn't worry you enough to make you want to install PGP, consider another situation. Suppose you see a newsgroup posting or e-mail message that looks like it is from Ted Ts'o (one of the main Linux developers), and which claims that:
A security hole has been found in Linux,
It is being exploited by crackers who are destroying the systems they crack into,
An attached kernel patch will solve the problem, and
You should install the patch on your system(s) as soon as possible.
Further suppose that the patch is beyond your comprehension. Do you install the patch? Let's assume that Ted is trustworthy (a pretty good assumption). How do you know that it is really Ted who made the posting or sent the message? Perhaps the patch really creates a security hole through which a cracker could attack, and a cracker is forging the message and pretending to be Ted in order to convince you to apply the patch.
You can know because Ted PGP-signed his patch, and because you have a copy of his public key. No one could sign it correctly without a copy of his private key, and Ted is a security expert who keeps his private key very safe.
In order to check a PGP-signed message, you need to have the public key. Where do you get the key? You want to get the real user's real key, not a fake one produced by a forger who is using the fake key to impersonate the sender.
Fundamentally, you need to get the key from a different source than the message. News and mail are notoriously insecure; anyone can fake an e-mail or news message, and anyone who wants to read this article to learn about PGP will probably not notice that the message is fake, and probably won't know how to tell the difference.
If someone is forging messages that are supposed to look like they come from someone else, and they are including PGP, they will also be attempting to propagate a fake key for the user as whom they are masquerading. This means that in an ideal world, you will collect public keys before you need to use them to verify a message. However, there's a good chance that you don't have the key yet when you want to read the message. Where do you look to find a key, and how do you know that it is correct?
Sometimes you can get a key from someone's home page on the Web. If you do that, you have to weigh the possibility that someone has broken security on that system and corrupted the key there. If you get the key well before you want to verify a suspicious message, chances are pretty good that the key you get will be good. The same goes for keys retrieved via finger. If you think you will ever want to verify a comp.os.linux.announce posting, get the key now. If you are paranoid, keep checking for the next few days to make sure there is no announcement that the key was forged or compromised.
One place to find lots of PGP keys is on BAL's PGP Public Key Server, at www-swiss.ai.mit.edu/~bal/pks-toplev.html. This web site has a large database of public keys, and the person you are looking for may have submitted the public key to the database. There's no security; anyone could post an update to anyone else's public key, even forgeries. You still have to verify the keys you get from BAL's server; it's only a convenient point of exchange.
None of these techniques ensure that the key you get is good. All security is a matter of degree, and this technique provides, for most purposes, a reasonable level of assurance that you have the right key. Don't bet the family fortune on it.
Essentially, PGP allows you to extend trust you already have. If you trust your brother to tell you the truth in person, and he has verified that your copy of his PGP public key is correct, then you can be rather sure that a message that is correctly signed with his private key really comes from him. You can be only as sure of that, however, as of his ability to keep his private key secret.
If your brother is sure that his copy of Joe's public key is correct, and you trust your brother to give you a good copy of Joe's public key, then you can be fairly sure that a message that is signed with Joe's public key really comes from Joe. This is a very useful notion, and PGP supports it.
To verify that he is positive that Joe's public key really belongs to Joe, your brother can sign the key with his own private key. If you are certain that your copy of your brother's public key is correct, and your brother has signed Joe's public key, then if you trust your brother's judgement in verifying keys you can be mostly sure that your copy of Joe's public key is correct. Now that you know Joe's key, if you trust his judgement, you can be reasonably confident of the veracity of public keys which he has signed.
PGP users have organized PGP-key-signing gatherings (parties, BOF (Birds of a Feather) sessions at conferences, whatever) in order to meet face to face and sign each other's keys. As people go to different gatherings in different places, it becomes easier and easier to say, “I trust my brother, and my brother has signed Joe's key, and Joe has signed Jean's key, so I can be pretty sure that this message signed with Jean's key is really from Jean.” This concept has become known as the “web of trust”.
Don't go off the deep end when it comes to the web of trust. PGP doesn't make people trustworthy. As Zimmermann says in the PGP manual, “Trust is not necessarily transferable; I have a friend who I trust not to lie. He's a gullible person who trusts the President not to lie. That doesn't mean I trust the President not to lie. This is just common sense.” If you don't trust someone about other things, there's no reason to trust their signatures of other people's keys. They may be duped or careless or lying themselves.
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- DevOps: Better Than the Sum of Its Parts
- "No Reboot" Kernel Patching - And Why You Should Care
- Android Candy: Intercoms
- Return of the Mac
- Designing Foils with XFLR5
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- April 2015 Issue of Linux Journal: High-Performance Computing
- Consent That Goes Both Ways
- diff -u: What's New in Kernel Development