On Tue, 02 Apr 2019 19:42:50 +0200,
Jon Callas wrote:
On Apr 2, 2019, at 6:12 AM, Conrado P. L. Gouvêa
<conradoplg(_at_)gmail(_dot_)com> wrote:
On Sat, Mar 30, 2019 at 11:59 PM Peter Gutmann
<pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz> wrote:
I'm not saying remove it, just get some data to support making a decision
in
some way. In particular, AEAD is a good thing, but there's no evidence
that
chunking with AEAD, which complicates things greatly, is useful or
necessary.
I know you're tired of hearing about it... but EFail.
Even if PGP used AEAD, but without chunks, EFail would probably still
happen. If the AEAD data is arbitrarly large, then implementations
would be forced to provide a streaming API that discloses
unauthenticated plaintext, and the same thing would happen.
No, no, it’s okay, because this why I was saying, “Let’s not talk about
Efail.” The AEAD discussion is good, and there are many reasons to upgrade to
allow its use. If one of those reasons is complex, then having that be the
major reason means that there’s a counter-argument that is essentially, “if
this isn’t the silver bullet claimed, then maybe we shouldn’t do it,” and
worse, it’s a completely reasonable counter-argument.
I agree that EFail is not the only reason to consider AEAD. And, I
think that the complexity counter argument is a convincing one. Like
Ferguson, Schneier and Kohno said in "Cryptography Engineering":
The more complex a system, the more likely it has security problems.
Indeed, we like to say that complexity is the worst enemy of
security.
But, once we decide that we want AEAD, I think it is fair to apply the
same counter argument to any proposals.
In our case, parameterizing the chunk size adds complexity. It
standardizes not a single algorithm, but a family of algorithms. I've
already shown how this parameterization can be abused. But whether
you think my attack is relevant or not, I think we agree that the
burden of justification ought to be on those defending the complexity,
i.e., allow multiple chunk sizes, or allow large chunk sizes.
Currently, I think the only extant argument in favor of large chunks
is your argument in <BFC5E4EE-01D8-4552-BBB0-F6B09D511160(_at_)icloud(_dot_)com>
or a variant thereof:
I believe that the more you believe tight security is necessary, then
the more *willing* you ought to be to allow people with special needs
to go off in the weeds on their own.
But, we don't prohibit people from experimenting! That's why we have
a private name space. If someone really has such special needs, they
can use, e.g., Tag 61, for an AEAD variant with large chunks. If it
turns out those needs are not so special, we can standardize that
variant.
(Tobias has proposed foregoing chunking. That's a different argument,
and one that I think is not interesting for us since it prevents
streaming.)
If there are other unaddressed arguments in favor of large chunk
sizes, please state them. If I missed them, please repeat them and
accept my apologies.
Thanks!
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp