Solving for faster SHA-1 collision detection

Posted by srijs 2 days ago

Solving for faster SHA-1 collision detection(sam.dev)

50 points | 9 comments

gleenn 9 hours ago|

This seems extremely cool, but man does it also sound complicated. The write up was thorough but the algorithm seems so complicated that the author can't even write good tests for it is concerning. I would be very concerned their algorithm might accidentally skip something important accidentally given they are dealing with dynamically combining large binary expressions. You can make it fast, but if you can't prove it and it's security related that probably needs to be proved out more, even if SHA1 is already compromised.

ted_dunning 5 hours ago||

Fuzz tests with tailored random distributions and good logical property tests are excellent tests.

What would you do better?

Also, the author didn't say that there were no other tests. They just said that they use fuzz + property tests a fair bit.

bawolff 7 hours ago||

Why do you conclude the author cannot write good tests for it?

rurban 7 hours ago||

Does git proper already accepts rust? 2x faster pack checks would be worthwhile, as it affects everybody. I heard since 2.55 they already do

masklinn 6 hours ago|

Git proper has had rust code in it since 2.52, as an opt-in optional. 2.55 makes it opt out. 3.0 might make it required.

someonebaggy 8 hours ago||

This writing almost feels AI, but it's not AI. Why is that?

bawolff 7 hours ago|

This reads like a totally normal article to me. At some point these AI accusations feel like a witch hunt.

entrope 4 hours ago||

I thought it was a really good, clear write-up of a very nice engineering discovery and optimization. If anything, I think an LLM would generate native superscript for the `2^(-r)` expression, so I didn't have an impression of LLM authorship.

Maybe an LLM did the search for what expressions to put in the blocks vs tail of the vectorized collision detection, but that seems like a good place to use an LLM as long as all of the expected bit relations are verified as checked properly.

srijs 4 hours ago||

Hi, author here. FWIW the blog is fully hand-written. I used Claude to help me generate the visuals.

What goes into head vs. tail is actually fully deterministically decided by the solver based on a P(tail) gradient, so expressions that are more effective in filtering out blocks before they can hit the (slower) tail are preferred in the prefix.

DreamOfXM 9 hours ago|

[flagged]