Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new hash algorithm for Git

lwn.net

Post reply on HN
Print view View original

51–60 of 240 posts

Re: A new hash algorithm for Git

#51

Post by patrec »

GlitchMr wrote: post #48
patrec wrote: post #43

Earlier quoted context omitted.

I supposed you are advocating two distinct Merkle trees? Because otherwise the prefixes will change anyway. But the only reason this would be attractive is because then people could keep using the existing prefixes to refer to the whole commit. But of course doing this would be insecure. So for this to make any sense at all, people would need to make good choices on when to use an insecure prefix and when to use the…

To be fair, the prefix problem would exist no matter what hash function would you pick. GitHub displays 7 characters of a hash, giving 28 bits. You could very quickly generate collisions with birthday attack in pretty much no time. Prefixes are always going to be insecure because they are so short. In fact, https://github.com/bradfitz/gitbrute exists.

Correct, but backwards compatibility does make a difference here, as in: there are surely quite a few cases where it would not be attractive to use a shortened hash if git hashes are changed incompatibly anyway, but where it will be attractive to use the shortened hash, because that keeps an existing setup working as before.

Also: the prefixing increases the length of the hash (and hence the desire to shorten it) without adding any security.

Re: A new hash algorithm for Git

#53

Post by ascar »

GlitchMr wrote: post #24

I wonder if it would make sense to use `concat(sha1, sha256)` hash algorithm. This wouldn't change the prefixes while improving strength of an algorithm (by including SHA256 in a hash).

I'm probably missing something, but isn't it simpler to just make both available separately and allow users to still reference by sha1, if they want to, while sha256 can be used for collision detection by git operations internally?

Re: A new hash algorithm for Git

#54

Post by rocqua »

tialaramex wrote: post #20
glandium wrote: post #4

Earlier quoted context omitted.

> How long until a specified length preimage attack can break bittorrent blocks? Even MD5 still doesn't have a known preimage attack, so... many many years?

To be fair for MD5 there is a known attack, it's just impractical. It's a real attack though because the whole point of a crypto hash is that you'd have to brute force it to win, and the paper shows a slightly quicker way because MD5 is broken. It's just not quick enough that you could actually do it. Oh wait, perhaps you actually meant preimage as you said rather than I assumed second preimage. OK yes, that isn't ev…

I think OP meant 'viable' pre-image attack. Not just an attack that is better than brute force.

Re: A new hash algorithm for Git

#55

Post by rocqua »

GlitchMr wrote: post #24

I wonder if it would make sense to use `concat(sha1, sha256)` hash algorithm. This wouldn't change the prefixes while improving strength of an algorithm (by including SHA256 in a hash).

There is a downside that this would mean commit-prefixes remain sensitive to collisions. Hence anyone checking out a commit by a hash-prefix would still be vulnerable.

Not a dealbreaker by far, but still a slight mark against this solution.

Re: A new hash algorithm for Git

#56

Post by GlitchMr »

patrec wrote: post #51
GlitchMr wrote: post #48

Earlier quoted context omitted.

To be fair, the prefix problem would exist no matter what hash function would you pick. GitHub displays 7 characters of a hash, giving 28 bits. You could very quickly generate collisions with birthday attack in pretty much no time. Prefixes are always going to be insecure because they are so short. In fact, https://github.com/bradfitz/gitbrute exists.

Correct, but backwards compatibility does make a difference here, as in: there are surely quite a few cases where it would not be attractive to use a shortened hash if git hashes are changed incompatibly anyway, but where it will be attractive to use the shortened hash, because that keeps an existing setup working as before. Also: the prefixing increases the length of the hash (and hence the desire to shorten it) wit…

Yeah, kinda agreeing here. The hash length will need to be increased anyway, but concatenation of SHA1 and SHA256 will be 104 bytes in total when displayed (40 + 64), which is a lot.

It may be a better to display SHA-256 commit hashes, but accept SHA-1 hash prefixes for old commits. It may be confusing for git to accept hashes that aren't visible in `git log`, but it's probably for the better.

Re: A new hash algorithm for Git

#57

Post by patrec »

ascar wrote: post #53
GlitchMr wrote: post #24

I wonder if it would make sense to use `concat(sha1, sha256)` hash algorithm. This wouldn't change the prefixes while improving strength of an algorithm (by including SHA256 in a hash).

I'm probably missing something, but isn't it simpler to just make both available separately and allow users to still reference by sha1, if they want to, while sha256 can be used for collision detection by git operations internally?

Correct, and I think this is what they are doing -- you can optionally keep the sha1s around.

Re: A new hash algorithm for Git

#58

Post by wolfgke »

nullc wrote: post #30
nnx wrote: post #11

Surprising they didn't go with Blake3 instead since it has much higher performance and Git's performance-oriented ethos.

> Git's performance-oriented ethos Than sha256 will likely be preferable in the long run: It's faster with SHA-NI than blake3. If you're not developing on a system with sha-ni, get with the program. Zen2 is freeking awesome. :)

> Zen2 is freeking awesome. :)

SHA-NI was introduced with the Intel Goldmont microarchitecture.

Re: A new hash algorithm for Git

#59

Post by sandGorgon »

freddie_mercury wrote: post #7
sandGorgon wrote: post #3

does anyone know if github/bitbucket support it today ?

Why would they support it? The article clearly states it is nowhere close to being useful yet. It is untested, unstable code that can only write to repositories and not read them. "Much of the work to implement the SHA‑256 transition has been done, but it remains in a relatively unstable state and most of it is not even being actively tested yet. In mid-January, carlson posted the first part of this transition code,…

actually - i might have worded it confusingly.

For smaller projects (like my own), can i move to sha-256 with no expectation of backward compatibility today ?

Post reply on HN