Let's go through Matt's major points: Key Exchange / Key Management This isn't really a problem with the OpenPGP protocol or an OpenPGP implementation. Th

Let's go through Matt's major points: Key Exchange / Key Management This isn't really a problem with the OpenPGP protocol or an OpenPGP implementation. This is inherent to any system that tries to protect you from active adversaries. If you are willing to use centralization, then you can do something like X509 (what is what TLS uses), but there are many, many cases of CAs issuing bad certificates either by accident or maliciously, e.g., the TURKTRUST incident. You can also do something like Signal with its verified key servers. But, if you want to be decentralized, then somehow you have to get the user involved. So, in my opinion, this is more a criticism of decentralization than of OpenPGP. Now, that doesn't mean that OpenPGP tooling can't help. In fact, about 4 years ago, several initiatives began working on mechanisms to make key discovery much easier, and mostly transparent for users primarily concerned about privacy (as opposed to those whose threat model includes active adversaries, like activists, lawyers, or journalists). See, in particular, the work that pep (https://pep.foundation https://pep.foundation) and Autocrypt (https://autocrypt.org https://autocrypt.org) have been doing. Forward Secrecy As I've written before (https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/ https://arstechnica.com/information-technology/2016/12/signa...), I don't think that forward secrecy is actually fixing a problem that most people have. Particularly in the case of OpenPGP where most people are interested in encryption of data at rest (messages stored on an IMAP server), which forward secrecy doesn't help (forward secrecy, because it throws away old key material, only makes sense for protecting data in motion). But, that doesn't mean that we haven't given some thought to the problem. In fact, at the very same gathering, Justus, who is also working on Sequoia, presented a proposal for adding forward secrecy to OpenPGP in a backwards compatible manner. You can watch the presentation (https://www.youtube.com/watch?v=an6oYjikAPY https://www.youtube.com/watch?v=an6oYjikAPY), or read an early version of the proposal (https://mailarchive.ietf.org/arch/msg/openpgp/mk8_FSS-n4DVGfh_VwuGtEOS2xk https://mailarchive.ietf.org/arch/msg/openpgp/mk8_FSS-n4DVGf...). The short version is: OpenPGP already has mechanisms to mark encryption keys as being appropriate for data at rest or data in motion. Until now, no implementation has bothered with this distinction. We propose creating two encryption-capable subkeys, one for data at rest, and one for data in motion, and rotating the one for data in motion once a week. To ensure that a sender has a non-expired encryption key we pre-generate keys, and distribute them via the keyserver network. The OpenPGP format and defaults suck It is true that OpenPGP has standardized a number of ciphers that are no longer sensible, includes compression support, etc. But, OpenPGP is over 30 years old. In that time there have been many improvements. But Matt is right that these improvements come slowly. This is partly due to the lack of funding: the industry choose S/MIME over OpenPGP. (Although S/MIME is cryptographically worse than OpenPGP. See EFAIL for a critical example of why.) A major difficult to deprecating old ciphers is that OpenPGP is used for data at rest. And people rightly expect, I think, to be able to decrypt data and verify signatures from X years ago. This means we can't completely drop support for, say, CAST5: people wouldn't be able to decrypt old messages. Matt seems to ignore this bit, and focuses primarily on real-time communication (e.g., Signal), which only needs encryption for data in motion, i.e., the encryption is stripped and only archived on a trusted device (e.g., not an IMAP server). One thing that we are consider in Sequoia is requiring the caller to provide a timestamp when verifying or decrypting a message. The timestamp can be used to choose defaults that are appropriate for when the message was allegedly created. The timestamp can be double checked with the timestamp in the signature. In this way, if someone tries to send you an email using a deprecated cipher, they'll also have to set the timestamp in the email to, say, 1997, which would hopefully be suspicious. Likewise, something like a can be shown when the message doesn't meet the current standard. I hope that helps! If you have any other questions, you're welcome to ask here, or on irc (#sequoia on freenode) or on our mailing list (devel@sequoia-pgp.org). :) Neal