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
|
quorum of storage servers to change the contents of the file, since there's
|
||||||
nothing in K2 that's dependent upon the actual shares.
|
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
|
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,
|
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
|
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
|
## Mutable readcap plus commitment
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue