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

21–30 of 240 posts

Re: A new hash algorithm for Git

#21

Post by Ayesh »

nnx wrote: post #11

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

Linux also has the ethos to choose boring technology. SHA2 has been here for so long and battle tested. For the majority of us, it is the natural choice. I'm not implying anything negative about SHA3/Blake/Keccak.

Re: A new hash algorithm for Git

#22

Post by dchest »

nnx wrote: post #11

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

BLAKE3 was released a month ago! The decision for new hash in git was made about two years ago. BLAKE2 was considered, though.

SHA-256 is fine. The biggest problem is switching to it...

Re: A new hash algorithm for Git

#25

Post by dchest »

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).

Something to remember about the security of concatenated hashes: https://crypto.stackexchange.com/a/63543/291

Re: A new hash algorithm for Git

#26

Post by GlitchMr »

dchest wrote: post #25
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).

Something to remember about the security of concatenated hashes: https://crypto.stackexchange.com/a/63543/291

I'm well aware concatenation wouldn't necessarily improve the strength. However, the idea is, even if SHA-1 was hopelessly broken. CONCAT(SHA1(x), SHA256(x)) would be at least as strong as SHA-256 (where "at least" means it may have the same strength).

Re: A new hash algorithm for Git

#27

Post by [deleted] »

tcharlton wrote: post #5

I can't find documentation for the command in the article: git convert-repo --to-hash=sha-256 --frobnicate-blobs --climb-subtrees \ --liability-waiver=none --use-shovels --carbon-offsets Surely some of those options aren't real...

[deleted]

Re: A new hash algorithm for Git

#28

Post by HereBeBeasties »

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

You're assuming that 100% of the source code matters, but most source code has comments. Some has a lot of comments (boilerplate headers). Delete all the comments and superfluous whitespace, add nefarious code, put in a comment in the remaining bytes for the sole purpose of causing a hash collision (likely plenty of bytes to play with).

Re: A new hash algorithm for Git

#29

Post by est31 »

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 shattered collision attack featured two pdfs with the same sha1 and wait for it, the same length. Also note that even with normal sha1, the length is hashed into the final sha1 hash already, that's what the merkle damgard scheme is about. You can read about it on Wikipedia.

Reusing the precise collision from the shattered attack is made impossible by initializing the state with anything other than the prefix from the shattered attack. But the cost for mounting such an attack yourself is only 11k USD. However, as git uses the sha1collisiondetection library, such an attack would be detected by current git. Thus, this library is a much better protection than the length encoding.

Re: A new hash algorithm for Git

#30

Post by nullc »

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. :)

Post reply on HN