| 65 | | == Two: Zooko's scheme == |
| | 65 | == Two: Zooko's Scheme == |
| | 66 | |
| | 67 | Zooko wrote this scheme up in |
| | 68 | [http://allmydata.org/pipermail/tahoe-dev/2009-September/002796.html this message] |
| | 69 | and [http://zooko.com/imm-short-readcap-simple-drawing.svg this diagram], |
| | 70 | and was improved upon during the subsequent tahoe-dev discussion. |
| | 71 | |
| | 72 | * pick a random readkey K1 (perhaps via CHK) |
| | 73 | * use K1 to encrypt the data |
| | 74 | * encode the shares and compute the UEB hash, as usual. (zooko's message |
| | 75 | defines v=UEBhash) |
| | 76 | * K2 = H(K1+UEBhash) |
| | 77 | * K1enc = AES(key=K2, data=K1) |
| | 78 | * readcap = K2 |
| | 79 | * storage-index = H(K2) |
| | 80 | * verifycap = H(K1enc+UEBhash) |
| | 81 | * store sharedata and K1enc on the server |
| | 82 | |
| | 83 | Properties: |
| | 84 | |
| | 85 | * storage-index is unknown until the end of encoding. |
| | 86 | * change the storage protocol to permit assignment of storage-index after |
| | 87 | upload |
| | 88 | * To get Tahoe2-style load-balancing, define a separate |
| | 89 | "server-selection-index" value (which has no cryptographic requirements |
| | 90 | and can be much shorter, perhaps 20 bits), either randomly or with some |
| | 91 | convergence-secret salted CHK scheme. Put this value in the readcap. |
| | 92 | * readcap is kappa (e.g. 128bits) plus len(SSI), so perhaps 148bits total |
| | 93 | * verifycap cannot be offline-derived from readcap (it requires knowing |
| | 94 | K1enc, which cannot be included in the UEB since that'd be circular) |
| | 95 | * server does not have full validation (they can check that shares are |
| | 96 | internally consistent, but cannot confirm that they've been stored under |
| | 97 | the correct storage-index) |
| | 98 | |
| | 99 | To download the file, the readcap holder does: |
| | 100 | |
| | 101 | * extract server-selection-index from readcap, permute peerlist with it |
| | 102 | * extract K2 from readcap |
| | 103 | * compute storage-index = H(K2) |
| | 104 | * query peers for shares |
| | 105 | * fetch K1enc, UEBhash from at least one share |
| | 106 | * decrypt K1=AES(key=K2, data=K1enc) |
| | 107 | * compute K2'=H(K1,UEBhash), assert K2'==K2 |
| | 108 | * any share which fails this test is discarded |
| | 109 | * once the valid UEBhash is determined, any share with a different UEBhash |
| | 110 | is discarded |
| | 111 | * fetch UEB, validate against UEBhash |
| | 112 | * fetch share data, validate, decode, decrypt, emit plaintext |
| | 113 | |
| | 114 | |
| | 115 | == Three: Brian's previous flawed reconstruction of Zooko's scheme == |
