add zooko's real proposal
[Imported from Trac: page NewImmutableEncodingDesign, version 4]
parent
5fcb5259c4
commit
903ff7d5bd
|
@ -62,7 +62,57 @@ SI = H(C), SSI=SI. Verifycap is SI+I.
|
||||||
* long caps (128+256+len(k+N+filesize)) ~= 400bits
|
* long caps (128+256+len(k+N+filesize)) ~= 400bits
|
||||||
* server cannot verify entire share
|
* server cannot verify entire share
|
||||||
|
|
||||||
## Two: Zooko's scheme
|
## Two: Zooko's Scheme
|
||||||
|
|
||||||
|
Zooko wrote this scheme up in
|
||||||
|
[this message](http://allmydata.org/pipermail/tahoe-dev/2009-September/002796.html)
|
||||||
|
and [this diagram](http://zooko.com/imm-short-readcap-simple-drawing.svg),
|
||||||
|
and was improved upon during the subsequent tahoe-dev discussion.
|
||||||
|
|
||||||
|
* pick a random readkey K1 (perhaps via CHK)
|
||||||
|
* use K1 to encrypt the data
|
||||||
|
* encode the shares and compute the UEB hash, as usual. (zooko's message
|
||||||
|
defines v=UEBhash)
|
||||||
|
* K2 = H(K1+UEBhash)
|
||||||
|
* K1enc = AES(key=K2, data=K1)
|
||||||
|
* readcap = K2
|
||||||
|
* storage-index = H(K2)
|
||||||
|
* verifycap = H(K1enc+UEBhash)
|
||||||
|
* store sharedata and K1enc on the server
|
||||||
|
|
||||||
|
Properties:
|
||||||
|
|
||||||
|
* storage-index is unknown until the end of encoding.
|
||||||
|
* change the storage protocol to permit assignment of storage-index after
|
||||||
|
upload
|
||||||
|
* To get Tahoe2-style load-balancing, define a separate
|
||||||
|
"server-selection-index" value (which has no cryptographic requirements
|
||||||
|
and can be much shorter, perhaps 20 bits), either randomly or with some
|
||||||
|
convergence-secret salted CHK scheme. Put this value in the readcap.
|
||||||
|
* readcap is kappa (e.g. 128bits) plus len(SSI), so perhaps 148bits total
|
||||||
|
* verifycap cannot be offline-derived from readcap (it requires knowing
|
||||||
|
K1enc, which cannot be included in the UEB since that'd be circular)
|
||||||
|
* server does not have full validation (they can check that shares are
|
||||||
|
internally consistent, but cannot confirm that they've been stored under
|
||||||
|
the correct storage-index)
|
||||||
|
|
||||||
|
To download the file, the readcap holder does:
|
||||||
|
|
||||||
|
* extract server-selection-index from readcap, permute peerlist with it
|
||||||
|
* extract K2 from readcap
|
||||||
|
* compute storage-index = H(K2)
|
||||||
|
* query peers for shares
|
||||||
|
* fetch K1enc, UEBhash from at least one share
|
||||||
|
* decrypt K1=AES(key=K2, data=K1enc)
|
||||||
|
* compute K2'=H(K1,UEBhash), assert K2'==K2
|
||||||
|
* any share which fails this test is discarded
|
||||||
|
* once the valid UEBhash is determined, any share with a different UEBhash
|
||||||
|
is discarded
|
||||||
|
* fetch UEB, validate against UEBhash
|
||||||
|
* fetch share data, validate, decode, decrypt, emit plaintext
|
||||||
|
|
||||||
|
|
||||||
|
## Three: Brian's previous flawed reconstruction of Zooko's scheme
|
||||||
|
|
||||||
Readcaps contain one crypto value that combines C and I fields. (I forget how
|
Readcaps contain one crypto value that combines C and I fields. (I forget how
|
||||||
this worked.. it was clever, but I think it had some fatal flaw, like not
|
this worked.. it was clever, but I think it had some fatal flaw, like not
|
||||||
|
|
Loading…
Reference in a new issue