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
