[tahoe-dev] Thoughts about filerock and dedup

[Peter Secor]

You may want read the configuration document (
https://tahoe-lafs.org/trac/tahoe-lafs/browser/git/docs/configuration.rst)
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.


On Thu, Jan 24, 2013 at 6:38 PM, Tony Arcieri <tony.arcieri at gmail.com>wrote:

> 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.
>
>
> On Thu, Jan 24, 2013 at 4:51 PM, Uncle Zzzen <unclezzzen at gmail.com> wrote:
>
>> Hi.
>> I've been looking at https://www.filerock.com/ 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.
>>
>> 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 the paper <http://eprint.iacr.org/2012/631>), 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 *risk* may
>> be jail or worse :(
>>
>> Now filerock has a very trivial approach: there's a folder called
>> "encrypted" and the rest *isn't* (and can be easily deduped).
>>
>> 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.
>>
>> Just my .002BTC worth
>>
>> _______________________________________________
>> tahoe-dev mailing list
>> tahoe-dev at tahoe-lafs.org
>> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>>
>>
>
>
> --
> Tony Arcieri
>
> _______________________________________________
> 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/20130125/43519ddb/attachment.html>