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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Sun, Jan 31 2021, Thomas Ackermann via GitGitGadget wrote:

> diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt
> index dc0c4976a62..c9b57a125e2 100644
> --- a/Documentation/technical/hash-function-transition.txt
> +++ b/Documentation/technical/hash-function-transition.txt
> @@ -27,13 +27,17 @@ advantages:
>    methods have a short reliable string that can be used to reliably
>    address stored content.
>  
> -Over time some flaws in SHA-1 have been discovered by security
> -researchers. On 23 February 2017 the SHAttered attack
> +Over time some flaws in SHA-1 have been discovered by security researchers.
> +In early 2005, around the time that Git was written, Xiaoyun Wang,
> +Yiqun Lisa Yin, and Hongbo Yu announced an attack finding SHA-1
> +collisions in 2^69 operations. In August they published details.
> +Luckily, no practical demonstrations of a collision in full SHA-1 were
> +published until 10 years later: on 23 February 2017 the SHAttered attack
>  (https://shattered.io) demonstrated a practical SHA-1 hash collision.
>  
>  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 that mitigates the SHAttered attack, but
> +SHA-1 is still believed to be weak.
>  
>  Thus Git has in effect already migrated to a new hash that isn't SHA-1
>  and doesn't share its vulnerabilities, its new hash function just
> @@ -57,6 +61,29 @@ 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.

I don't think this is an improvement, why does someone trying to learn
about Git's SHA-256 transition care about early SHA-1 flaws that didn't
prompt the transition.

I'm probably biased since the current intro is mine from 5988eb631a3
(doc hash-function-transition: clarify what SHAttered means,
2018-03-26), but this really feels too much like going into the weeds.

I think the document would be improved by just removing the whole
mention of early 2005 and mentioning several researchers by name. I
think the current prose of "Over time some flaws in SHA-1 have been
discovered by security researchers" suffices, if people are curious
about SHA-1's vulnerability history there's plenty of good easily found
sources for that.

> +Choice of Hash
> +--------------
> +The hash to replace the 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).
> +
> +We choose SHA-256.
> +
>  Goals
>  -----
>  1. The transition to SHA-256 can be done one local repository at a time.
> @@ -601,39 +628,6 @@ example:
>  
>      git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256}
>  
> -Choice of Hash
> ---------------
> -In early 2005, around the time that Git was written, Xiaoyun Wang,
> -Yiqun Lisa Yin, and Hongbo Yu announced an attack finding SHA-1
> -collisions in 2^69 operations. In August they published details.
> -Luckily, no practical demonstrations of a collision in full SHA-1 were
> -published until 10 years later, in 2017.
> -
> -Git v2.13.0 and later subsequently moved to a hardened SHA-1
> -implementation by default that mitigates the SHAttered attack, but
> -SHA-1 is still believed to be weak.
> -
> -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).
> -
> -We choose SHA-256.
> -

Same here. We're going into the weeds about what hashes we didn't pick
before talking about what we're going to do with SHA-256? Much of that
wording is just historical, and pre-dates the SHA-256 pick. I think
something like this would be much better at this point:
    
    diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt
    index 6fd20ebbc25..a4222eb0a6c 100644
    --- a/Documentation/technical/hash-function-transition.txt
    +++ b/Documentation/technical/hash-function-transition.txt
    @@ -602,36 +602,17 @@ git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256}
     
     Choice of Hash
     --------------
    -In early 2005, around the time that Git was written, Xiaoyun Wang,
    -Yiqun Lisa Yin, and Hongbo Yu announced an attack finding SHA-1
    -collisions in 2^69 operations. In August they published details.
    -Luckily, no practical demonstrations of a collision in full SHA-1 were
    -published until 10 years later, in 2017.
     
    -Git v2.13.0 and later subsequently moved to a hardened SHA-1
    -implementation by default that mitigates the SHAttered attack, but
    -SHA-1 is still believed to be weak.
    -
    -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).
    +There were several contenders for a successor hash to SHA-1, including
    +SHA-256, SHA-512/256, SHA-256x16, K12, and BLAKE2bp-256.
     
    -4. As a tiebreaker, the hash should be fast to compute (fortunately
    -   many contenders are faster than SHA-1).
    +In late 2018 the project picked SHA-256 as its successor hash.
     
    -We choose SHA-256.
    +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.
     
     Transition plan
     ---------------