[tahoe-dev] “On the limits of the use cases for authenticated encryption”

Zooko Wilcox-O'Hearn zooko at zooko.com
Thu Apr 26 09:39:22 UTC 2012


On Thu, Apr 26, 2012 at 3:25 AM, Ben Laurie <ben at links.org> wrote:
>
> OK, but that is not the confusing part of the post. The confusing part is where you say "this is no use for Tahoe" but then don't go on to say why! I'd really like to see some flesh on the claim...
>
> Alternatively, its not confusing at all, and what you're saying is that authenticated encryption does not directly provide a way to, for example, "authorize you to check the integrity of a file (ciphertext) without authorizing you to read it". OK, but so what? That's not a property of authenticated encryption, as formally defined. If you want some other system, then you ... want some other system. This just seems like an uninteresting truth to me.

So, I'm not sure if you understand my claims and you find them
uninteresting or if you don't entirely understand them yet and want
more explanation about them.

You may not find it interesting, but _I_ find it interesting that
Authenticated Encryption provides a feature (symmetric authentication)
which Tahoe-LAFS doesn't need, and doesn't provide the
integrity-checking features that Tahoe-LAFS does need. It proves to me
that the AE abstraction is not applicable generally to *all*
authentication/integrity-checking needs, and it makes me wonder: is
Tahoe-LAFS the exception and AE is a fitting solution for most of the
unexplored world of future usage scenarios? Or is it the other way
around -- is two-party session authentication a la TLS the exception
and AE is an ill-fitted tool for most of that unexplored world of
usage scenarios?

Regards,

Zooko


More information about the tahoe-dev mailing list