Re: [Monotone-devel] Hash collisions resiliency

[Richard Li]

Not 100% relevant, but Graydon posted about the general case in August 2004:

http://lists.gnu.org/archive/html/monotone-devel/2004-08/msg00142.html

" - if SHA-1 falls completely (trivial inversion), it is a small

  amount of work to switch monotone to a new algorithm. this is
  a simple fact of life when working with security software: it
  is an arms race. we will have to do the same when someone
  trivializes RSA as well (as will SSH, SSL, GPG...)


- content addressing has the wonderful property that you can
  recompute all existing object identifiers under a new hash,
  so history doesn't get lost if we do this. it just creates
  a communication barrier with old clients. we'll bump the
  protocol number and carry on."


It wouldn't be difficult (but possibly computationally expensive) to 
validate non-collision against a database (perhaps integrated with db 
check so it doesn't get run on commit, and add a --veryparanoid flag to 
db check).

Richard

address@hidden wrote:

> I have read the documentation on hash integrity, but it doesn't address
> my particular questions, which are:
>
>  Should there be a hash collision:
>
>    -- Would I care?
>
>    -- If I did care, how would I know that there had been a collision?
>
>    -- How would I continue to work with Monotone without changing any
>    source files in the collision case?  (Assume that they are immutable
>    binary files for the sake of the question)  
>
> Please understand that I do realise the improbability of a collision.  
>
>