Specific criticisms of GPG:

> the working hypothesis for privacy enhancing technology was simple: we’d develop really flexible power tools for ourselves, and then teach everyone to be like us... 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

I think it's self-explanatory why it's not good that users need to know about SERPENT, IDEA, and TwoFish.

> the fundamental architecture of PGP also leaves no room for now critical concepts like forward secrecy.

> a ballooning penumbra of OpenPGP specifications and notes so prolific that the entire picture is almost impossible to grasp... Mailpile had to write 1400 lines of python code just to interface with a native GnuPG installation for basic operations, and it still isn’t rock solid.

> journalists who depend on it struggle with it and often mess up (“I send you the private key to communicate privately, right?”)

UX failure leads to user uncertainty or insecure behavior.

What a better replacement looks like (from the comment here):

> Good UX requires thinking about interactions all the way down to the protocol.

> we can start fresh with modern cryptography, a modern protocol, and a modern design philosophy

You list plenty of specific problems with GPG the UI and GPG the "API" (though frankly the fact that mailpile would write 1400 lines of python that wrap GPG rather than taking one of the independent library implementations of RFC4880 and bringing it up to production quality makes them part of the problem). But none of those specific problems are problems with OpenPGP the protocol.

Well, I was only quoting the article, but it sounds like he has a good point that the protocol doesn't support forward secrecy. I also tend to trust his judgment that it's too complicated, and/or the complication adds little value for "normal" users. I guess some of this can be isolated as an app/API problem rather than protocol, as you say.

Perfect forward secrecy is of course better than not, but I'm not convinced it actually helps a lot for realistic threat models. It means that when you utterly screw up and reveal today's treason you won't also be revealing last week's treason - but for someone who's using crypto for serious reasons, how often is it that last week's message would get you in trouble and today's message is innocuous?

Would a ground-up rewrite of OpenPGP have PFS? Of course. Is the functionality important enough to justify a new protocol? Not on its own, IMO.

Follow-up: on more thinking, I don't think it's possible at all without compromising important properties of GPG.

> UX failure leads to user uncertainty or insecure behavior.

I'd say user uncertainty and insecure behavior are, each, sufficient criteria to declare a UX a failure.

Thanks; for the first question, I suppose I should have read more carefully.

The second question, however, still isn't adequately answered; "we should be thinking about interactions" and "we should use modern things" are two of the most vague answers possible.

Apparently it's so hard to use properly that even Snowden screwed it up in the course of communicating during his leaks.

> The frustrating and ironic thing about GPG is that even experts make mistakes with it. Even, as it turns out, Edward Snowden.

> I now had Poitras’ permission to send Snowden her encryption key, but in his first email to me, Snowden had forgotten to attach his key, which meant I could not encrypt my response. I had to send him an unencrypted email asking for his key first.

https://firstlook.org/theintercept/2014/10/28/smuggling-snow...

Any encryption system has to exchange keys, and you can do it easily or securely, pick one. Failing the way you describe makes things cumbersome but does not compromise security.