<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 26, 2012 at 10:39 AM, Zooko Wilcox-O'Hearn <span dir="ltr"><<a href="mailto:zooko@zooko.com" target="_blank">zooko@zooko.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Apr 26, 2012 at 3:25 AM, Ben Laurie <<a href="mailto:ben@links.org">ben@links.org</a>> wrote:<br>

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

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

<br>
</div>So, I'm not sure if you understand my claims and you find them<br>
uninteresting or if you don't entirely understand them yet and want<br>
more explanation about them.<br></blockquote><div><br></div><div>I don't know, does it sound like I understand them?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
You may not find it interesting, but _I_ find it interesting that<br>
Authenticated Encryption provides a feature (symmetric authentication)<br>
which Tahoe-LAFS doesn't need, and doesn't provide the<br>
integrity-checking features that Tahoe-LAFS does need. It proves to me<br>
that the AE abstraction is not applicable generally to *all*<br>
authentication/integrity-checking needs, and it makes me wonder: is<br>
Tahoe-LAFS the exception and AE is a fitting solution for most of the<br>
unexplored world of future usage scenarios? Or is it the other way<br>
around -- is two-party session authentication a la TLS the exception<br>
and AE is an ill-fitted tool for most of that unexplored world of<br>
usage scenarios?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Am I missing something?</div><div><br></div><div>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:</div>
<div><br></div><div>1. Is there really no well-known abstraction? The presence of a near miss does not indicate the absence of a direct hit :-)</div><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
<br>
Zooko<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a><br>
<a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
</div></div></blockquote></div><br></div>