Thread (50 messages) 50 messages, 19 authors, 2017-10-02

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

From: Mike Hommey <hidden>
Date: 2017-06-15 21:10:57

On Thu, Jun 15, 2017 at 09:01:45AM -0400, Jeff King wrote:
On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote:
quoted
On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote:
quoted
Footnote *1*: SHA-256, as all hash functions whose output is essentially
the entire internal state, are susceptible to a so-called "length
extension attack", where the hash of a secret+message can be used to
generate the hash of secret+message+piggyback without knowing the secret.
This is not the case for Git: only visible data are hashed. The type of
attacks Git has to worry about is very different from the length extension
attacks, and it is highly unlikely that that weakness of SHA-256 leads to,
say, a collision attack.
What do the experts think or SHA512/256, which completely removes the
concerns over length extension attack? (which I'd argue is better than
sweeping them under the carpet)
I don't think it's sweeping them under the carpet. Git does not use the
hash as a MAC, so length extension attacks aren't a thing (and even if
we later wanted to use the same algorithm as a MAC, the HMAC
construction is a well-studied technique for dealing with it).
AIUI, length extension does make brute force collision attacks (which,
really Shattered was) cheaper by allowing one to create the collision
with a small message and extend it later.

This might not be a credible thread against git, but if we go by that
standard, post-shattered Sha-1 is still fine for git. As a matter of
fact, MD5 would also be fine: there is still, to this day, no preimage
attack against them.

Mike
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help