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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
