Slashdot Mirror
PGP & GPG
Ben Rothke writes "PGP (Pretty Good Privacy), as most Slashdot readers know, is one of the most popular software encryption programs ever. It is so good and so effective that in the early 1990s the FBI launched a multi-year investigation against Phil Zimmerman, the creator of PGP, for possible violation of federal export laws, especially ITAR (International Traffic in Arms Regulation). After many years of investigation, the FBI ultimately dropped its case against Zimmerman. Even though PGP is synonymous with end-user encryption, there have only been a few books written on the subject. Jump to 2006, and PGP & GPG: Email for the Practical Paranoid is a welcome title." Read the rest of Ben's review.
PGP & GPG: Email for the Practical Paranoid
author
Michael Lucas
pages
216
publisher
No Starch Press
rating
8
reviewer
Ben Rothke
ISBN
1593270712
summary
Pretty good overview of PGP & GPG
On page 167 in Appendix A of the book, the author candidly writes that PGP "comes with a very good and complete manual at over 300 pages". With that, one may question why one would spend $24.95 on a book which covers much of the same information as the bundled documentation.
The reality is that there is a large class of people that will simply not read any form of documentation. Rather, they prefer something with an ISBN number. Such people are a boon to authors (of which I am one) and publishers. For that group, PGP & GPG: Email for the Practical Paranoid provides a pretty good overview of how to use PGP.
The book is written for an end-user who, while comfortable with the workings of technology, is new to the sometimes strange world of public key cryptography. The author writes in an easy-to-read style and, through repetition, inculcates the principal ideas of encryption and cryptography to the reader.
The introduction and first chapter provide a good presentation of the concepts of encryption, cryptography and public-key cryptography. The idea of public-key cryptography, on which PGP is based, is not so intuitive, and many people struggle with the basic concepts. The first chapter, appropriately titled 'Cryptography Kindergarten' is a good read for those who are public-key cryptography challenged.
On a side note, the notion that even smart end-users can be intimidated by public key cryptography was detailed in a now seminal research paper 'Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0.'
The premise of the paper is that user errors cause or contribute to most computer security failures, yet user interfaces for security still tend to be clumsy, confusing, or near-nonexistent. The authors argue that effective security requires a different usability standard, and that it will not be achieved through the user interface design techniques appropriate to other types of consumer software. The authors conclude that PGP 5.0 is not usable enough to provide effective security for most computer users despite its attractive graphical user interface. Even though PGP is in version 9.x, it still suffers from usability flaws.
Cryptography purists may recoil when the author repeatedly uses the term 'military-grade encryption.' Military-grade encryption and military-grade cryptography are overused terms, most often by marketing departments, but there is no real definition of 'military-grade encryption' -- and even if there were, it would be classified. Most people use 'military-grade encryption' to mean really strong crypto, much like those who use the term 'Olympic-size swimming pool' to refer to a really large pool. But the term 'military-grade encryption' is so misused by so many people that it is a lost cause to try to fight it.
In the rest of the book, chapters 2 - 11, the author details the varied usages of PGP & GPG. The book also details the differences between OpenPGP, PGP and GPG.
The difference between them is that PGP is a commercial piece of software, GPG (Gnu Privacy Guard) is open source, and OpenPGP is a protocol that defines a standard format for encrypted messages, signatures, and certificates for exchanging public keys.
The author astutely writes that while PGP provides really strong security, this is only if, and this is a huge if, it is implemented correctly. Chapter 11 notes that although OpenPGP provides a reliable method of authentication and encryption, it is also not unbreakable. OpenPGP can be vulnerable to many different types of attacks and weaknesses, including poor implementation, hardware or software compromise, fake keys and more. It is important to realize that OpenPGP provides significant, but not unbreakable security.
At 180 pages and priced at $24.95, PGP & GPG: Email for the Practical Paranoid is an excellent book that shows the end-user in an easy to read and often entertaining style just about everything they need to know to effectively and properly use PGP and OpenPGP.
For those that want to save money and perhaps save a few trees, the free documentation that comes along with the product is similarly worth reading.
You can purchase PGP & GPG: Email for the Practical Paranoid from bn.com.
Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
On page 167 in Appendix A of the book, the author candidly writes that PGP "comes with a very good and complete manual at over 300 pages". With that, one may question why one would spend $24.95 on a book which covers much of the same information as the bundled documentation.
The reality is that there is a large class of people that will simply not read any form of documentation. Rather, they prefer something with an ISBN number. Such people are a boon to authors (of which I am one) and publishers. For that group, PGP & GPG: Email for the Practical Paranoid provides a pretty good overview of how to use PGP.
The book is written for an end-user who, while comfortable with the workings of technology, is new to the sometimes strange world of public key cryptography. The author writes in an easy-to-read style and, through repetition, inculcates the principal ideas of encryption and cryptography to the reader.
The introduction and first chapter provide a good presentation of the concepts of encryption, cryptography and public-key cryptography. The idea of public-key cryptography, on which PGP is based, is not so intuitive, and many people struggle with the basic concepts. The first chapter, appropriately titled 'Cryptography Kindergarten' is a good read for those who are public-key cryptography challenged.
On a side note, the notion that even smart end-users can be intimidated by public key cryptography was detailed in a now seminal research paper 'Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0.'
The premise of the paper is that user errors cause or contribute to most computer security failures, yet user interfaces for security still tend to be clumsy, confusing, or near-nonexistent. The authors argue that effective security requires a different usability standard, and that it will not be achieved through the user interface design techniques appropriate to other types of consumer software. The authors conclude that PGP 5.0 is not usable enough to provide effective security for most computer users despite its attractive graphical user interface. Even though PGP is in version 9.x, it still suffers from usability flaws.
Cryptography purists may recoil when the author repeatedly uses the term 'military-grade encryption.' Military-grade encryption and military-grade cryptography are overused terms, most often by marketing departments, but there is no real definition of 'military-grade encryption' -- and even if there were, it would be classified. Most people use 'military-grade encryption' to mean really strong crypto, much like those who use the term 'Olympic-size swimming pool' to refer to a really large pool. But the term 'military-grade encryption' is so misused by so many people that it is a lost cause to try to fight it.
In the rest of the book, chapters 2 - 11, the author details the varied usages of PGP & GPG. The book also details the differences between OpenPGP, PGP and GPG.
The difference between them is that PGP is a commercial piece of software, GPG (Gnu Privacy Guard) is open source, and OpenPGP is a protocol that defines a standard format for encrypted messages, signatures, and certificates for exchanging public keys.
The author astutely writes that while PGP provides really strong security, this is only if, and this is a huge if, it is implemented correctly. Chapter 11 notes that although OpenPGP provides a reliable method of authentication and encryption, it is also not unbreakable. OpenPGP can be vulnerable to many different types of attacks and weaknesses, including poor implementation, hardware or software compromise, fake keys and more. It is important to realize that OpenPGP provides significant, but not unbreakable security.
At 180 pages and priced at $24.95, PGP & GPG: Email for the Practical Paranoid is an excellent book that shows the end-user in an easy to read and often entertaining style just about everything they need to know to effectively and properly use PGP and OpenPGP.
For those that want to save money and perhaps save a few trees, the free documentation that comes along with the product is similarly worth reading.
You can purchase PGP & GPG: Email for the Practical Paranoid from bn.com.
Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Until Microsoft starts bundling their Certificate Services in Vista Home editions as a My-Identity-broker kind of thing, X.509 is useless for most people. X.509 is in Outlook because Outlook is the frontend for Exchange.
GPG/PGP are asymmetric cryptosystems that don't rely on PKI infrastructure, just per-user public/private keypairs. Not enterprise friendly but they can be used to bootstrap a trusted online relationship.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
There's a Public Key field in the User Preferences page on Slashdot, but does anyone know where you go to pick up other users' keys?
"Cryptography purists may recoil when the author repeatedly uses the term 'military-grade encryption.' ... there is no real definition of 'military-grade encryption' -- and even if there were, it would be classified."
Ahem, reference http://www.nsa.gov/ia/industry/crypto_suite_b.cfm
While Suite A is classified, Suite B, specifically AES, is specifically mentioned as being suitable for up to TOP SECRET info.
Military grade is not a useless term, as it is therein defined.
HOO-AH!
First of all, you can get free personal S/MIME email certificates from Thawte, which is a trusted CA. Second of all, you don't have to use a commercial trusted CA. You can also be your own CA and issue yourself all the certificates you want. The only catch is that outside the domain of your CA, your CA will not be a trusted CA, so you either have to establish trust in advance with other users, or live with having an untrusted certificate.
If you don't know where you are going, you will wind up somewhere else.
I read up a tiny bit on X.509.
That is obvious.
According to Wikipedia, X.509 uses signed certificates from CAs, meaning you have to PAY,
No, you can set up your own CA (for free) with openssl. And in fact, you don't need a CA at all. You can use your own certificates that aren't signed by anyone, just like PGP/GPG. In fact, the underlying math (public-key cryptography) is exactly the same as PGP/GPG.
and store your certificate with a "trusted company".
Store your certificate? Bullshit. You send the CA a certificate signing request. They sign it, and send it back to you. The certificate is useless without your private key, and the private key doesn't leave your possession. Decryption can only be done with the private key. So don't lose it.
Not only is this horrible for paranoids who wouldn't trust Verisign,
You don't need to trust Versign for X.509 to work. The only time you need to trust Versign (or any other CA) is to identify the cert of someone you never met. How do you know that a cert really belongs to the person? Verisign (or some other CA) signed the certificate. How do you know if a PGP key really belongs to someone you never met? Someone signed it.
But do you trust the signer? That question occurs with certificates and PGP keys.
but the US Gov. could subpoena your information from these companies, rendering your encryption useless (against the government).
Even if the US Gov't seizes all of verisign's info, that won't help them break your cryptography, since the private key (see above) never left your possession and Verisign never had it.
It's one thing to be paranoid, it's another thing to be an idiot. Understand how cryptography works before you start to rant & rave.
Frankly, if the US Gov't really, really wants to break your encryption, they'll bug your computer, or your house, or call in the NSA, or send in the Marines.
John: Cool. Here's mine.
Et voila - we can now start sending private messages back and forth (neglecting man-in-the-middle issues with the key exchange that can be trivially avoided with a single phone call or in-person meeting). Notice the missing step: neither of us paid Verisign or another CA for the privilege of saying "Hey, wanna go to lunch?" in private.
Dewey, what part of this looks like authorities should be involved?
Check out eCryptfs, which has recently been accepted upstream into the
-mm Linux kernel:
http://ecryptfs.sf.net/
This encrypts on a per-file basis, so that you can grab and copy the
file from the lower filesystem (which can be pretty much anything --
ext3, jfs, reiserfs, nfs...) without even having to mess with all that
partitioning stuff.
It's a great cryptographic filesystem now with just passphrase
support. It looks like they're going to be done with the public key
subsystem (with pluggable PKI support) before too long. HMAC
(integrity verification) will come next, and then when they get into
the policy stuff, eCryptfs will go beyond any crypto filesystem that
anyone has ever written, Open Source or not.
Coincidentally, the header format is inspired by the OpenPGP
specification (RFC 2440).
Apples, oranges, pears, and bananas here people. Truecrypt is a fantastic program, but how in the world would it be easier to:
encrypt your data in a small volume and attach it as a file to who you want to send it to...
How would they know the passphrase to open your attachment? That's the whole point of the public/private key system.
Well, it doesn't do absolutely everything on your list but it's a pretty good start: http://www.gpg4win.org/.
It does the first two, and the third - it does cache passphrases for short periods of time. I don't know off the top of my head how to change the cache duration, but there should be a config option somewhere.
Sending encrypted or signed email is just a matter of two toggles in a toolbar on every email - you should be able to change a setting somewhere so they always default to on (right now they default to off unless I'm replying to a PGP-encrypted/signed email).
It is GPL.
As for this:
* Attach the pubkey to all outgoing mails where the address isn't in my keyring.
Seems like it would be a pretty easy addition to the existing GPG4Win codebase.
* Automatically (just ask for password confirmation or something) addition of incoming pubkeys to my keyring.
Not sure about this since I don't think I ever get such emails, but I believe you can just double click on a pubkey attachment in the correct format and it will open it in WinPT, the key management software packaged with GPG4Win.
* The people who got the pubkey would also get a link to where to download the plugin.
This is trivial if you are already attaching the pubkey, just stick a link in your sig.
The one thing GPG4Win needs is some English documentation - it's got decent documentation, but in German only. A bit more professional looking web design would be nice too. And some parts of the software feel a touch rough around the edges, but overall it "just works" most of the time.
That's why fingerprints and web of trust were invented.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD