7 ms·

For those who are paranoid, but can't move away from SHA-1 for whatever reason, consider using SHA-1DC. It's compatible with SHA-1, but will barf on the known c

by avar 8y ago

For those who are paranoid, but can't move away from SHA-1 for whatever reason, consider using SHA-1DC. It's compatible with SHA-1, but will barf on the known collision attack against SHA-1: https://github.com/cr-marcstevens/sha1collisiondetection https://github.com/cr-marcstevens/sha1collisiondetection It's what Git uses by default, of course there's no guarantee that new SHA-1 attacks won't be discovered, but it's better than nothing.

tialaramex 8y ago
To be clear, what this is doing is _markedly more sophisticated_ than just comparing to a fixed hash we know is bad and rejecting it, and so "new SHA-1 attacks" would likely actually still trip this. The idea in all these MD-family (which SHA1 and SHA2 are members of) collisions is the same, using one or two input blocks you trap the hash function in an awkward place so that fewer state bits than normal matter, and then skewered in this way you calculate one final block that will collide it. The SHA-1DC is watching for that situation which its developers call a "disturbance vector" and so it will detect all attacks based on the same approach and "fix" the hash at a small CPU premium for all hashes. We know for MD5 that independent (presumably nation state given the costs) elements did a similar but different attack that we only found out about after the published MD5 collision - but it trips the same detection (for MD5 in that case) because it's based on the same mathematical approach, even though none of the actual hash values involved were the same. A defence of this sort would have worked, even against an adversary with nation state resources (in this case probably Israel or the US).
- avar 8y ago
  All true, thanks for the elaboration. The only minor thing I'll add is that while its default mode of operation is to munge its internal state when detecting such colliding data and returning a hash that's not the same as what stock SHA-1 would return, it can also be made to just return an error. That's the mode Git uses it in: https://github.com/git/git/blob/v2.21.0-rc2/sha1dc_git.c#L10-L22 https://github.com/git/git/blob/v2.21.0-rc2/sha1dc_git.c#L10...

by avar 8y ago

tialaramex 8y ago

To be clear, what this is doing is _markedly more sophisticated_ than just comparing to a fixed hash we know is bad and rejecting it, and so "new SHA-1 attacks" would likely actually still trip this. The idea in all these MD-family (which SHA1 and SHA2 are members of) collisions is the same, using one or two input blocks you trap the hash function in an awkward place so that fewer state bits than normal matter, and then skewered in this way you calculate one final block that will collide it. The SHA-1DC is watching for that situation which its developers call a "disturbance vector" and so it will detect all attacks based on the same approach and "fix" the hash at a small CPU premium for all hashes. We know for MD5 that independent (presumably nation state given the costs) elements did a similar but different attack that we only found out about after the published MD5 collision - but it trips the same detection (for MD5 in that case) because it's based on the same mathematical approach, even though none of the actual hash values involved were the same. A defence of this sort would have worked, even against an adversary with nation state resources (in this case probably Israel or the US).

avar 8y ago
All true, thanks for the elaboration. The only minor thing I'll add is that while its default mode of operation is to munge its internal state when detecting such colliding data and returning a hash that's not the same as what stock SHA-1 would return, it can also be made to just return an error. That's the mode Git uses it in: https://github.com/git/git/blob/v2.21.0-rc2/sha1dc_git.c#L10-L22 https://github.com/git/git/blob/v2.21.0-rc2/sha1dc_git.c#L10...