EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
This is the worst reaction to a serious and interesting vulnerability I think I&#x27;ve ever seen on HN.<p>The problem being exploited today is that PGP isn&#x27;t properly authenticated. PGP has an authenticator, but it&#x27;s simply the SHA-1 of the plaintext appended to the message. Since even that SHA-1 was a later addition to the protocol, mainstream PGP implementations will process messages that lack the hash and decrypt the message. This is broken: a basic property of modern authenticated cryptography is not to present plaintext to the caller until integrity is checked. There are modern AEAD constructions that go through contortions to obtain that property.<p>The attack is trivial and obvious <i>in retrospect</i>. Attackers strip off the SHA-1 authenticator of a message and then flip bits in the ciphertext to inject HTML that, when rendered, exfiltrates plaintext.<p>The GPG project objects to the way this attack is characterized. If you strip the SHA-1 hash off a message, GPG will print a warning. But popular mainstream GPG clients don&#x27;t honor that warning, which doesn&#x27;t say &quot;Stop, don&#x27;t process this plaintext I am showing you&quot;, but rather &quot;message was not integrity protected&quot;. The fact is, there isn&#x27;t 1 cryptography engineer in 10 that knew exactly what GPG&#x27;s behavior with a stripped MDC was or how they should check for it.<p>This is, to me, an almost perfect analog of the event where it was revealed that the curl API didn&#x27;t check TLS certificates on CURL_SSL_VERIFYHOST=1, but that was OK because the man page said you should use CURL_SSL_VERIFYHOST=2 if you wanted checking. Sure, programming languages cast &quot;true&quot; to 1, and there was literally no meaningful distrinction between 0 and 1 in curl&#x27;s design, and, sure, dozens of applications were made insecure by that design decision, but, really, it&#x27;s in the man page, so they should have known better.<p>Is &quot;don&#x27;t render plaintext when an MDC isn&#x27;t present in the message&quot; in the GPG man page?<p>Other people object because this exploit depends on HTML email to function. It&#x27;s a vulnerability with HTML email readers, not PGP! That&#x27;s an even dumber objection. It is precisely analogous to the argument that BEAST and CRIME and Lucky13 weren&#x27;t vulnerabilities in TLS, because, after all, they depended on browser HTTP behavior in order to function.<p>The right thing for GPG to have done was to not render plaintext at all if a valid MDC wasn&#x27;t included in the message. To provide for compatibility and diagnostics in the vanishingly rare cases where it would be needed, they could have had a flag to restore the current insecure behavior. But, like curl, they did the opposite of the right thing, and now they&#x27;re blaming downstream while implicitly doubling down on their own broken behavior. Not encouraging.<p>Finally: several people, including the GPG project apparently, are claiming that the researchers behind this work didn&#x27;t reach out to them. But Werner Koch himself said that the researchers reached out on November 24th of last year.<p>This is a shitshow, but it&#x27;s also probably going to be the best crypto attack of the year. Be careful dismissing it; I think that won&#x27;t be a good look in the long run.