From 903ff7d5bdb6f422b73c5128e0506a0a44ccead6 Mon Sep 17 00:00:00 2001
From: warner <>
Date: Mon, 7 Sep 2009 21:33:31 +0000
Subject: [PATCH] add zooko's real proposal

[Imported from Trac: page NewImmutableEncodingDesign, version 4]
---
 NewImmutableEncodingDesign.md | 52 ++++++++++++++++++++++++++++++++++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/NewImmutableEncodingDesign.md b/NewImmutableEncodingDesign.md
index c591219..cca95b5 100644
--- a/NewImmutableEncodingDesign.md
+++ b/NewImmutableEncodingDesign.md
@@ -62,7 +62,57 @@ SI = H(C), SSI=SI. Verifycap is SI+I.
  * long caps (128+256+len(k+N+filesize)) ~= 400bits
  * server cannot verify entire share
 
-## Two: Zooko's scheme
+## Two: Zooko's Scheme
+
+Zooko wrote this scheme up in
+[this message](http://allmydata.org/pipermail/tahoe-dev/2009-September/002796.html)
+and [this diagram](http://zooko.com/imm-short-readcap-simple-drawing.svg),
+and was improved upon during the subsequent tahoe-dev discussion.
+
+ * pick a random readkey K1 (perhaps via CHK)
+ * use K1 to encrypt the data
+ * encode the shares and compute the UEB hash, as usual. (zooko's message
+   defines v=UEBhash)
+ * K2 = H(K1+UEBhash)
+ * K1enc = AES(key=K2, data=K1)
+ * readcap = K2
+ * storage-index = H(K2)
+ * verifycap = H(K1enc+UEBhash)
+ * store sharedata and K1enc on the server
+
+Properties:
+
+ * storage-index is unknown until the end of encoding.
+  * change the storage protocol to permit assignment of storage-index after
+    upload
+  * To get Tahoe2-style load-balancing, define a separate
+    "server-selection-index" value (which has no cryptographic requirements
+    and can be much shorter, perhaps 20 bits), either randomly or with some
+    convergence-secret salted CHK scheme. Put this value in the readcap.
+ * readcap is kappa (e.g. 128bits) plus len(SSI), so perhaps 148bits total
+ * verifycap cannot be offline-derived from readcap (it requires knowing
+   K1enc, which cannot be included in the UEB since that'd be circular)
+ * server does not have full validation (they can check that shares are
+   internally consistent, but cannot confirm that they've been stored under
+   the correct storage-index)
+
+To download the file, the readcap holder does:
+
+ * extract server-selection-index from readcap, permute peerlist with it
+ * extract K2 from readcap
+ * compute storage-index = H(K2)
+ * query peers for shares
+ * fetch K1enc, UEBhash from at least one share
+ * decrypt K1=AES(key=K2, data=K1enc)
+ * compute K2'=H(K1,UEBhash), assert K2'==K2
+  * any share which fails this test is discarded
+  * once the valid UEBhash is determined, any share with a different UEBhash
+    is discarded
+ * fetch UEB, validate against UEBhash
+ * fetch share data, validate, decode, decrypt, emit plaintext
+
+
+## Three: Brian's previous flawed reconstruction of Zooko's scheme
 
 Readcaps contain one crypto value that combines C and I fields. (I forget how
 this worked.. it was clever, but I think it had some fatal flaw, like not