git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
Jan 31, 2021, 20:37 UTC
Message-ID
<87r1m0onbg.fsf@evledraar.gmail.com>
In-Reply-To
<2cdb0f8e2edc4416c5dfb88722aa05be35afba7d.1612093734.git.gitgitgadget@gmail.com>
On Sun, Jan 31 2021, Thomas Ackermann via GitGitGadget wrote:
Show 29 quoted lines
> 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.

Show 63 quoted lines
> +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
     ---------------
Previous: Ævar Arnfjörð BjarmasonNext: Thomas Ackermann via GitGitGadget
Message 4 of 25 in “Re: [PATCH 1/6] doc hash-function-transition: fix asciidoc output”
  1. Ævar Arnfjörð BjarmasonJan 31, 2021
  2. Ævar Arnfjörð BjarmasonJan 31, 2021
  3. Ævar Arnfjörð BjarmasonJan 31, 2021
  4. Ævar Arnfjörð BjarmasonJan 31, 2021
  5. 0/6 doc: improvements for hash-function-transitionThomas Ackermann via GitGitGadget, Feb 2, 2021
  6. 5/6 doc hash-function-transition: move rationale upwardsThomas Ackermann via GitGitGadget, Feb 2, 2021
  7. Junio C HamanoFeb 2, 2021
  8. brian m. carlsonFeb 2, 2021
  9. 6/6 doc: use https linksThomas Ackermann via GitGitGadget, Feb 2, 2021
  10. 4/6 doc hash-function-transition: fix incomplete sentenceThomas Ackermann via GitGitGadget, Feb 2, 2021
  11. 1/6 doc hash-function-transition: fix asciidoc outputThomas Ackermann via GitGitGadget, Feb 2, 2021
  12. 3/6 doc hash-function-transition: use upper case consistentlyThomas Ackermann via GitGitGadget, Feb 2, 2021
  13. 2/6 doc hash-function-transition: use SHA-1 and SHA-256 consistentlyThomas Ackermann via GitGitGadget, Feb 2, 2021
  14. Junio C HamanoFeb 2, 2021
  15. Junio C HamanoFeb 2, 2021
  16. Junio C HamanoFeb 2, 2021
  17. 0/6 doc: improvements for hash-function-transitionThomas Ackermann via GitGitGadget, Feb 5, 2021
  18. 6/6 doc: use https linksThomas Ackermann via GitGitGadget, Feb 5, 2021
  19. 4/6 doc hash-function-transition: fix incomplete sentenceThomas Ackermann via GitGitGadget, Feb 5, 2021
  20. 5/6 doc hash-function-transition: move rationale upwardsThomas Ackermann via GitGitGadget, Feb 5, 2021
  21. Ævar Arnfjörð BjarmasonFeb 5, 2021
  22. Junio C HamanoFeb 5, 2021
  23. 3/6 doc hash-function-transition: use upper case consistentlyThomas Ackermann via GitGitGadget, Feb 5, 2021
  24. 1/6 doc hash-function-transition: fix asciidoc outputThomas Ackermann via GitGitGadget, Feb 5, 2021
  25. 2/6 doc hash-function-transition: use SHA-1 and SHA-256 consistentlyThomas Ackermann via GitGitGadget, Feb 5, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.