From 545aca890ce43a346a146378b3359bb1bdbd8bf2 Mon Sep 17 00:00:00 2001
From: warner <>
Date: Fri, 28 Aug 2009 07:15:52 +0000
Subject: [PATCH] try to reconstruct zooko's (flawed?) immutable encoding
 scheme

[Imported from Trac: page NewImmutableEncodingDesign, version 2]
---
 NewImmutableEncodingDesign.md | 50 +++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/NewImmutableEncodingDesign.md b/NewImmutableEncodingDesign.md
index f3ef5b0..f3d4774 100644
--- a/NewImmutableEncodingDesign.md
+++ b/NewImmutableEncodingDesign.md
@@ -73,6 +73,56 @@ here).
  * short caps
  * convergence problems
 
+[this tahoe-dev message](http://allmydata.org/pipermail/tahoe-dev/2009-July/002350.html) 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?
 
 ## Ideas