Fwd: It's time for PGP to die.

[Nicholas Cole]

On Sun, Aug 17, 2014 at 12:08 AM, Robert J. Hansen <rjh at sixdemonbag.org> wrote:
> On 8/16/2014 1:14 PM, Kristy Chambers wrote:
>> Sorry for that crap subject. I just want to leave this.
>
> Meh.  Color me unimpressed.

This was a terrific post.  Thank you, Robert.

[snip]

> * "No forward secrecy."  Not everyone needs PFS, and frankly, obsession
> with PFS is one of those things I really wish people would grow out of.
>  Before complaining about what OpenPGP needs or where it's lacking, try
> looking at where OpenPGP has been broken in the real world.  Hint: PFS
> ain't a panacea.

I agree people are obsessed with this, and it is unhealthy. I think
the name doesn't help.  I've seen various definitions.

http://en.wikipedia.org/wiki/Forward_secrecy

"This means that the compromise of one message cannot lead to the
compromise of others".  In the case of PGP, of course, it is true that
the compromise of the Public key would compromise all messages, but in
other ways PGP does help. It is possible, for example, to surrender
just the session key, in the case that it is necessary to do so to
comply with a legitimate law-enforcement request.  But I don't see how
PFS could really apply to something like email, as opposed to
something like an http request.

> * "So what should we be doing?"

There are 25 years invested in making PGP work. Many subtle bugs and
security errors in the protocol and the gnupg implementation have been
worked out.   Throwing out PGP would be a bit like making this
mistake:

http://www.joelonsoftware.com/articles/fog0000000069.html

> OpenPGP's biggest problem, BTW, which goes *completely unmentioned* in
> this blogpost: OpenPGP can't protect your metadata, and that turns out
> to often be higher-value content than your emails themselves are.
> Further, exposed metadata is inherent to SMTP, which means this problem
> is going to be absolutely devilish to fix.

That is true.  But perhaps it would be a start if email clients
actually put the actual email (with subject and references headers
etc.) as an attachment to a bare email that contained only the minimal
headers for delivery.  It wouldn't be a perfect solution, but it would
at least fix a certain amount of metadata analysis.