On Mon, Sep 24, 2012 at 10:59 AM, Yaverot <span dir="ltr"><<a href="mailto:Yaverot@computermail.net" target="_blank">Yaverot@computermail.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">A key part of Tahoe is that if someone else sticks the Avengers movie that comes out tomorrow on my server, I have no knowledge or access to it. So $BigCompany can't just MD5(avengers movie) and then sue me into oblivion for "distributing" it. You're probably fine to backup Windows 7, but if it lands on my server... I don't have a Win7 license.</div>

</blockquote><div><br></div><div>You're describing the confirmation of file attack (itself a degenerate form of the "learn the remaining information" attack).</div><div><br></div><div>Even in a system like Tahoe you have plausible deniability in this case. While $BigCompany can discover you have an encrypted copy of their intellectual property, you can claim 1) someone else put it there 2) you don't have the readcap needed to decrypt it, therefore you have no access to the actual content.</div>

<div><br></div><div>That said, I'd propose the following options, both of which I'd like to support:</div><div><br></div><div>1) No added secret value: this opens you up to the aforementioned attacks, but provides global deduplication</div>

<div>2) Added secret value: instead of a per-user secret, I'd like to simply add a random secret to the capability string itself. This prevents the aforementioned attacks, while also providing the sort of easy transferability that makes capabilities great</div>

<div><br></div></div>-- <br>Tony Arcieri<br><br>