review of Projects/replay_cache_collision_avoidance,	ending	Jan. 12
    Jeffrey Hutzelman 
    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
mailing list