Neal H. Walfield <neal(_at_)walfield(_dot_)org> writes:
But what is the cost? I would say there is basically none. So it makes no
sense to me to optimize for this case. It's irrelevant.
There is a significant cost in terms of implementing, debugging, and interop-
testing every implementation that wants to do this. If no-one cares about
auth protection of data at rest, and in the complete absence of real-world
data I'm going to claim no-one does because you can't prove otherwise, using
what we currently have has zero cost because it's already implemented. Adding
blocked auth protection has a distinctly nonzero cost.
Efail occured. Why is that not enough?
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'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.
Peter.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp