Re: Migrating away from SHA-1?

[David Turner <dturner@twopensource.com>]

On Tue, 2016-04-12 at 16:00 -0700, 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?

Here's my reasoning as to why the security of SHA1 matters:

If SHA-1 is not broken, and someone hacks into e.g. kernel.org, they
can't replace an arbitrary blob with anything else without being
detected by git's automatic checksumming of objects.  GPG is necessary
here because otherwise the HEAD commit could be changed (to point to a
new tree that points to the new blob). 

If SHA-1 is broken (in certain ways), someone *can* replace an
arbitrary blob.  GPG does not help in this case, because the signature
is over the commit object (which points to a tree, which eventually
points to the blob), and the commit hasn't changed.  So the GPG
signature will still verify.

It would be possible, of course, to GPG-sign the entire commit's
transitive data (rather than just the SHA1s of same).  But as far as I
know, that is not ever what is done.

This is the argument for migration to a more-secure hash.