From: H. Peter Anvin Date: Tue, 12 Apr 2016 23:06:53 GMT Subject: Re: Migrating away from SHA-1? Message-ID: <570D7F8D.9050406@zytor.com> In-Reply-To: On 04/12/16 16:00, Stefan Beller wrote: > On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin 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 , 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