Efail was one of the best crypto breaks of 2018, accepted into both Usenix Security (a top-tier academic venue) and BHUSA (the top tier industry venue), and virtually universally lauded by actual cryptography engineers and researchers.
What you've said here is false, a personal attack on the researchers, and absolutely unacceptable on HN. Take this stuff somewhere else.
As much as I believe that Efail was the result of badly implemented email clients it's not like the OpenPGP standard hadn't any involvement with it whatsoever. DJB for example suggests small authenticated and encrypted packets, something that OpenPGP does not have. See https://groups.google.com/forum/#!original/boring-crypto/BpU...
Since I am apparently replying too fast and I need to slow down, here is my reply to the child post by Sir_Cmpwn:
> I don't really see the link between the email you posted and efail
GPG decrypts the whole message which might be gigaoctets long and throws it to the output. After it has been decrypted it checks the MDC (if it exists) and throws an error if the MDC does not match or if it is missing. Meanwhile if a OpenPGP message was composed of small authenticated packets GPG would be able to first authenticate if the MAC of the packet is correct and then return an error right away if it does not match. If it did match it would return plaintext and move on to the next packet. You can see now how efail would be prevented, right?
> PGP
Do people use PGP nowadays? I was under the impression that pretty much everyone used GPG ever since it was released.
I don't really see the link between the email you posted and efail, other than the fact that PGP encrypts the whole message. I don't understand how, if it encrypted smaller parts of the message, efail could have been avoided.
PGP has semi-optional, strippable authenticators. Serious cryptographic protocols do not. Plaintext encrypted with a modern AEAD cipher --- forget protocols, here we're just talking about selecting reasonable primitives --- can't be decrypted without simultaneously authenticating. That's not how PGP (or S/MIME) works, and that malleability led to Efail.
No competent engineer would accept in 2019 (or, for that matter, 2009) a new cryptosystem that functioned the way PGP does.
The OpenPGP RFC bis does add AEAD. The spec is overall much too flexible IMO and could use some modernization, but I don't see it as un-salvageable, as you seem to.
OpenPGP is unsalvageable. One of the core goals of modern cryptography is to eliminate backwards compatibility with insecure 1990s crypto; OpenPGP instead lovingly preserves it.
Much of that could be solved by an implementation having user-controlled policies that whitelist/blacklist sets of algorithms. An implementation could be made with a sane default policy.
Of course, some things ought to just be replaced (S2K).
What you've said here is false, a personal attack on the researchers, and absolutely unacceptable on HN. Take this stuff somewhere else.