Linus' reply on Git and SHA-1 collision

Re:Linus' reply on Git and SHA-1 collision by loup-vaillant on Thursday February 23, 2017 @09:55PM (#13720509)

Clearly, Linus didn't know at the time. If he'd know, he would have chosen another hash in 3 seconds —no additional complexity, no additional effort involved in not choosing a hash the security community starts to have doubts about.

[ Parent | on HN ]

Re:Linus' reply on Git and SHA-1 collision by dingo_bat on Thursday February 23, 2017 @10:16PM (#13720610)

Don't forget the extra computation cost with a more complex hash.

[ Parent | on HN ]

Re:Linus' reply on Git and SHA-1 collision by loup-vaillant on Friday February 24, 2017 @05:06AM (#13722435)

Nobody cares. Hashes are plenty fast. Even the code complexity doesn't matter: I've implemented both SHA-256, and SHA-512, take less than a hundred lines of code. And of course, Linus would have use some existing implementation.

Also, "more secure" doesn't necessarily mean "more complex", or "slower". Blake2b for instance is as fast as md5 and has a simple RAX (xor, rot, add) core from Chacha20.

[ Parent | on HN ]

Re:Linus' reply on Git and SHA-1 collision by Kubuxu on Friday February 24, 2017 @06:23AM (#13722691)

It wasn't like that in 2005.

[ Parent | on HN ]

Re:Linus' reply on Git and SHA-1 collision by KingMob on Friday February 24, 2017 @12:04AM (#13721156)

Which is largely irrelevant on desktops. Nobody's using git on embedded devices, so hash computational cost shouldn't be the deciding factor. Maybe people storing BLOBs will notice.

[ Parent | on HN ]

Re:Linus' reply on Git and SHA-1 collision by reacweb on Friday February 24, 2017 @04:58AM (#13722387)

There are blobs in the kernel and speed was a very important motivation when kernel switched to git.

[ Parent | on HN ]

Re:Linus' reply on Git and SHA-1 collision by loup-vaillant on Friday February 24, 2017 @05:08AM (#13722440)

So now we need to assess whether hashes are a significant bottleneck.

[ Parent | on HN ]