From 2f544a5dbdb2408a60cd3962372af52ea3c9d572 Mon Sep 17 00:00:00 2001
From: warner <>
Date: Thu, 3 Sep 2009 07:06:32 +0000
Subject: [PATCH] update on the hypothetical zooko scheme

[Imported from Trac: page NewImmutableEncodingDesign, version 3]
---
 NewImmutableEncodingDesign.md | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/NewImmutableEncodingDesign.md b/NewImmutableEncodingDesign.md
index f3d4774..c591219 100644
--- a/NewImmutableEncodingDesign.md
+++ b/NewImmutableEncodingDesign.md
@@ -106,10 +106,27 @@ 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=H(K2) and K1=CHK(data), then you get protection against Rose+Server,
+but you only get to discover problems after you've extracted all of the
+plaintext, so alacrity is maximally bad (you can't deliver the first byte
+of validated plaintext until you've retrieved the last byte of the ciphertext).
+
+Not having a validated UEB is troublesome, because then you don't know which
+shares are good, so if whatever subsequent validation you have (like a CHK)
+fails, you don't know which shares to throw out. But since all shares are
+supposed to have a copy of the same UEB, there's a workaround: validate each
+share up to its local UEB, sort the varieties of UEBs that you see, start
+with the most popular one, see if a decode matches your CHK. If not, iterate
+to the next-less-popular variant, etc.
+
 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.
+use the storage-index to validate anything. You could imagine a separate
+table, though, that mapped H(K2) to storage-index values, but of course this
+table would have to be stored somewhere, etc.
+
+
 
 ## Mutable readcap plus commitment