[tahoe-dev] how to encrypt and integrity-check with only one value

[Brian Warner]

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