Re: [PATCH v2 5/6] doc hash-function-transition: move rationale upwards

> "Thomas Ackermann via GitGitGadget" <gitgitgadget@gmail.com> writes:
> > -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@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).