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

31–40 of 128 posts

Re: The beginning of Git supporting other hash algorithms

#31

Post by rocqua »

amluto wrote: post #29
anilgulecha wrote: post #27

Earlier quoted context omitted.

A note on 'lifecycle': that's not how it works -- the age of use/lifecycle is not a function of the bit-length in hash, or inevitability of the current standard being broken. Technically MD5(128bits) and SHA1(160bits) lengths are sufficient for hashes, but they had cryptographic weaknesses -- the functions had cryptanalytic attacks, which reduced bruteforce from the complete keyspace to something of a much smaller ma…

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

Re: The beginning of Git supporting other hash algorithms

#32

Post by digi_owl »

dahart wrote: post #22
zoren wrote: post #10

Someone please remind me why the hash is not a type definition so the representation would only have to be changed in one place.

That's exactly what this change is. You mean why wasn't it that way before the change? Maybe because it wasn't ever needed before? Git's been good with only sha-1 for 12 years. Think about the flip side of your question... what were the alternatives 12 years ago, or 5 years ago? And why would someone write code for alternatives that aren't expected to be used and maybe don't exist? In my experience, generalizing ahea…

Not really adding much, but damn it i feel old reading that.

I still recall freshly the hoopla over Bitkeeper licensing that lead to Torvalds creating Git.

Re: The beginning of Git supporting other hash algorithms

#33

Post by kozak »

anilgulecha wrote: post #27
kozak wrote: post #25

Do they anticipate that one day we'll have to move from SHA256 to something else again? It's only matter of time. Hash function have lifecycle. Tre transition has to be done in a way that will also make the next transition more straightforward.

A note on 'lifecycle': that's not how it works -- the age of use/lifecycle is not a function of the bit-length in hash, or inevitability of the current standard being broken. Technically MD5(128bits) and SHA1(160bits) lengths are sufficient for hashes, but they had cryptographic weaknesses -- the functions had cryptanalytic attacks, which reduced bruteforce from the complete keyspace to something of a much smaller ma…

Yep, I'm not about the bit length: 256 bit "should be enough for everybody". But algorithms to generate those 256 bits will change.

Re: The beginning of Git supporting other hash algorithms

#34

Post by loeg »

jffry wrote: post #12
zoren wrote: post #10

Someone please remind me why the hash is not a type definition so the representation would only have to be changed in one place.

If you have a repo with a lot of GPG signed commits, or you just don't want to change all your commit IDs (because you reference them in other places), then it'd be very valuable to be able to have a repo that's mixed old and new hashes. Also your Git binary, if compiled with only the One True Hash™, wouldn't be able to work with older repos at all because the hashes it's calculating are now different. (Edit: Another…

The one typedef could have just been changed from char[20] to 'struct objectid' to support multiple hash types.

Re: The beginning of Git supporting other hash algorithms

#35

Post by loeg »

dahart wrote: post #22
zoren wrote: post #10

Someone please remind me why the hash is not a type definition so the representation would only have to be changed in one place.

That's exactly what this change is. You mean why wasn't it that way before the change? Maybe because it wasn't ever needed before? Git's been good with only sha-1 for 12 years. Think about the flip side of your question... what were the alternatives 12 years ago, or 5 years ago? And why would someone write code for alternatives that aren't expected to be used and maybe don't exist? In my experience, generalizing ahea…

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

Re: The beginning of Git supporting other hash algorithms

#36

Post by drostie »

bk2204 wrote: post #9

I'm the person who's been working on this conversion for some time. This series of commits is actually the sixth, and there will be several more coming. (I just posted the seventh to the list, and I have two more mostly complete.) The current transition plan is being discussed here: https://public-inbox.org/git/CA+dhYEViN4-boZLN+5QJyE7RtX+q6a...

I'm not quite so familiar with the Git internals, how do you deal with the problem of having different non-leaf nodes scattered through the directory tree?

This might be a non-issue based on how Git stores the tree, but I can imagine one simple model where each directory would be a sort of "collection object", a binary encoding of a list of (filename, hash) pairs in filename order, and therefore the directory gets a hash of its own. But that means that when you're communicating with a SHA-1 repository you don't just need to rename this object; its contents also need to be changed pre-rename, and then you need to store every internal node twice. I'm not seeing that in your summary.

Is it just that Git doesn't have any internal nodes in the directory tree per se because the "filename" is a full POSIX path with subdirs? Or what?

Re: The beginning of Git supporting other hash algorithms

#37

Post by asveikau »

zoren wrote: post #10

Someone please remind me why the hash is not a type definition so the representation would only have to be changed in one place.

How to say this without being rude.. You didn't read the diff.

To derisively say "remind me why not X" at a diff that does X ... I am amused.

Re: The beginning of Git supporting other hash algorithms

#38

Post by csense »

zoren wrote: post #10

Someone please remind me why the hash is not a type definition so the representation would only have to be changed in one place.

They want the new version to be backward compatible with existing sha1 repos and remotes. Also, sha256 hashes are longer.

Re: The beginning of Git supporting other hash algorithms

#39

Post by dang »

irontoby wrote: post #11

Why don't you ask Linus, I'm sure he will calmly and respectfully explain the answer while apologizing for the trouble :)

"Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them."

https://news.ycombinator.com/newsguidelines.html

We detached this subthread from https://news.ycombinator.com/item?id=13907130 and marked it off-topic.

Post reply on HN