Re: [PATCH v2 5/6] doc hash-function-transition: move rationale upwards
From: Junio C Hamano <hidden>
Date: 2021-02-02 19:55:46
"Thomas Ackermann via GitGitGadget" [off-list ref] writes:
From: Thomas Ackermann <redacted> Move rationale for new hash function to beginning of document so that it appears before the concrete move to SHA-256 is described. Remove details about SHA-1 weaknesses. Instead add references to the details of how the new hash function was chosen. Signed-off-by: Thomas Ackermann <redacted> --- .../technical/hash-function-transition.txt | 62 +++++-------------- 1 file changed, 16 insertions(+), 46 deletions(-)
Hmph, this might turn out to be a bit more controversial than its worth. I'd summon/cc a few people from the original discussion.
-Over time some flaws in SHA-1 have been discovered by security -researchers. On 23 February 2017 the SHAttered attack -(https://shattered.io) demonstrated a practical SHA-1 hash collision. +Over time some flaws in SHA-1 have been discovered by security researchers. Git v2.13.0 and later subsequently moved to a hardened SHA-1 -implementation by default, which isn't vulnerable to the SHAttered -attack. +implementation by default, but SHA-1 is still believed to be weak.
Even if we've hardended against one particular form of attack, we still have incentive to switch away from SHA-1. It is unclear why we just do not add ", but ..." to the original and instead remove the half-sentence about sha1dc.
quoted hunk
@@ -57,6 +47,19 @@ SHA-1 still possesses the other properties such as fast object lookup and safe error checking, but other hash functions are equally suitable that are believed to be cryptographically secure. +Choice of Hash +-------------- +There were several contenders for a successor hash to SHA-1, including +SHA-256, SHA-512/256, SHA-256x16, K12, and BLAKE2bp-256. + +In late 2018 the project picked SHA-256 as its successor hash. + +See 0ed8d8da374 (doc hash-function-transition: pick SHA-256 as +NewHash, 2018-08-04) and numerous mailing list threads at the time, +particularly the one starting at +https://lore.kernel.org/git/20180609224913.GC38834@genre.crustytoothpaste.net/ +for more information.
I personally think this is referring too much to external document for typical readers, and lost too much relative to the original. I do not mind losing the history of how we reached the conclusion that SHA-1 is no longer viable at all, but I am not sure if we want to lose the list of criteria we used when choosing (i.e. stronger than SHA-1, 256-bit, quality implementations, etc.) from this section.
-The hash to replace this hardened SHA-1 should be stronger than SHA-1 -was: we would like it to be trustworthy and useful in practice for at -least 10 years. - -Some other relevant properties: - -1. A 256-bit hash (long enough to match common security practice; not - excessively long to hurt performance and disk usage). - -2. High quality implementations should be widely available (e.g., in - OpenSSL and Apple CommonCrypto). - -3. The hash function's properties should match Git's needs (e.g. Git - requires collision and 2nd preimage resistance and does not require - length extension resistance). - -4. As a tiebreaker, the hash should be fast to compute (fortunately - many contenders are faster than SHA-1).