try to reconstruct zooko's (flawed?) immutable encoding scheme
[Imported from Trac: page NewImmutableEncodingDesign, version 2]
parent
077a48d611
commit
545aca890c
|
@ -73,6 +73,56 @@ here).
|
||||||
* short caps
|
* short caps
|
||||||
* convergence problems
|
* 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?
|
## Others?
|
||||||
|
|
||||||
## Ideas
|
## Ideas
|
||||||
|
|
Loading…
Reference in a new issue