[tahoe-dev] separating security and redundancy layers Re: help! how do I manage dependencies on JavaScript code?

Zooko O'Whielacronx zooko at zooko.com
Fri Sep 3 16:21:23 UTC 2010


On Fri, Sep 3, 2010 at 10:03 AM,  <travis+ml-tahoe-dev at subspacefield.org> wrote:
>
> My first impression on reading about the project is, "redundancy and
> crypto in the same tool?  I wonder if they couldn't be separated".

Actually I've been wondering the same thing recently. The encryption
and the creation of ciphertext-integrity-checks is performed before
the erasure-coding, so in principle it would be possible to make those
separately usable or allow composition of alternate implementations of
them, etc.

You can see a bit of this in the fact that the Upload Erasure Coding
Helper accepts ciphertext from the client and does the erasure coding
step. The purpose being that the client can do the encryption and
upload ciphertext over its slow home DSL line to the Upload Erasure
Coding Helper which can erasure-code the ciphertext and send the
resulting shares out to storage server over a faster net connection.

Also the new downloader offers the ability in its Python API to
download and return just the ciphertext, although that ability is not
exposed in the Web API. (If someone wants to do the work to implement
that, by all means volunteer!)

I'm not sure if this approach would run into trouble in the management
of capabilities, though. We should definitely write down in
http://tahoe-lafs.org/trac/tahoe-lafs/wiki/NewCapDesign that one
desideratum for the next capability design is to facilitate this:
using the crypto layer without using the erasure coding layer. (N.B.
I'm not sure that we'll succeed at achieving that desideratum along
with all the other ones, but we should still write it down so we
consciously know if we are sacrificing it.)

Regards,

Zooko



More information about the tahoe-dev mailing list