> I think the article is five years old, has not aged well (e.g. MUA > integration has improved), and that nothing better than PGP has come > along in the meantime. I think Matthew Green is a very sharp fellow and his criticisms are thoroughly on-point. My biggest complaint about that article is that he doesn't draw a clean distinction among the OpenPGP specification, how software packages like GnuPG choose to implement the specification, and the supporting ecosystem that is neither OpenPGP nor implementation.
The OpenPGP spec says surprisingly little about what the format of a key should be, for instance. If you look at GnuPG's key export format, it was chosen in the late '90s to be interoperable with PGP Security's PGP 5.0 offering (which was, at the time, pretty much cutting-edge). Well -- nowadays GnuPG is the big mover in that space. There's a strong argument to be made that GnuPG should be more of an innovator. There's no reason anymore to retain the old and inefficient PGP 5 format. We can change it and still be compliant with the spec: maybe we should. I think we should. And hey, if we fix the key exchange format, that's one massive section of his objections gone. That set of objections isn't to OpenPGP, it's purely about how we implement it. Another major complaint of his is the keyserver network, which we've known for years was inadequate. It was also the only game in town and there was neither the money nor the manpower to do a better job. Now we've got Autocrypt, WKD, and Hagrid: of these Autocrypt is probably the most mature and the easiest for email users. We've got three at least arguably better ways of distributing certificates: if we can actually persuade people to start using them, we can fix this and wipe another set of complaints off his list. His set of objections here is not to either OpenPGP or an implementation of it, but rather the support ecosystem. (Note to anyone who thinks I'm saying "it's kinda good that this Great Unpleasantness is happening because it's making people migrate": no. Absolutely not. The people behind this deserve to be shunned by our community and exiled from our mailing lists. They are not our friends.) About the only actual protocol-level complaints Professor Green has are: 1. OpenPGP has no forward secrecy. (Correct! I'd love to see the OpenPGP Working Group tackle this. I'm not sure it can be done for offline asynchronous communications, but it would be good to at least investigate the possibilities.) 2. OpenPGP has no AE/AEAD mode. (Incorrect! The MDC is a form of authenticated encryption. It predates modern AE/AEAD and looks kind of baroque to modern eyes, but it's AE. The fact some mail clients *ignore* the AE is a different [and very serious!] matter. Further, the latest RFC4880bis spec -- which was written after Professor Green's blogpost -- explicitly incorporates modern AE/AEAD.) My complaint about Professor Green's blogpost is that he treats PGP as a single monolithic block, instead of as different plants in a garden that all grow interdependently. The OpenPGP protocol is solid. But we can, and I think we need to, do a serious modernization pass on how we choose to *implement* that protocol. If I were to set priorities for GnuPG? 1. Set a flag day. Past a certain date, old-and-busted certificates and data formats will simply not be supported. They won't be written, they won't be read, they won't be processed, GnuPG will simply say "nope, that might be legit old-school RFC4880 traffic but I'm not going to play that game." 2. Overhaul the key format. 3. Do away with user IDs. Only use key IDs. If a user wants to associate a key with an email address, let them: but user IDs originally existed *mostly* to support the email use case, and with the advent of Autocrypt that's not such an issue any more. (Note that a lot of thorny problems suddenly just *go away* if you stop using userIDs.) 4. Require a limited subset of the RFC4880bis standard to be used. Keep support for adding ciphers to the spec -- algorithm agility is a wonderful thing -- but by default only use one specific ECC algorithm in one specific key length, with AES256 as a symmetric cipher, and SHA512 for a hash. GnuPG's ability to support arbitrary preferences and algorithms is neat technically but I have literally *never* seen it be necessary in field usage, and I have seen people accidentally degrade their security literally *hundreds* of times. (If your cipher preferences are 3DES AES128 AES256, for instance? Say hello to 3DES: you will literally never use AES256.) 5. If we're going to continue to have a keyserver network the only way forward is to burn it down and build something newer and better. There are no other realistic options. 6. Develop a well-defined output format. Werner & co. like to say the output of --with-colons is well-defined. It's not. Unless there's something like a DTD or a BNF specification and the output can be formally verified against the specification, what you have is ad hoc. The processing bugs the Efail paper exploited were overwhelmingly caused by MUA authors misunderstanding or misinterpreting the output GnuPG was giving it. ... Would this be painful? Sure. But it doesn't involve throwing out the OpenPGP spec, just overhauling how we implement it and the supporting software ecosystem. That would be *hard*, don't get me wrong, and I am *in no way* saying this would be easy. But worth it? I dunno. Maybe. Yeah. Let's throw it out there, let's talk about it. But that's just me. :) _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users