[tahoe-dev] Removing the dependency of immutable read caps on UEB computation
David-Sarah Hopwood
david-sarah at jacaranda.org
Wed Oct 7 00:50:01 PDT 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