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

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

On Fri, Feb 05 2021, Thomas Ackermann via GitGitGadget wrote:

> diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt
> index 5ff9ee027cff..0c4cb98cd4e9 100644
> --- a/Documentation/technical/hash-function-transition.txt
> +++ b/Documentation/technical/hash-function-transition.txt
> @@ -33,16 +33,9 @@ researchers. On 23 February 2017 the SHAttered attack
>  
>  Git v2.13.0 and later subsequently moved to a hardened SHA-1
>  implementation by default, which isn't vulnerable to the SHAttered
> -attack.
> +attack, but SHA-1 is still 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
> -happens to produce exactly the same output for all known inputs,
> -except two PDFs published by the SHAttered researchers, and the new
> -implementation (written by those researchers) claims to detect future
> -cryptanalytic collision attacks.
> -
> -Regardless, it's considered prudent to move past any variant of SHA-1
> +Thus it's considered prudent to move past any variant of SHA-1
>  to a new hash. There's no guarantee that future attacks on SHA-1 won't
>  be published in the future, and those attacks may not have viable
>  mitigations.
> @@ -57,6 +50,38 @@ 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 missed version 2 of this. I don't think it's an improvement to
completely remove the description of us using sha1collisiondetection by
default, i.e. effectively revert 5988eb631a3 (doc
hash-function-transition: clarify what SHAttered means, 2018-03-26)

I can see how my comment on v1 could have been read like that. FWIW I
didn't mean remove the whole thing, but that I don't think it adds much
value to our description of how we use SHA-1 to go into the level of
detail of mentioning several researchers by name, there's Wikipedia for
that.

I think what we should instead do is have some brief summary of the
vulnerabilities and how they're impacting git.

Maybe I'm barking up the wrong tree here, and what I'm describing should
be in a "man 5 gitsecurity" or something.

But anyway, I think it adds a lot of value to somewhere have not just
what amounts to "sha-1 sucks, see research papers", but to have some
brief human-readable summary of what the practical impact is on users.

In 2018 it was true that sha1collisiondetection was mitigating the known
attack in practice, and that's also true about this new attack[1] (maybe
there's others I missed ...).

Then there's the fact that we don't *just* rely on SHA-1, but e.g. the
"don't re-write objects we have already". So as a practical attack on
someone using git ...

Oh, and the attacks currently all seem to require file formats like JPEG
or PDF for anything practical, i.e. being able to spew in lots of
arbitrary data into some data segment, as opposed to e.g. creating a
program that compiles.

None of this is meant as some overall defense of SHA-1, just that most
of our users aren't security researchers, and will be helped by a
summary of how this system they're using using SHA-1, and having read
that it's "broken" or "believed to be weak" translates to a threat to
them in practice.

1. https://eprint.iacr.org/2020/014.pdf