On Thu, Apr 26, 2012 at 10:39 AM, Zooko Wilcox-O'Hearn <[email protected]>wrote:
> On Thu, Apr 26, 2012 at 3:25 AM, Ben Laurie <[email protected]> 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 > [email protected] > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev >
_______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
