Slashdot Mirror
Moxie Marlinspike: GPG Has Run Its Course
An anonymous reader writes: Security researcher Moxie Marlinspike has an interesting post about the state of GPG-encrypted communications. After using GPG for much of its lifetime, he says he now dreads getting a GPG-encrypted email in his inbox. "Instead of developing opinionated software with a simple interface, GPG was written to be as powerful and flexible as possible. It's up to the user whether the underlying cipher is SERPENT or IDEA or TwoFish. The GnuPG man page is over sixteen thousand words long; for comparison, the novel Fahrenheit 451 is only 40k words. Worse, it turns out that nobody else found all this stuff to be fascinating. Even though GPG has been around for almost 20 years, there are only ~50,000 keys in the "strong set," and less than 4 million keys have ever been published to the SKS keyserver pool ever. By today's standards, that's a shockingly small user base for a month of activity, much less 20 years." Marlinspike concludes, "I think of GPG as a glorious experiment that has run its course. ... GPG isn't the thing that's going to take us to ubiquitous end to end encryption, and if it were, it'd be kind of a shame to finally get there with 1990's cryptography."
I know quite a few people who have started using GPG via the Enigmail plug-in for Thunderbird lately. The length of the man page is irrelevant and they never publish their keys so are effectively invisible to the statistics. That doesn't mean that it isn't an extremely useful, valuable piece of software though.
I use Thunderbird with Enigmail, mostly to sign my emails to get other people used to seeing signed mails, with an attachment with the signature in it. I've got one question about this, a friend asking what that mysterious attachment was and I explained it. I created an IMAP mail account that I only use to make notes that I can easily share among different computers. All these notes are encrypted using my public key. I can open them on the computer which has my private key.
Your comment about being invisible to statistics does not mean being invisible to NSA and GCHQ. As they and several other agencies scan all mail, they will see these attachments, they will see mail headers and other signs that mail being encrypted, whatever method you use. So they will know that your friends use GPG.
Yeah. If only there was an easy to use end2end encrypted mobile phone application for voice calls that Moxie had been involved in creating.
https://en.wikipedia.org/wiki/...
it's in my head
The point is that Moxie actually *does* something (has the OP done anything? We don't know).
I don't agree on everything with Moxie, but fact is that he's not sitting on his hands, by a long stretch.
PGP isn't a standard
It most certainly is:
RFC 1991, 2440, 4880, 5581, 6637, 2015, 3156
http://en.wikipedia.org/wiki/P...
The e-mail client I use has gnupg support by default.
Why use gpg instead of s/mime, which has native support in most e-mail programs, with no need for plugins? S/MIME relies on centralized key servers or opens itself to man-in-the-middle attacks. You can hand-authenticate individual CAs with some effort, but there's no equivalent to PGP's web of trust. And CAs are single points of failure, making them extremely desirable points of attack. Marlinspike, of course, has developed his own proposed solution to the CA problem: http://en.wikipedia.org/wiki/C... It's up to the reader whether this contributes to his credibility on the issue because he knows what he's talking about and has taken the time to contribute code to help fix the problem, or whether he's someone with his own personal dog in the fight and hence has an ulterior motive in denigrating PGP's trust model.
rage, rage against the dying of the light
There are two items when people mention PGP:
The OpenPGP format.
The PGP implementation applications, like archaic PGP versions, NetPGP, APG, OpenKeyChain, GNU Privacy Guard, Symantec Encryption Desktop, and a number of others.
As far as I know, all the above have their source code available under various licenses, even the Symantec stuff either has, or used to have, its source available for examination.
I do agree that a revamp in some of the OpenPGP implementation programs is direly needed, because as of now, the most usable implementation (IMHO) is Symantec's version, which is a commercial product.
It might be nice to see about breaking the OpenPGP implementation programs up into to parts -- two library frameworks (one for BSD, and one for GPL v3), and the code that accesses the libraries.
As for the OpenPGP format itself, it does need some incremental improvements:
1: Additional encryption and the ability to chain encryption algorithms. This isn't meant to win a bitsize war, but so that if one algorithm like SERPENT gets broken, there is still AES and Twofish. TrueCrypt implements this.
2: Splitting how much you trust a key versus how much you trust a key's owner to sign, introduce, and validate other people's keys, with both of these values exportable. This way, if you are 100% sure you have a key of a cretin, you can pass that along.
3: Newer compression protocols like LZMA2, bzip2, and others, so that data is further shrunk before encryption.
4: An error correction protocol applied after encryption and signing, with a user selectable amount of ECC applied. This way, a signed OpenPGP file that suffers some damage can likely be repaired, and the signature still be valid.
5: Share splitting. This way, a user can select x out of y pieces be required to recover an OpenPGP packet.
However, all and all, the OpenPGP protocol has stood the test of time when it comes to security. Its main strength is that it is not tied to a communications or messaging protocol, so an OpenPGP packet can be sent on a file on a SD card, via E-mail, AIM, SMS, MMS, posted on a newsgroup or forum, or virtually any other means. There are people who bash OpenPGP, but oftentimes, they have their own solution, and have a vested interest in getting people to leave OpenPGP for a closed system.
OpenPGP fills a crucial need. Not just securing data over communications, but protecting data stashed away. Few encryption protocols can secure both data at rest, and data in motion.