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

[Zooko O'Whielacronx]

Shawn:

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?

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?)

I'm not sure that I understood the goals.

Hm, it seems like some solutions to that first goal would open the
possibility of a "shapeshifting immutable file attack" -- the attack
where the original creator of an immutable file makes it so that some
downloaders see a different file than others see (like Christan
Grothoff's Hall of Fame entry [1]).  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).

Also, would storage servers keep different "encoding parameter
variants" of the same share?  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 guess these desiderata (use same immutable file cap for different K,
and compute immutable file cap efficiently) should be ticketed and/or
added to http://allmydata.org/trac/tahoe/wiki/NewCapDesign .  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!), but I would like to have thorough documentation of
what things are desired and what the trade-offs are.

Regards,

Zooko

[1] http://hacktahoe.org