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

121–130 of 240 posts

Re: A new hash algorithm for Git

#121

Post by vluft »

jayflux wrote: post #105
strenholme wrote: post #97

I’m already seeing a lot of discussion both here and over at LWN about which hash algorithm to use. The Git team made the right choice: SHA2-256 is the best choice here; it has been around for 19 years and is still secure, in the sense that there are no known attacks against it. Both BLAKE[2/3] and SHA-3 (Keccak) have been around for 12 years and are both secure; just as BLAKE2 and BLAKE3 are faster reduced round var…

> BLAKE is faster when using software to perform the hash Is BLAKE 3 still faster than sha-256 when using the cpu speciliazed instructions? I think most modern desktop CPUs has built-in instructions for SHA256. I’m guessing when people compare BLAKE 3 to SHA 256 they’re comparing software to software, but this wouldn’t be the case in reality?

On my machine with sha extensions, blake3 is about 15% faster (single threaded in both cases) than sha256.

Re: A new hash algorithm for Git

#122

Post by abecedarius »

vluft wrote: post #121
jayflux wrote: post #105

Earlier quoted context omitted.

> BLAKE is faster when using software to perform the hash Is BLAKE 3 still faster than sha-256 when using the cpu speciliazed instructions? I think most modern desktop CPUs has built-in instructions for SHA256. I’m guessing when people compare BLAKE 3 to SHA 256 they’re comparing software to software, but this wouldn’t be the case in reality?

On my machine with sha extensions, blake3 is about 15% faster (single threaded in both cases) than sha256.

Also, Blake3 has some kind of advantage in parallelizability, iirc.

Re: A new hash algorithm for Git

#123

Post by microtherion »

kazinator wrote: post #114

> There is, of course, a way to unambiguously give a hash value in the new Git code, and they can even be mixed on the command line; this example comes from the transition document: git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256} > For a Git user interface this is relatively straightforward and concise No, it isn't. It's a complete and utter user interface clusterfuck. Just say no to this insanity.

Note the qualifier "for a Git user interface".

The average git command is along the lines of "git ph-nglui --mglw=nafh Cthulhu...R'lyeh -- wgah^nagl fhtagn"

Re: A new hash algorithm for Git

#124

Post by papreclip »

_verandaguy wrote: post #119
strenholme wrote: post #97

I’m already seeing a lot of discussion both here and over at LWN about which hash algorithm to use. The Git team made the right choice: SHA2-256 is the best choice here; it has been around for 19 years and is still secure, in the sense that there are no known attacks against it. Both BLAKE[2/3] and SHA-3 (Keccak) have been around for 12 years and are both secure; just as BLAKE2 and BLAKE3 are faster reduced round var…

Honest question: what are the use cases in Git where hash computation speed is a meaningful optimization?

less wasted computation means less global warming

Re: A new hash algorithm for Git

#125

Post by kazinator »

microtherion wrote: post #123
kazinator wrote: post #114

> There is, of course, a way to unambiguously give a hash value in the new Git code, and they can even be mixed on the command line; this example comes from the transition document: git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256} > For a Git user interface this is relatively straightforward and concise No, it isn't. It's a complete and utter user interface clusterfuck. Just say no to this insanity.

Note the qualifier "for a Git user interface". The average git command is along the lines of "git ph-nglui --mglw=nafh Cthulhu...R'lyeh -- wgah^nagl fhtagn"

That cute rhetoric will not fool anyone. Common git workflows use fairly succinct git commands:

  git diff
  git commit -p
  git rebase -i HEAD~3
The command quoted in my original comment is just this we strip away the SHA256 garbage:

  git log abac87a..f787cac
(Or maybe it is:

  git log abac87a^..f787cac^
I cannot guess whether the ^ operator still has the same meaning or whether it is part of this ^{sha...} notation.)

The hashes will typically be copy and pasted, so you type just the git log, .. and spaces.

The fixed parts of convoluted git syntax can be hidden behind shell functions and aliases. But notations for referencing objects are not fixed; they will end up as arguments.

Re: A new hash algorithm for Git

#126

Post by pdonis »

acidictadpole wrote: post #107
anaisbetts wrote: post #9

I don't understand the practical attack vector for breaking SHA1s in Git. Not only are objects checksummed by SHA1, they also encode the length . Finding a SHA1 collision is plausible, but finding a SHA1 collision that both lets you do something Nefarious, and is the length you need, seems really really unlikely

The author does seem to concede that hitting all the checkmarks in an attack on git would be pretty tricky: > An attacker would not just have to do that, though; this new version would have to contain the desired hostile code, still function as a working floppy driver, and not look like an obfuscated C code contest entry The whole idea is that they want to switch away before these things become likely. They are unlik…

> and not look like an obfuscated C code contest entry

The full quote here is even better:

"and not look like an obfuscated C code contest entry (at least not more than it already does)."

Re: A new hash algorithm for Git

#127

Post by ptomato »

abecedarius wrote: post #122
vluft wrote: post #121

Earlier quoted context omitted.

On my machine with sha extensions, blake3 is about 15% faster (single threaded in both cases) than sha256.

Also, Blake3 has some kind of advantage in parallelizability, iirc.

yeah, blake3 multi-threaded is about 11 times faster for me than sha256 single-threaded.

Re: A new hash algorithm for Git

#128

Post by mathnmusic »

zackmorris wrote: post #113

Summary of hashing function security in bits, for convenience: https://en.wikipedia.org/wiki/Secure_Hash_Algorithms Since collision resistance is roughly half the number of bits, it seems unconscionable to me that anything below 256 bit hashes even exist, because 64 bits is crackable but 128 bits effectively never will be. This was well-understood even in the 90s when MD5 and SHA were first published. Just thinking a…

Also relevant: Multihash is a format for self-describing hashes that helps with data portability and future-proofing: https://github.com/multiformats/multihash

Re: A new hash algorithm for Git

#129

Post by KMag »

strenholme wrote: post #97

I’m already seeing a lot of discussion both here and over at LWN about which hash algorithm to use. The Git team made the right choice: SHA2-256 is the best choice here; it has been around for 19 years and is still secure, in the sense that there are no known attacks against it. Both BLAKE[2/3] and SHA-3 (Keccak) have been around for 12 years and are both secure; just as BLAKE2 and BLAKE3 are faster reduced round var…

SHA-256 is probably the right choice, but I don't think it's as obvious as you suggest, given SHA-512/256.

SHA-512/256 is a standard peer-reviewed and well-studied way to run SHA-512 with a different initial state and then truncate output to 256 bits.

This is heavy bikeshedding, but SHA-512/256 would be a more conservative choice than SHA-256. Under standard assumptions, SHA-256 is no weaker than SHA-512. The structure is extremely similar to SHA-256, but a collision on intermediate state requires a collision on all 512 bits of state instead of 256.

On most 64-bit CPUs without dedicated hash instructions, SHA-512/256 is faster for messages longer than a couple of blocks, due to processing blocks twice as large in fewer than twice as many operations.

Currently, the latest server and laptop CPUs have SHA-256 hardware acceleration but not SHA-512 acceleration. I'm not sure how many phone CPUs support sha256 but not ARMv8.2-SHA extensions (SHA-512). If it weren't for this difference in hardware acceleration, there would be few reasons to use SHA-256.

That being said, the current difference in hardware acceleration support probably makes SHA-256 the right choice here.

Re: A new hash algorithm for Git

#130

Post by scarejunba »

kazinator wrote: post #114

> There is, of course, a way to unambiguously give a hash value in the new Git code, and they can even be mixed on the command line; this example comes from the transition document: git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256} > For a Git user interface this is relatively straightforward and concise No, it isn't. It's a complete and utter user interface clusterfuck. Just say no to this insanity.

Perhaps suggest an alternative? It may help understand why this was chosen.
Post reply on HN