On Mon, Mar 26, 2018 at 2:27 PM, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > Attempt to clarify what the SHAttered attack means in practice for > Git. The previous version of the text made no mention whatsoever of > Git already having a mitigation for this specific attack, which the > SHAttered researchers claim will detect cryptanalytic collision > attacks. > [...] > Signed-off-by: Ævar Arnfjörð Bjarmason <ava...@gmail.com> > --- > diff --git a/Documentation/technical/hash-function-transition.txt > b/Documentation/technical/hash-function-transition.txt > @@ -28,11 +28,30 @@ advantages: > 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. > + > +Git v2.13.0 and later subsequently moved to a hardened SHA-1 > +implementation by default, which isn't vulnerable to the SHAttered > +attack. > + > +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 > +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. > + > +If SHA-1 and its variants were to be truly broken Git's hash function
s/broken/&,/ > +could not be considered cryptographically secure any more. This would > +impact the communication of hash values because we could not trust > +that a given hash value represented the known good version of content > +that the speaker intended.
