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
|
||||
* 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?
|
||||
|
||||
## Ideas
|
||||
|
|
Loading…
Reference in a new issue