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.arci...@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 <unclezz...@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@tahoe-lafs.org >> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev >> >> > > > -- > Tony Arcieri > > _______________________________________________ > tahoe-dev mailing list > tahoe-dev@tahoe-lafs.org > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > >
_______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
