review of Projects/replay_cache_collision_avoidance, ending Jan. 12

Jeffrey Hutzelman jhutz at
Fri Jan 9 16:49:37 EST 2009

--On Wednesday, December 31, 2008 06:03:52 AM -0500 Sam Hartman 
<hartmans at> 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 mailing list