Surprising they didn't go with Blake3 instead since it has much higher performance and Git's performance-oriented ethos.
I'm waiting for Blake7.
A new hash algorithm for Git
31–40 of 240 posts
Re: A new hash algorithm for Git
#32I 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
This is pretty interesting and shows you shouldn't try to pull any sort of stunts if you're not a crypto expert. I've actually wondered before whether md5 + sha1 would result in something stronger than those two used individually. Now I know.
Re: A new hash algorithm for Git
#33Earlier 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…
Cheap talk is hardly an attack though.
Re: A new hash algorithm for Git
#34I 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
Length actually is already part of the hash result... and the sha-1 collision uses the same length pdfs.
Re: A new hash algorithm for Git
#35Surprising they didn't go with Blake3 instead since it has much higher performance and Git's performance-oriented ethos.
The decision was made before the release of Blake3. The article did mention the algorithm is no longer hardcoded (hence the ability to support both SHA1 & SHA256). This means it's possible to transition to Blake3 (or any other) in future, though it won't be trivial.
Re: A new hash algorithm for Git
#36Earlier quoted context omitted.
Something to remember about the security of concatenated hashes: https://crypto.stackexchange.com/a/63543/291
This is pretty interesting and shows you shouldn't try to pull any sort of stunts if you're not a crypto expert. I've actually wondered before whether md5 + sha1 would result in something stronger than those two used individually. Now I know.
By the way, this may be rather obvious, but concatenating hash algorithms is a terrible idea for passwords. A password cracker could easily pick the less secure algorithm to crack, and ignore the other hash.
Note that git doesn't concern itself with reversing a hash function. The commit contents are part of a repository, there is no value in guessing the commit contents basing on its hash. Here, the hash function choice is purely about collision resistance.
But yeah, don't do weird things with hashes. Cryptography is hard. Don't invent memecrypto: https://twitter.com/sciresm/status/912082817412063233, it's not going to increase the security. Use a single algorithm if you can. Don't transform the output of a hash function in any way.
Re: A new hash algorithm for Git
#37Re: A new hash algorithm for Git
#38I 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...
Of course they are ?!?!!? https://git-man-page-generator.lokaltog.net/ (never fails to amuse me)
Oh dear god. Because it's git related, my brain somehow still tries to make sense of that stuff because it just seems so real.
Re: A new hash algorithm for Git
#39I 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).
Very interesting idea. But, wouldn't existing hashed be kept intact anyway.
Re: A new hash algorithm for Git
#40Earlier quoted context omitted.
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).
If you know that it's a concatenation, couldn't you only look at the SHA1 part and completely bypass any other strong hash? On second thought probably not, because you might find any possible collision, that isn't a collition on all the other hash algorithms. If you bruteforce through a password list it would still apply though.