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

101–110 of 240 posts

Re: A new hash algorithm for Git

#101

Post by velcrovan »

alkonaut wrote: post #95

I didn't get the argument against just converting? Sure some code bases are large and spread out, but any git repo needs to have one blessed central point, and everyone needs to be able to just re-clone from the central repository whenever history is rewritten for whatever reason (could be that a huge file is trimmed from the past etc). Why can't all commits in the Kernel history be rewritten to SHA256? (Other than t…

The whole point of git is that there doesn't need to be a blessed central point.

Re: A new hash algorithm for Git

#102

Post by ekimekim »

bangboombang wrote: post #38
buserror wrote: post #10

Earlier quoted context omitted.

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.

It's a curious feeling. Like reading code that is syntactically valid but utterly nonsensical.

Re: A new hash algorithm for Git

#103

Post by bjoli »

nnx wrote: post #11

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

There are organisations that can only use approved crypto for various certifications and government contracts. It would be bad to drive such users away from git.

Under "feedback from git people" on https://www.mercurial-scm.org/wiki/SHA1TransitionPlan

Re: A new hash algorithm for Git

#104

Post by wolfgke »

nullc wrote: post #87
wolfgke wrote: post #58

Earlier quoted context omitted.

> Zen2 is freeking awesome. :) SHA-NI was introduced with the Intel Goldmont microarchitecture.

Yes, but Goldmont is not particularly awesome. :) Presumably goldmont would be a downgrade for many people. (On AMD the first generation zen have sha-ni, FWIW)

Of course, processors that use one of the Atom/Celeron/Pentium microarchitectures are not the best choice if you desire maximum speed, but otherwise they are surprisingly interesting processors (IMHO much more interesting than what Intel delivers with the Core series).

At this time, Intel often experiments with or introduces features that are particularly interesting for embedded usages first on the Atom. For example the already mentioned SHA-NI. Another example are the MOVBE instructions (insanely useful if you handle big-endian data, for example in network packages (I am aware that on older x86 processors, there exists the BSWAP instruction)) - they were first introduced with Atom.

Re: A new hash algorithm for Git

#105

Post by jayflux »

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?

Re: A new hash algorithm for Git

#106

Post by IshKebab »

rocqua wrote: post #55
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.

I don't see how it would change anything. A collision of a short prefix is trivial to generate with any hash.

Re: A new hash algorithm for Git

#107

Post by acidictadpole »

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 unlikely now, but SHA-1 is only getting weaker as time goes by and more research is done.

Re: A new hash algorithm for Git

#108

Post by dfox »

tialaramex wrote: post #61
jakeogh wrote: post #2

Is there an archive of crypto related future predictions? How long until a specified length preimage attack can break bittorrent blocks? I remember a paper published a ~decade ago estimating very short (well funded) ASIC sha1 collisons. Anyone have that ref? EDIT: Should I have not said preimage? My understanding is bittorrent is broken (by DDoS, not infohash(?)) if you can make a bad block that matches the length an…

> EDIT: Should I have not said preimage? My understanding is bittorrent is broken (by DDoS, not infohash(?)) if you can make a bad block that matches the length and sha1 of a target block. There are three different attacks 1. Collision, which is practical (expensive but practical) for SHA-1 today, lets somebody make two documents A and B which have the same hash. This is only useful if you can fool people somehow int…

The reason why people mostly meand second pre-image when saying unqualified "pre-image" is that probably any imaginable method of reversing a hash function (given sufficiently long input to the hash) will with overwhelming probability produce hash input that is different from the original.

Re: A new hash algorithm for Git

#109

Post by strenholme »

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?

I haven’t seen any benchmarks for BLAKE3 vs. the Intel/AMD SHA extensions. My guess is that Intel hardware accelerated SHA-256 will be faster than BLAKE3 running in software for most real world uses.

I can tell you this much: It is only with Ice Lake, which was released in the last year, that mainstream Intel chips finally got native hi speed SHA-NI support. Coffee Lake and Comet Lake, which are still the CPUs in a lot of new laptops being sold right now, do not support SHA-NI.

Re: A new hash algorithm for Git

#110

Post by arve0 »

wongarsu wrote: post #81
donatj wrote: post #71

Excuse my ignorance, but couldn’t they just add a SHA256 hash to commit objects (or some new commit-verify object) of the entire trees current concatenated content, leave everything else SHA1 and get the same benefit without rewriting the entire thing from the ground up? Git could even do that as part of the git gc step slowly over time - tag commits with a secondary hash. Rewriting the whole thing including every gi…

You can't change past commits to add that hash (without changing all commit hashes), so this method could only protect new commits. For any existing repo this would lead to a very weird security model: We admit that sha1 hashes are broken, and only guarantee that commits made by git versions newer than git x.x.x are safe from after-the-fact modification (or alternatively only commits made after date X).

I’m not known with the internal data structure of git, but couldn’t you add the new hash as a commit in a new format “on the side”, leaving the original commit as is?
Post reply on HN