[tahoe-dev] Removing the dependency of immutable read caps on UEB computation

David-Sarah Hopwood david-sarah at jacaranda.org
Wed Oct 7 07:50:01 UTC 2009


Some clarifications:

David-Sarah Hopwood wrote:
>> When [Elk Point] is used for mutable files, this collision-resistance for
>> EncK1, Dhash and V doesn't really buy you anything because even if those
>> values are fixed, the file contents can still vary. However, if a hash of the
>> plaintext (also of length m bits, say) is optionally included in the input
>> to hash_m, the same protocol can be used for immutable files, and still
>> obtains (n+t)/2 bits of collision resistance for the plaintext, from
>> the point of view of a read cap holder.

This plaintext hash should be either salted, or encrypted with the read key,
so that it does not allow guessing attacks.

> Incidentally, I previously said
> "I think it's desirable to continue to avoid relying on public key
> cryptography in the immutable file protocol."
> 
> However, using the mutable file protocol in the way described above,
> does not rely on public key cryptography for integrity of the plaintext
> as read by a read-cap holder. That is still only dependent on hashes,
> and on the symmetric cipher used to encrypt K1.

Note that integrity is not dependent on the security of the symmetric
cipher; only that it is implemented correctly, and is a deterministic
permutation for a given key.

> The public key crypto is
> relied on just to allow checking validity of a share without the read cap.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com




More information about the tahoe-dev mailing list