Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by mlindner | Hacker News Reader

Parent Full thread

mlindner·

I mean that doesn't help anything as if you collide the SHA-1 hash you automatically get a SHA-256 hash collision.

View on HN

That can't be true

Perhaps I misinterpreted your comment.

If you have X and Y such that X has a SHA1 hash collision with Y, you end up such that SHA256(SHA1(X)) == SHA256(SHA1(Y)).

That's why I said what I said.

I think the ancestor comment meant SHA1(SHA256(X)) instead. Not clear to me how that wouldn’t have collisions, too. Just that the underlying commits that generate the collisions would need to look different.

If that's the case you can just replace the SHA256(X) portion with arbitrary content to get the above SHA1 collision.

I don't follow. If the algorithm is SHA1(SHA256(X)) all an attacker can modify is X. Yes it's possible to find a SHA1() collision, but finding X where the SHA256() will generate a collision -- that is SHA1(SHA256(X)) == SHA1(SHA256(Y)) -- is still required.

The question is does the SHA1 step make this any easier?

Don't you still have to either break SHA256 (predicting the hash it will generate) or do this by brute force?

I was assuming that it was optionally SHA1(X) or SHA1(SHA256(X)) with the determination of which happening being something attacker controllable in X.

I’m OP. I mean SHA1(SHA256(X)) but I have no idea if that makes a collision more difficult than SHA1(X) or any other implications. It was a way to reduce to hash length without truncation.

Reply on news.ycombinator.com