Re: Migrating away from SHA-1?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]