threads / patch / 48156

patch, 2 partsdoc hash-function-transition: minor & major clarifications

Subject: [PATCH 0/2] doc hash-function-transition: minor & major clarifications

## tl;dr

5 messages between Mar 26, 2018 and Mar 26, 2018. Diffs are folded; open one to read it.

replies: 4people: 3as markdown or json

Ævar Arnfjörð Bjarmason· Mar 26, 2018, 18:27 UTC · lore

Having read through the hash-function-transition.txt again, a couple of things jumped out at me:

Ævar Arnfjörð Bjarmason (2):
  doc hash-function-transition: clarify how older gits die on NewHash

We weren't accurately describing how "git status" would die on NewHash repos on new versions.

  doc hash-function-transition: clarify what SHAttered means

I don't think we had a good summary of how SHA-1 vulnerabilities overlap with concerns Git has, now that we've moved to the hardened SHA-1.

I may very well have gotten this new summary subtly wrong though. So please review.

 .../technical/hash-function-transition.txt    | 40 +++++++++++++++----
 1 file changed, 32 insertions(+), 8 deletions(-)

-- 
2.16.2.804.g6dcf76e118

Ævar Arnfjörð Bjarmason· Mar 26, 2018, 18:27 UTC · re: Ævar Arnfjörð Bjarmason · lore

[PATCH 1/2] doc hash-function-transition: clarify how older gits die on NewHash

Change the "Repository format extension" to accurately describe what happens with different versions of Git when they encounter NewHash repositories, instead of only saying what happens with versions v2.7.0 and later.

See ab9cb76f66 ("Repository format version check.", 2005-11-25) and 00a09d57eb ("introduce "extensions" form of core.repositoryformatversion", 2015-06-23) for the relevant changes to the setup code where these variables are checked.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 Documentation/technical/hash-function-transition.txt | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

Show changes to Documentation/technical/hash-function-transition.txt +8 −3

diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt
index 417ba491d0..34396f13ec 100644
--- a/Documentation/technical/hash-function-transition.txt
+++ b/Documentation/technical/hash-function-transition.txt
@@ -116,10 +116,15 @@ Documentation/technical/repository-version.txt) with extensions
 		objectFormat = newhash
 		compatObjectFormat = sha1
 
-Specifying a repository format extension ensures that versions of Git
-not aware of NewHash do not try to operate on these repositories,
-instead producing an error message:
+The combination of setting `core.repositoryFormatVersion=1` and
+populating `extensions.*` ensures that all versions of Git later than
+`v0.99.9l` will die instead of trying to operate on the NewHash
+repository, instead producing an error message.
 
+	# Between v0.99.9l and v2.7.0
+	$ git status
+	fatal: Expected git repo version <= 0, found 1
+	# After v2.7.0
 	$ git status
 	fatal: unknown repository extensions found:
 		objectformat

-- 
2.16.2.804.g6dcf76e118

Ævar Arnfjörð Bjarmason· Mar 26, 2018, 18:27 UTC · re: Ævar Arnfjörð Bjarmason · lore

[PATCH 2/2] doc hash-function-transition: clarify what SHAttered means

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.

I may have gotten some of the nuances wrong, but as far as I know this new text accurately summarizes the current situation with SHA-1 in git. I.e. git doesn't really use SHA-1 anymore, it uses Hardened-SHA-1 (they just so happen to produce the same outputs 99.99999999999...% of the time).

Thus the previous text was incorrect in asserting that:

    [...]As a result [of SHAttered], SHA-1 cannot be considered
    cryptographically secure any more[...]

That's not the case. We have a mitigation against SHAttered, *however* we consider it prudent to move to work towards a NewHash should future vulnerabilities in either SHA-1 or Hardened-SHA-1 emerge.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 .../technical/hash-function-transition.txt    | 29 +++++++++++++++----
 1 file changed, 24 insertions(+), 5 deletions(-)

Show changes to Documentation/technical/hash-function-transition.txt +24 −5

diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt
index 34396f13ec..34b8b83a34 100644
--- a/Documentation/technical/hash-function-transition.txt
+++ b/Documentation/technical/hash-function-transition.txt
@@ -28,11 +28,30 @@ advantages:
   address stored content.
 
 Over time some flaws in SHA-1 have been discovered by security
-researchers. https://shattered.io demonstrated a practical SHA-1 hash
-collision. As a result, SHA-1 cannot be considered cryptographically
-secure any more. This impacts the communication of hash values because
-we cannot trust that a given hash value represents the known good
-version of content that the speaker intended.
+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
+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.
 
 SHA-1 still possesses the other properties such as fast object lookup
 and safe error checking, but other hash functions are equally suitable

-- 
2.16.2.804.g6dcf76e118

Eric Sunshine· Mar 26, 2018, 19:03 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: [PATCH 2/2] doc hash-function-transition: clarify what SHAttered means

On Mon, Mar 26, 2018 at 2:27 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 31 quoted lines

> 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 <avarab@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.

Stefan Beller· Mar 26, 2018, 18:35 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: [PATCH 0/2] doc hash-function-transition: minor & major clarifications

On Mon, Mar 26, 2018 at 11:27 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

> Having read through the hash-function-transition.txt again, a couple
> of things jumped out at me:

> Ævar Arnfjörð Bjarmason (2):
>    doc hash-function-transition: clarify how older gits die on NewHash

> We weren't accurately describing how "git status" would die on NewHash
> repos on new versions.

>    doc hash-function-transition: clarify what SHAttered means

> I don't think we had a good summary of how SHA-1 vulnerabilities
> overlap with concerns Git has, now that we've moved to the hardened
> SHA-1.

> I may very well have gotten this new summary subtly wrong though. So
> please review.

>   .../technical/hash-function-transition.txt    | 40 +++++++++++++++----
>   1 file changed, 32 insertions(+), 8 deletions(-)

Both patches look good to me.

Stefan