I wasn't referring to the existing scheme at tahoe-lafs, but to the idea (I think by Zooko) of using. message-locked encryption (see attached PDF) in a future version of Tahoe-LAFS.<br><br><div class="gmail_quote">On Sat, Jan 26, 2013 at 2:10 PM, Peter Secor <span dir="ltr"><<a href="mailto:secorp@secorp.net" target="_blank">secorp@secorp.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You may want read the configuration document (<a href="https://tahoe-lafs.org/trac/tahoe-lafs/browser/git/docs/configuration.rst" target="_blank">https://tahoe-lafs.org/trac/tahoe-lafs/browser/git/docs/configuration.rst</a>) where it describes the file <tahoe home>/private/convergence which contains a convergence secret. This secret is used by the client node to construct the URI when uploading a file and is by default randomly generated for each new client node when you first start it up. If you want to enable convergent encryption, you have to set this convergence secret for each node that is uploading a file. I believe that this means in order to determine whether you have already uploaded content by checking whether the convergent encryption short-circuits the upload can only occur if the other party obtains the convergence secret. Of note is that the empty string is considered a valid string, so if you set the string to empty in the file, then anybody else who sets that string to empty will have the same convergence secret and thus be able to notice if the upload need not occur due to the contents having already been uploaded by you or another party.</div>
<div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 24, 2013 at 6:38 PM, Tony Arcieri <span dir="ltr"><<a href="mailto:tony.arcieri@gmail.com" target="_blank">tony.arcieri@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Something I've thought about along these lines: (optionally) including a convergence secret within the capability itself. Excluding it would give you dedup and shorter capabilities. Including it would prevent the confirmation of file/learn the remaining data attacks but make the capability longer.</div>



<div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Thu, Jan 24, 2013 at 4:51 PM, Uncle Zzzen <span dir="ltr"><<a href="mailto:unclezzzen@gmail.com" target="_blank">unclezzzen@gmail.com</a>></span> wrote:<br>



</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div><div><div>Hi.<br></div>I've been looking at <a href="https://www.filerock.com/" target="_blank">https://www.filerock.com/</a> and although I have some reservations (server isn't open source, reasons to believe they collect statistics - e.g. web interface has google analytics, etc.) it's still interesting as something I could tell granny: "use this, it's pretty safe" (tried this with LAE and she's still recovering :) ), so any insight about them is welcome.<br>




<br></div>Anyway - I was reading the slides about "dedupable crypto" zooko has mentioned (don't remember where, can't find url now, but here's what I think is <a href="http://eprint.iacr.org/2012/631" target="_blank">the paper</a>), and my main concern is an attacker's ability to prove I'm storing known plaintext (censored, copyrighted, etc.). The estimate of what you save from this is 50% (just charge the customers twice, case closed). What you <i>risk</i> may be jail or worse :(<br>




<br></div>Now filerock has a very trivial approach: there's a folder called "encrypted" and the rest <i>isn't</i> (and can be easily deduped).<br></div><br>At the moment - everything in Tahoe-LAFS is encrypted (ain't complainin'). In future Tahoe-LAFS releases I'd rather see a choice per file between "encrypted (default)" and "plaintext (cheaper)" than having to use "dedupable crypto", exposing myself to censorship/copyright/etc. attacks.<br>




<br></div>Just my .002BTC worth<br></div>
<br></div></div>_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org" target="_blank">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>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Tony Arcieri<br>
</font></span></div>
<br>_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org" target="_blank">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>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<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>
<br></blockquote></div><br>