[tahoe-dev] Removing the dependency of immutable read caps on UEB computation
shawn at willden.org
Sun Oct 4 15:53:38 UTC 2009
On Sunday 04 October 2009 08:52:38 am Zooko O'Whielacronx wrote:
> Interesting. The goal is to be able to upload a file with a different
> K encoding parameter (num shares require to reconstruct) but the same
> plaintext and the same (?) encryption key and have it match the same
> immutable file cap?
Different N or K. Or perhaps a different structure entirely (not sure why
we'd ever want to go there).
> And, as another goal, to make it faster to compute an immutable file
> cap from a plaintext and key? (I.e., you can compute an immutable
> file cap without producing all the erasure coding shares?)
You could compute an immutable file cap without even having the plaintext,
just hashes of plaintext and ciphertext.
> In order to be secure against a
> shapeshifting immutable file, the read-cap itself needs to contain
> something derived from the ciphertext (or even better, the plaintext).
Yes, I suggested that the plaintext and ciphertext hashes be part of the cap
derivation. Allowing re-encoding just requires excluding the share hashes.
> So one storage server might have, under
> storage index X, a share from the 3-of-10 encoding of that file as
> well as a share of the 6-of-10 encoding of the same file? And the
> downloader would specify in its request which encoding of the file it
> is looking for?
I imagine the downloader would first ask what shares the storage server has,
then indicate which ones it wants.
> I don't
> think that we're going to fit all of the desired features into the
> NewCap format (especially because "simplicity of format" is one of the
> desired features!)
I think the "immutable files are just locked-down mutable files" approach
helps with the simplicity of format goal.
More information about the tahoe-dev