update on the hypothetical zooko scheme
[Imported from Trac: page NewImmutableEncodingDesign, version 3]
parent
253e53fac9
commit
2f544a5dbd
|
@ -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
|
||||
|
||||
|
|
Loading…
Reference in a new issue