David-Sarah Hopwood wrote: >> * verifycap cannot be offline-derived from readcap: >> ... >> One mitigation strategy would be to store both readcap and >> verifycap in dirnodes, effectively caching the verifycap >> computation. > > Given that the combined (readcap, H(v, k1_enc)) is as short as just > the readcap in any alternative scheme, this seems quite acceptable to > me.
Yeah, it's just that it'll require a new dirnode format, and it means that the "add_child" webapi operation (which accepts a childname and childcap, and adds a new child to a directory) will have to first run out to the servers and figure out the verifycap. Annoying, but not fatal. >> * but since storage-index != verifycap (i.e. H(UEBhash+k1enc)), >> servers will be unable to completely validate their shares. They >> can confirm that everything (including K1enc, thanks to >> David-Sarah's suggestion) matches the verifycap, but they can't >> tell that the verifycap matches the storage-index under which the >> share is stored (i.e. they'd be unable to detect two swapped >> sharefiles). This permits the "roadblock" attack and generally >> misses our goals of allowing full server-side validation. > > That could be fixed by including the storage index in the verifycap, > i.e. (storage_index, H(v, k1_enc)). Nope :(. You can give both the storage-index and the verifycap (H(UEBhash+k1enc)) to the server, but they've got not way to confirm that they two are related.. they just have to take your word for it. To visualize this, imagine that you've created share A, with SI_A and Vcap_A (=H(v,k1_enc)) , and you've also created share B with SI_B and Vcap_B. Now because you're evil, you send share A, SI_B, and Vcap_A to the server (i.e. you put share A in the place where share B ought to go). The server can confirm that share A matches Vcap_A. But because they don't get the readcap, they can't do the operation to show that SI_B doesn't match share A. I still don't know how to solve this one for immutable files. For mutable files, we want the verifycap and storage-index to both be the public key (or its hash). > dirnodes still only need to store (readcap, H(v, k1_enc)), since > the readcap can be hashed to get the storage index. Yeah, unless/until we want traversalcaps, for which we need to store the verifycap in a place where mere traversalcap-holders can see it. That probably means storing some redundant information. >> * we wouldn't be able to directly use our permuted-list Tahoe2 >> peer-selection protocol, since we won't know the storage-index >> (and thus the permuted list) until after we've uploaded all the >> shares. > > Zooko's protocol still works if r = H(k1, H(plaintext)), rather than r > = H(k1, H(ciphertext)). In that case you would only need to know the > hash of the plaintext, not the encoded ciphertext, to calculate the > storage-index. Does that help? It would reduce the amount of work needed to compute the storage index, but I think it would also cease to provide integrity checking on the ciphertext. That might get us into a situation where we 1) have poor alacrity, since we'd have to pull down the whole plaintext before being able to validate anything, 2) when something failed, we couldn't tell which shares were bad, so we could try other ones, and 3) the readcap-to-verifycap attenuation would require a full download, not just a network roundtrip. I think we really need r=H(k1,H(UEB)) to make the integrity properties work. > Are the above suggestions enough to address your dissatisfaction? Not yet, although I suspect I may be misunderstanding some of your suggestions.. please correct me if I got it wrong. thanks! -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
