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

The beginning of Git supporting other hash algorithms

github.com

Post reply on HN
Print view View original

71–80 of 128 posts

Re: The beginning of Git supporting other hash algorithms

#71

Post by QSIITurbo »

dahart wrote: post #67
tedunangst wrote: post #61

Earlier quoted context omitted.

Even totally ignoring that SHA2 was a thing, anybody looking around would have noticed that MD4 was broken, MD5 was broken, and it would be unlikely that the hash of today would stand forever.

Yes, true. Correct. That is still true, and applies to SHA-2 as well. And Linus was aware of exactly what you say, back in 2005. My point was that the choice that was made was considered good enough for the purposes for which it was intended. In the context of the OP's comment, criticizing git for not making different code design choices doesn't mean that Linus was wrong, it may mean that the OP doesn't know and/or u…

Well, this whole mess proves that Linus was wrong. Typing "unsigned char [20]" everywhere is beyond amateurish to me in any case and raises a concern about the overall quality of code in git and linux kernel.

Re: The beginning of Git supporting other hash algorithms

#72

Post by wolf550e »

lisper wrote: post #68
rurban wrote: post #58

Earlier quoted context omitted.

I do like your hashname/nohash idea. If we could come up with a simple compression negotiation protocol also: zlib -> zstd. But this will be much harder, as hashes are internal only, and compression is in the protocol. kudos to brian m carlson to convince linus to use sha3-256 over sha256. this is really the only sane option we have.

> this is really the only sane option we have Why?

Yeah, I would have gone with BLAKE2. It's much faster than SHA-256 and SHA3-256: https://blake2.net/skylake.png

Re: The beginning of Git supporting other hash algorithms

#73

Post by wolf550e »

lvh wrote: post #16

FWIW, Fossil released a version with backwards compatibility, configurable graceful upgrades a week ago: https://www.fossil-scm.org/index.html/doc/trunk/www/changes....

Dmitry Chestnykh wrote a little about problems with the documented security claims of Fossil SCM 3 days ago:

https://twitter.com/dchest/status/842489752892968960

https://twitter.com/dchest/status/842498609652383744

Re: The beginning of Git supporting other hash algorithms

#74

Post by mschwaig »

rocqua wrote: post #31
amluto wrote: post #29

Earlier quoted context omitted.

> Technically MD5(128bits) and SHA1(160bits) lengths are sufficient for hashes, but they had cryptographic weaknesses Not true. A 128-bit hash gets collisions after ~2^64 tries. A big cluster can find targeted 128-bit collisions. To attack something like git, the entire attack can be done offline. The big MD5 X.509 break needed cryptanalysis to make it day I because the attack needed to happen in real time.

The threat models in which 64 bits of security (by birthday attack on 128bit hashes) is insufficient are really limited.

On the other hand a hash function that works well in all scenarios that constitute a theoretically sound use of a cryptographic hash function is infinitely harder to misuse.

Re: The beginning of Git supporting other hash algorithms

#75

Post by IncRnd »

rocqua wrote: post #60
IncRnd wrote: post #50

Earlier quoted context omitted.

That is misleading, since a birthday attack is not required. The security strength of hashes is not measured by the length of the hashes. md5 was first "broken" in 1995. As of 10 years ago, a collision attack took only a few seconds. Plus, there are a _number_ of other attacks on the hash.

The argument I replied to concerned best-case for length. I.e. a perfect hash at 128 bits delivers 64 bits of security against collisions. (Note the 'perfect' part) 64 bits of security is good enough against most non-nation state actors. Obviously, MD5 (and sha-1) aren't anywhere near perfect hashes. And obviously, you need to look at more than length when judging a hash. Basically my point was that md5's hash length…

You can rent Amazon time and create an md5 collision for less money than people spend going to a movie. Restating the issue as "a perfect hash is perfect" may be correct in a limited sense, but it is also highly misleading.

64 bits of ideal security is about half the industry accepted security strength in bits for a hash function.

Re: The beginning of Git supporting other hash algorithms

#76

Post by yuhong »

QSIITurbo wrote: post #71
dahart wrote: post #67

Earlier quoted context omitted.

Yes, true. Correct. That is still true, and applies to SHA-2 as well. And Linus was aware of exactly what you say, back in 2005. My point was that the choice that was made was considered good enough for the purposes for which it was intended. In the context of the OP's comment, criticizing git for not making different code design choices doesn't mean that Linus was wrong, it may mean that the OP doesn't know and/or u…

Well, this whole mess proves that Linus was wrong. Typing "unsigned char [20]" everywhere is beyond amateurish to me in any case and raises a concern about the overall quality of code in git and linux kernel.

It shows that Linus is not a cryptographer, to be more precise. Though yes SHA-1 chosen prefix attacks are still very expensive at this point. I wonder how many non-cryptographers knew about SHA-2 back in 2003-2004.

Re: The beginning of Git supporting other hash algorithms

#77

Post by benchaney »

wolf550e wrote: post #72
lisper wrote: post #68

Earlier quoted context omitted.

> this is really the only sane option we have Why?

Yeah, I would have gone with BLAKE2. It's much faster than SHA-256 and SHA3-256: https://blake2.net/skylake.png

This is a perfect example of a situation where hashing performance doesn't matter at all.

Re: The beginning of Git supporting other hash algorithms

#78

Post by snakeanus »

dahart wrote: post #56
loeg wrote: post #35

Earlier quoted context omitted.

> what were the alternatives 12 years ago, or 5 years ago? SHA-2. > And why would someone write code for alternatives that aren't expected to be used and maybe don't exist? Well, the real question is why someone picked SHA-1 over SHA-2 in 2005 when attacks that reduced its strength were already being demonstrated.

Linus has explained why he picked SHA-1. I'm not Linus, and I'm not defending his choice, but he has said repeatedly that git's hash is primarily for indexing and error correction, and not primarily for security. Clearly he felt like SHA-1 was "good enough". And if you have something that's "good enough" there are reasons not to write code for alternatives you're not going to use.

>but he has said repeatedly that git's hash is primarily for indexing and error correction, and not primarily for security

And he was wrong as openpgp signatures on commits and tags are a thing.

Not sure when that feature was introduced however, I doubt that it existed in the first version of git. That being said he should have changed the hash function the moment that feature was introduced.

Re: The beginning of Git supporting other hash algorithms

#80

Post by koolba »

snakeanus wrote: post #79
koolba wrote: post #45

Since the majority of us are running x64 machines, will the hash be a truncated SHA-512/256 or will it be SHA-256? The former is significantly faster on x64 machines.

>Since the majority of us are running x64 machines We don't.

I didn't say all. I said the majority. If you think I'm wrong, show me a statistic that shows the most common platform for developers using git isn't x86-x64.
Post reply on HN