Changes between Version 1 and Version 2 of NewImmutableEncodingDesign

Timestamp:

2009-08-28T07:15:52Z (15 years ago)

Author:

warner

Comment:

try to reconstruct zooko's (flawed?) immutable encoding scheme

NewImmutableEncodingDesign

@@ -74 +74 @@
  * convergence problems
 
+[http://allmydata.org/pipermail/tahoe-dev/2009-July/002350.html this tahoe-dev message] contains some clues:
+
+{{{
+For immutable files, you have to encrypt+encode the file before you can
+get the secure hash that forms the root of the integrity check (because we
+want to validate the individual shares too). Since you must commit to the
+encryption keys before you get those bits, so you can't just derive the
+encryption keys from that hash. But you could combine that hash with some
+other secret, and hide the main encryption key by encrypting it with that
+secret, and then the bits of that secret would each provide C+Ir. I think
+this is closely related to Zooko's scheme.
+}}}
+
+I still can't reconstruct it, but here's one possibility:
+
+ * pick a random readkey K1 (perhaps via CHK)
+ * pick another random key K2
+ * use K1 to encrypt the data
+ * encode the shares and compute the UEB hash, as usual
+ * store AES(key=H(K2+UEBhash), data=K1) in the share: the encrypted readkey
+ * readcap = K2
+ * storage-index = H(K2)
+ * or storage-index = UEBhash
+
+If SI=H(K2), then the reader starts from readcap=K2, computes the SI, fetches
+the share, computes UEBhash, computes H(K2+UEBhash), decrypts K1, then
+compares the share hash trees against the UEB, decodes the shares, and uses
+K1 to decrypt them. The servers can't validate anything against the
+storage-index (because it is derived from the readcap, which is forbidden to
+them). And I'm pretty sure that Rose the readcap-holder can collude with a
+quorum of storage servers to change the contents of the file, since there's
+nothing in K2 that's dependent upon the actual shares.
+
+If SI=UEBhash, then you've got the integrity checking that you want, but
+there's no way for the readcap holder to find out what the storage-index is,
+so they can neither locate a share (to compute everything else) nor can they
+use the storage-index to validate anything.
+
+== Mutable readcap plus commitment ==
+
+Another idea is to upload regular mutable files, create a readcap, and then
+augment the readcap with some number of I bits (basically the "R=roothash" in
+our current mutable-file layout, which corresponds to the UEB hash in our
+immutable layout). Having the the readcap would reduce the set of people who
+could modify your file down to the writecap holders; adding the I bits would
+reduce/remove their ability to modify it either.
+
+But I think this converges on the current CHK design once you make those
+non-modification guarantees equally strong.
+
 == Others? ==