Re: Migrating away from SHA-1?

[Stefan Beller <sbeller@google.com>]

On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> OK, I'm going to open this can of worms...
>
> At what point do we migrate from SHA-1?  At this point the cryptoanalysis of
> SHA-1 is most likely a matter of time.

And I thought the cryptographic properties of SHA1 did not matter for
Gits use case.
We could employ broken md5 or such as well.
( see http://stackoverflow.com/questions/28792784/why-does-git-use-a-cryptographic-hash-function
)
That is because security goes on top via gpg signing of tags/commits.

I am not sure if anyone came up with
a counter argument to Linus reasoning there?

>
> For existing repositories we will need to have a migration mechanism. Since
> we can't modify objects without completely invalidating the cryptographic
> properties, what I would suggest is that we leave the existing objects as
> is, with a persistent lookup table from SHA-1 to <new hash>, and have that
> lookup table signed (e.g. GPG) by the person responsible for converting the
> repository.  This freezes the cryptographic status of the existing SHA-1
> objects at the time the conversion happens.  This is a very good reason to
> do this before SHA-1 is actually broken  In contrast. SHA-2 has been
> surprisingly resistant to cryptoanalysis, to the point that SHA-3 was
> motivated by performance and the desire to have a well-tested function based
> on entirely different principles should a generic attack against the common
> structure of MD5/SHA-1/SHA-2 would ever be found.

When the kernel moved from BitKeeper to Git, all history was thrown away,
and started from scratch. The old history could be grafted into the
repo, if you cared
though.

I'd propose to go that route again and use a sha1 graft history which
you can get optionally
put into your new history for convenience.

Stefan

>
>         -hpa
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html