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

[Ben Laurie]

On Thu, Apr 26, 2012 at 10:39 AM, Zooko Wilcox-O'Hearn <zooko at zooko.com>wrote:

> 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.
>

I don't know, does it sound like I understand 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?
>

This seems like a different sort of question ... AE provides a way to
encrypt a plaintext s.t. the recipient (who knows the key) can either get
back the original plaintext or an error, and that's all. If you want a
mechanism whereby the recipient _can't_ decrypt, but can do some other
thing (e.g. check integrity), then AE is the wrong tool.

Am I missing something?

OTOH, AE got defined as an abstraction because people finally noticed that
it was happening a lot, without any sound basis. Does the fact that
(apparently) there is not a well-known abstraction that matches Tahoe's
semantics indicate that these semantics are unusual? I guess there are two
parts to this question:

1. Is there really no well-known abstraction? The presence of a near miss
does not indicate the absence of a direct hit :-)

2. If 1 is really true, then I would suggest that the lack of appropriate
existing abstractions reflects the wide non-use of privacy respecting
protocols. Perhaps this is a gap we should fix? That would be an
interesting exercise.


>
> Regards,
>
> Zooko
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120426/70966838/attachment-0001.html>