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

81–90 of 128 posts

Re: The beginning of Git supporting other hash algorithms

#81

Post by snakeanus »

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

>b. A SHA256 repository can communicate with SHA-1 Git servers and clients (push/fetch).

Wouldn't fetching from a sha-1 repository degrade security? I think it would be better to show a warning (similar to how openssh does with 1024 bit dsa keys) every time you try to fetch from a SHA-1 git repo. Same for pushing a signed commit to a sha-1 repository.

Re: The beginning of Git supporting other hash algorithms

#82

Post by harshreality »

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

sha3 will probably get hw accel eventually. Blake2 is less likely to. It's like the dilemma between chacha20 and a stream cipher mode for aes. An argument could be made for either, depending on application specifics and available hardware.

Re: The beginning of Git supporting other hash algorithms

#83

Post by harshreality »

benchaney wrote: post #77
wolf550e wrote: post #72

Earlier quoted context omitted.

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.

The hash function may not matter for overall git performance in virtually all dev machine setups, but there will be a (maybe tiny, maybe larger, depending on the repo and disk io speed) difference in cpu utilization and heat generation, right?

Re: The beginning of Git supporting other hash algorithms

#84

Post by indolering »

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…

> Think about the flip side of your question... what were the alternatives 12 years ago, or 5 years ago?

SHA-2 and RIPEMD.

> And why would someone write code for alternatives that aren't expected to be used and maybe don't exist?

That's the problem: the software industry is still suffering from MD5 getting cracked [0]! Cryptographic agility is a baseline requirement for security primitives.

> In my experience, generalizing ahead of need more often than not causes problems

I agree and Linus has valid complaints about security recommendations during the 25-year history of Linux: most of the security recommendations kill performance and are only partial fixes, so why bother?

But Linus is also engaging in premature optimization: computers are ~30 billion times faster than when he first starting programming Linux. Yes, SHA-2 is relatively slow, they could have at least not hardcoded SHA-1 into the codebase and protocol.

> I've watched over-engineering result in far more effort to fix when the need it was anticipating does arrive than just waiting until the need is there.

You clearly haven't done any safety related engineering. That's the thing about cryptography: millions of dollars and human lives are at stake. Despite the smartest people in the world working on these problems, cryptographic primitives/protocols are regularly broken. Due to Quantum computing, every common cryptographic primitive we use today will need to be replaced or upgraded at some point.

Thankfully, you don't need to worry about the engineering of a given cryptographic primitive as long as you can swap it out with a new one. But when you hardcode a specific hash function and length into your protocol/codebase you are now assuming the role of a cryptographer.

[0]: https://en.wikipedia.org/wiki/Flame_%28malware%29

Re: The beginning of Git supporting other hash algorithms

#85

Post by QSIITurbo »

yuhong wrote: post #76
QSIITurbo wrote: post #71

Earlier quoted context omitted.

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.

No it's more than that. "unsigned char[20]" already has at least three potential points of failure (and why isn't it uint8 anyways). Moreover, it'll be referenced as unsigned char*, which opens another can of worms. And oh, by the way, have fun searching all references to sha1 on your source code now that you weren't pro enough to create a type for your object ids / hashes.

I'm guessing it's part lack of skill in design, part bad software development tools (uEMACS and makefiles or something), and part just being against c++ et al.

Re: The beginning of Git supporting other hash algorithms

#86

Post by bhhaskin »

snakeanus wrote: post #81
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...

>b. A SHA256 repository can communicate with SHA-1 Git servers and clients (push/fetch). Wouldn't fetching from a sha-1 repository degrade security? I think it would be better to show a warning (similar to how openssh does with 1024 bit dsa keys) every time you try to fetch from a SHA-1 git repo. Same for pushing a signed commit to a sha-1 repository.

The sha1 hash isn't used for security. You should be signing your commits if security is a concern.

Re: The beginning of Git supporting other hash algorithms

#87

Post by indolering »

yuhong wrote: post #76
QSIITurbo wrote: post #71

Earlier quoted context omitted.

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.

Linus regularly treats security as a second-class citizen and is famous for his outrageous harassment [0]:

> Of course, I'd also suggest that whoever was the genius who thought it was a good idea to read things ONE FCKING BYTE AT A TIME with system calls for each byte should be retroactively aborted. Who the fck does idiotic things like that? How did they noty die as babies, considering that they were likely too stupid to find a tit to suck on?

He deserves to eat this shit sandwich.

> I wonder how many non-cryptographers knew about SHA-2 back in 2003-2004.

Any systems engineer should have known about SHA-2. SHA-1 only provides 80-bits of security, so everyone else assumed that it would need to be replaced.

[0]: https://en.wikiquote.org/wiki/Linus_Torvalds

Re: The beginning of Git supporting other hash algorithms

#88

Post by david-given »

wolf550e wrote: post #73
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

Given that both claims are unreferenced and using deliberately provocative language, I'd say he wrote very little...
Post reply on HN