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