(Sorry, I'm a lurker in this group, but wanted to chime in...)
On Fri, Mar 29, 2019 at 10:45 AM Peter Gutmann
<pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz> wrote:
That was due to broken email apps. If I can convince your email app to
forward the plaintext of a decrypted message to me, you lose no matter what
encryption mechanism you use.
Admittedly CBC/CFB made this easier, but it was the email apps that needed
fixing, not PGP.
I believe that's not true. The second EFail attack was caused by PGP
allowing removing the MDC or downgrading packets. This would not
happen if PGP handled authentication correctly.
I'm not saying it's not worth addressing, but before endlessly debating
solutions we need to figure out what problem we're solving. "We have this
cool AEAD mode lying around and want to apply it to something" isn't a
problem, or at least not a problem that a PGP user cares about solving, it's
something interesting for geeks to play with.
In the last five years or so I've received approximately zero PGP-encrypted
emails, and I'm one of the people who helped write the thing. OTOH I've
probably encrypted gigabytes of data with it, almost always symmetric-key with
the key communicated out of band. In none of those cases would blocked auth
protection have been useful.
This whole discussion has nothing to do with AEAD itself. With
"manual" encrypt-then-authenticate, the issue of chunk size and
releasing unauthenticated plaintext is the same.
Even for data at rest: many people store the data in cloud providers,
where it could be tinkered with by attackers.
If the problem is to be resilient to file corruption, then the answer
is error-correcting codes, not ignoring authentication. (Though I
agree that's an important issue that is mostly overlooked in crypto)
Conrado
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp