"Thomas Ackermann via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Thomas Ackermann <th.acker@xxxxxxxx> > > 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 <th.acker@xxxxxxxx> > --- > .../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. > @@ -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@xxxxxxxxxxxxxxxxxxxxxxxxxx/ > +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).
