What's with all these articles dissing the very idea of encrypting email? It used to be that hardly anyone cared. Now there seems to be some effort to discourage something that any reasonable person interested in privacy would enthusiastically support.
This is a pretty typical example from the article of the sort of important sounding but ultimately bogus argument presented in such articles:
>So, for example, it recently turned out to be possible for eavesdroppers to decrypt messages without a key, simply by tampering with encrypted messages.
By failing to actually specify the actual attack the writer hopes to prevent a rebuttal. I am pretty sure they are talking about EFAIL. EFAIL was itself a weird slander of the idea of encrypted email but ultimately did not show any weakness of either PGP or S/MIME. It was instead a cautionary tale about the use of HTML for email.
The article attempts to promote Signal as superior to PGP email. That is unlikely as Signal initially trusts the phone system for identity. It is also quite a lot more complex than PGP so the odds of an exploit are not in Signal's favour.
> By failing to actually specify the actual attack the writer hopes to prevent a rebuttal. I am pretty sure they are talking about EFAIL. EFAIL was itself a weird slander of the idea of encrypted email but ultimately did not show any weakness of either PGP or S/MIME. It was instead a cautionary tale about the use of HTML for email.
What you said there can't be stressed enough. Despite that almost no email client in the past decades defaults to allowing active or remote content. But because you could turn all that on with some clients... it somehow means PGP and S/MIME were impossibly insecure.
Efail worked with the default settings on almost all clients except Mutt. Most email clients do not have a "plain text" mode. They all display emails as HTML and apply some formatting to make the "plain text" mode be monospaced.
Also, one of the Efail exploits (the CDC gadget) was a cryptographic vulnerability. The fact you could manipulate the ciphertext to inject HTML tags such that GPG wouldn't scream bloody murder (because the MDC wasn't required and had very odd semantics, where GPG would output data to the caller before it had been authenticated and clients showed it as a warning and still rendered the HTML exploit) was definitely at its core a cryptographic bug.
All of this was explained in significant detail in the CCC talk about Efail[1].
and was optional. The protocol did not require validation and as a result some protocol compliant implementations were vulnerable.
If a protocol compliant impl is vulnerable, and the fix is to update the protocol, the protocol is broken.
Yes without html you couldn't build this gadget, but we don't blame machine code for making gadgets possible, we blame insecure c for having buffer overflows.
But in use for all the clients that the EFAIL people tested. That was not the problem. The problem was that there were email clients that were loading image URLs from HTML emails. There was nothing to fix in the case of GPG2. It was entirely a problem with the way that certain email clients handled HTML emails ... a problem, might I add, that still exists today. They just prevented the one type of attack. There will undoubtedly be others that may or may not involve encrypted emails.
> However, we found that several clients only gave a warning to the user for invalid MDCs, but still displayed the modified plaintext. This allowed the CFB gadget attack despite the MDC
No, the problem was that clients would render a plaintext known to have been tampered with. This was exacerbated by a zero click gadget, but would still have been an issue if images weren't loaded and a malicious link was clicked.
You're right that Gpg wasn't shown to be broken, but pgp was. (This is the CBC attack, not the direct attacks on clients which are just client bugs, which themselves aren't direct evidence that a protocol is broken)
This is a pretty typical example from the article of the sort of important sounding but ultimately bogus argument presented in such articles:
>So, for example, it recently turned out to be possible for eavesdroppers to decrypt messages without a key, simply by tampering with encrypted messages.
By failing to actually specify the actual attack the writer hopes to prevent a rebuttal. I am pretty sure they are talking about EFAIL. EFAIL was itself a weird slander of the idea of encrypted email but ultimately did not show any weakness of either PGP or S/MIME. It was instead a cautionary tale about the use of HTML for email.
The article attempts to promote Signal as superior to PGP email. That is unlikely as Signal initially trusts the phone system for identity. It is also quite a lot more complex than PGP so the odds of an exploit are not in Signal's favour.