[tahoe-dev] Removing the dependency of immutable read caps on UEB computation

[Shawn Willden]

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.

	Shawn.