| Message ID | 711a37969b6f51922c12555534d9c4634cde6021.1612282749.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | doc: improvements for hash-function-transition | expand |
"Thomas Ackermann via GitGitGadget" <gitgitgadget@gmail.com> writes: > From: Thomas Ackermann <th.acker@arcor.de> > > Move rationale for new hash function to beginning of document > so that it appears before the concrete move to SHA-256 is described. > > Remove details about SHA-1 weaknesses. Instead add references > to the details of how the new hash function was chosen. > > Signed-off-by: Thomas Ackermann <th.acker@arcor.de> > --- > .../technical/hash-function-transition.txt | 62 +++++-------------- > 1 file changed, 16 insertions(+), 46 deletions(-) Hmph, this might turn out to be a bit more controversial than its worth. I'd summon/cc a few people from the original discussion. > -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. > +Over time some flaws in SHA-1 have been discovered by security researchers. > > 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, but SHA-1 is still believed to be weak. Even if we've hardended against one particular form of attack, we still have incentive to switch away from SHA-1. It is unclear why we just do not add ", but ..." to the original and instead remove the half-sentence about sha1dc. > @@ -57,6 +47,19 @@ 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. > > +Choice of Hash > +-------------- > +There were several contenders for a successor hash to SHA-1, including > +SHA-256, SHA-512/256, SHA-256x16, K12, and BLAKE2bp-256. > + > +In late 2018 the project picked SHA-256 as its successor hash. > + > +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. I personally think this is referring too much to external document for typical readers, and lost too much relative to the original. I do not mind losing the history of how we reached the conclusion that SHA-1 is no longer viable at all, but I am not sure if we want to lose the list of criteria we used when choosing (i.e. stronger than SHA-1, 256-bit, quality implementations, etc.) from this section. > -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).
On 2021-02-02 at 19:54:20, Junio C Hamano wrote: > "Thomas Ackermann via GitGitGadget" <gitgitgadget@gmail.com> writes: > > -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. > > +Over time some flaws in SHA-1 have been discovered by security researchers. > > > > 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, but SHA-1 is still believed to be weak. > > Even if we've hardended against one particular form of attack, we > still have incentive to switch away from SHA-1. It is unclear why > we just do not add ", but ..." to the original and instead remove > the half-sentence about sha1dc. I think we should keep the original statement about the attack since it's relevant to why we want to change. I also think we should say, "but SHA-1 is still weak". Saying "is still believed to be" implies doubt or uncertainty, and the fact that multiple collisions have been performed and can be trivially verified should remove any doubt. Even if SHA-1 were still perfectly secure (which it is not), it can only by design provide an 80-bit security level, which is inadequate by today's standards. > > @@ -57,6 +47,19 @@ 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. > > > > +Choice of Hash > > +-------------- > > +There were several contenders for a successor hash to SHA-1, including > > +SHA-256, SHA-512/256, SHA-256x16, K12, and BLAKE2bp-256. > > + > > +In late 2018 the project picked SHA-256 as its successor hash. > > + > > +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. > > I personally think this is referring too much to external document > for typical readers, and lost too much relative to the original. I > do not mind losing the history of how we reached the conclusion that > SHA-1 is no longer viable at all, but I am not sure if we want to > lose the list of criteria we used when choosing (i.e. stronger than > SHA-1, 256-bit, quality implementations, etc.) from this section. I don't have a problem including this and in fact I think it might be valuable, but I think we should keep the below data as well. > > -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). I'd prefer to keep the original criteria here, because I think it's useful to document what they were for why we'd want to change. For example, we occasionally get random users asking why we didn't pick a hash with length extension resistance or why we didn't pick SHA-3. The fact that we don't need length extension attack resistance and that most non-Linux crypto libraries provide an extremely limited set of crypto primitives are essential to our decision. I think if SHA-3-256 had been more widely available, it would have been the winning candidate.
diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt index 86b09ea0f21..475f2f501a6 100644 --- a/Documentation/technical/hash-function-transition.txt +++ b/Documentation/technical/hash-function-transition.txt @@ -27,22 +27,12 @@ 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 -(https://shattered.io) demonstrated a practical SHA-1 hash collision. +Over time some flaws in SHA-1 have been discovered by security researchers. 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, 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 -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 +47,19 @@ 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. +Choice of Hash +-------------- +There were several contenders for a successor hash to SHA-1, including +SHA-256, SHA-512/256, SHA-256x16, K12, and BLAKE2bp-256. + +In late 2018 the project picked SHA-256 as its successor hash. + +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. + Goals ----- 1. The transition to SHA-256 can be done one local repository at a time. @@ -601,39 +604,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. - Transition plan --------------- Some initial steps can be implemented independently of one another: