review of Projects/replay_cache_collision_avoidance, ending Jan. 12

Jeffrey Hutzelman jhutz at
Fri Jan 9 16:57:39 EST 2009

--On Friday, January 09, 2009 04:49:37 PM -0500 Jeffrey Hutzelman 
<jhutz at> wrote:

> --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

Oops; I meant to delete this, rather than send it.  See my more verbose 
reply to Greg

More information about the krbdev mailing list