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

[Junio C Hamano <gitster@pobox.com>]

"Thomas Ackermann via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Thomas Ackermann <th.acker@arcor.de>
>
> 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@arcor.de>
> ---
>  .../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@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).