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 <[email protected]> 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 > [email protected] > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > > -- Tony Arcieri
_______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
