Re: Migrating away from SHA-1?

["H. Peter Anvin" <hpa@zytor.com>]

On 04/12/16 16:00, Stefan Beller wrote:
> 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?
>

Not true, because what we are signing is a chain of SHA-1s; the 
signature is meaningless unless the integrity of the hash chain is 
inviolate.

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

That was done more for legal reasons than anything else, as far as I 
understand.  The userbase of git today is also much, much larger than 
the userbase for BK ever was.

	-hpa