Re: Migrating away from SHA-1?

From: David Turner <dturner@twopensource.com>
Date: Apr 12, 2016, 23:15 UTC
Message-ID: <1460502934.5540.71.camel@twopensource.com>
In-Reply-To: <CAGZ79kaUN0G7i0GNZgWU7ZzJvWY=k=Rc6tqWvJsTu8gcRhP5bA@mail.gmail.com>

On Tue, 2016-04-12 at 16:00 -0700, Stefan Beller wrote:

Show 18 quoted lines

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