3 ms·

> Now this is a bad idea Somebody better tell Linus? I kid. But yeah the answer is you use it as part of your lookup and then mitigate collisions with more exp

> Now this is a bad idea Somebody better tell Linus? I kid. But yeah the answer is you use it as part of your lookup and then mitigate collisions with more expensive comparisons.

usr1106 5y ago
He was told weeks after git was published, I guess 2005. Sorry, no link handy. They are working on it since 2017. https://github.com/bk2204/git/commits/transition-stage-4/Documentation/technical/hash-function-transition.txt https://github.com/bk2204/git/commits/transition-stage-4/Doc... Not that it's particularly urgent...
dezren39 5y ago
It's a non-issue he's addressed many times. What happens after you collide a single hash, you need to have a useful commit that isn't going to destroy the ability of the code to run AND do something useful to you, etc etc? Also what happens after the next commit, where all the hashes recalculate? It's possible to be an issue, but highly improbable. More likely your creds are hacked or the fact that no one signs their commits finally bites us on a wide scale.
naniwaduni 5y ago
Well, it's well known since basically as soon as git was published and determined to have not been a big deal, with work on the way ever since an actual collision was published. Anyway, practically you're going to write a collision fallback anyway, the difference is that as long as collisions aren't likely, you can be pretty sure that collision handling is a very cold code path that's never going to have more than a handful of items in a bucket. The point I'm trying to make, though, is that while practical collision attacks do have practical implications, they aren't relevant to password hashing. People routinely assume that collision attacks make a hash unsuitable for password hashing. They're not exactly wrong, but it's kind of a non sequitur. I felt that this was a point that had to be made because the framing of parent ("what the consequences of a collision are") implied that the expected answers were exactly the opposite.

> Now this is a bad idea Somebody better tell Linus? I kid. But yeah the answer is you use it as part of your lookup and then mitigate collisions with more expensive comparisons.

usr1106 5y ago

He was told weeks after git was published, I guess 2005. Sorry, no link handy. They are working on it since 2017. https://github.com/bk2204/git/commits/transition-stage-4/Documentation/technical/hash-function-transition.txt https://github.com/bk2204/git/commits/transition-stage-4/Doc... Not that it's particularly urgent...

dezren39 5y ago

It's a non-issue he's addressed many times. What happens after you collide a single hash, you need to have a useful commit that isn't going to destroy the ability of the code to run AND do something useful to you, etc etc? Also what happens after the next commit, where all the hashes recalculate? It's possible to be an issue, but highly improbable. More likely your creds are hacked or the fact that no one signs their commits finally bites us on a wide scale.

naniwaduni 5y ago

Well, it's well known since basically as soon as git was published and determined to have not been a big deal, with work on the way ever since an actual collision was published. Anyway, practically you're going to write a collision fallback anyway, the difference is that as long as collisions aren't likely, you can be pretty sure that collision handling is a very cold code path that's never going to have more than a handful of items in a bucket. The point I'm trying to make, though, is that while practical collision attacks do have practical implications, they aren't relevant to password hashing. People routinely assume that collision attacks make a hash unsuitable for password hashing. They're not exactly wrong, but it's kind of a non sequitur. I felt that this was a point that had to be made because the framing of parent ("what the consequences of a collision are") implied that the expected answers were exactly the opposite.