[tahoe-dev] Thoughts about filerock and dedup

[Uncle Zzzen]

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.

On Sat, Jan 26, 2013 at 2:10 PM, Peter Secor <secorp at secorp.net> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20130126/21ba8d25/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ristenpart-mle.pdf
Type: application/pdf
Size: 4460781 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130126/21ba8d25/attachment-0001.pdf>