On: A SHA-1 chosen-prefix collision attack

[zdw]

From the paper, this doesn't seem to be able to create a collision while retaining the same length of input data.

It seems that checking both the hash and input length would be a very cheap way of identifying attempts at hash collisions.

[chrisseaton → zdw]

If you're going to modify your code to add an extra check you might as well just switch to another algorithm entirely.

[Someone1234 → chrisseaton]

A lot of existing schemes already check both.

The above comment didn't mention modification explicitly and could be read as talking about the level of threat this poses.

[yardstick → zdw]

This is one reason why HMAC-SHA1 is still safe.

[chias → yardstick]

This is incorrect, the safety of HMAC-SHA1 doesn't have anything to do with input length comparisons. HMAC-SHA1 is still safe because of how an HMAC operates:

Among other operations, HMAC begins by taking the secret key, XOR'ing it with a magic value not under your control, and using this as the first block when calculating an initial hash. In order to guard against an unlikely but potential pathological key / magic value combination, a similar operation is performed as a second round using a different magic value, and this time operating over the hash output from the first round. As such, HMAC operations are safe against chosen prefix attacks against the underlying hash function, because the first block in either round of hashing is entirely outside of your control.

See https://i.imgur.com/PPlVPr0.png for a visual reference. In this diagram, Y is the value being HMAC'ed. As you can see, any attack on the hash function which requires control of the prefix of the value being hashed is a non-starter.

[yardstick → chias]

Thanks, I stand corrected.

[jwilk → zdw]

Where did you read this? Chosen-prefix attack that produces strings of different length would be rather unusual.