review of Projects/replay_cache_collision_avoidance, ending Jan. 12
jhutz at cmu.edu
Fri Jan 9 16:49:37 EST 2009
--On Wednesday, December 31, 2008 06:03:52 AM -0500 Sam Hartman
<hartmans at mit.edu> wrote:
> I was writing up a message to disagree with Greg; in particular I
> think that you only need to pay the complexity cost of algorithm
> agility when you support the second algorithm.
> However I considered his argument that the hash is not security
> sensitive and agree. I'd like to expand on that a bit because I get
> nervous when people claim that a hash is not security sensitive
> without more detail. We depend on the hash to hash identical inputs
> to the same output; this seems quite safe as it is a function. If an
> attacker can cause non-identical inputs to collide,the worst they can
> get is false positives. So, I agree the hash is not likely to need to
> change for security reasons.
OK; I find this argument reasonably persuasive.
Greg also makes the argument that there is a general extensibility
mechanism in place which could reasonably be used to indicate a change in
hash algorithm or in the data being hashed, and that given such a mechanism
More information about the krbdev