SHA-1 and changeset signatures

Chad Netzer cnetzer at
Fri Aug 26 16:37:32 CDT 2005

On Fri, 2005-08-26 at 09:59 -0700, Eric Hopper wrote:

> Generating SHA-1 collisions isn't impractical.  I believe there's a
> website that will generate them for you.

I'd like to see that link, as I'm more than a bit skeptical.  Sure,
maybe there is a listing of known hashes that collide, but to "generate"
them as you wait?  Do I have to wait for weeks, months, or years?

In any case, the 'break' of SHA-1, seems to state that I can generate
two pieces of input that generate the same hash value, faster than a
brute-force search.  It does NOT state that, if I'm given a hash value,
I can find some input that generates that same hash faster than a brute
force search.  That is a much harder proposition, and probably more
relevant to the hash's use in Mercurial.

The 'break' might allow someone using SHA-1 to repudiate their signature
(where they have some control of the original hash input), or something
similar.  But probably NOT allow them to replace an existing changeset,
with a different or malicious changeset, while keeping the same hash.
At best, it'd probably have to be the same person checking in both the
original and replacement code, in which case there already issues about
whose code you trust enough to run.

So, the sky has not yet fallen; but it may be time to talk about
migration, simply to reduce pain at some future time.  But I doubt it
can be seen as a high priority.

I think migrating away could be as easy as using a "better" hash on new
repositories, and keeping SHA-1 around for existing repositories, with a
tool to upgrade.


More information about the Mercurial mailing list