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
|
||||
* 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
|
||||
this worked.. it was clever, but I think it had some fatal flaw, like not
|
||||
|
|
Loading…
Reference in a new issue