[wyager]

That's incredibly misleading.

We don't care about the likelihood of producing some random collision; we care about the likelihood of producing some specific collision (which is not vulnerable to the birthday attack). http://en.wikipedia.org/wiki/Preimage_attack

The reason SHA-1 is considered insufficient is that it is cryptographically broken https://marc-stevens.nl/research/papers/PhD%20Thesis%20Marc%...

I.e. the chance of finding a collision is substantially higher than would be expected from an ideal PRF.

As far as I know, there are no serious cryptanalytical attacks on RIPEMD-160, and 160 bits is more than sufficient for cryptographically unique identifiers.

[timmclean]

Collision resistance is critical for most applications of the OP's scheme. The OP is proposing using hashes as identifiers for immutable content. Imagine the following:

- I publish a JavaScript library under this scheme using a hash without collision resistance.

- Popular/important websites refer to my library as hashname://..., trusting that this refers to the version of the library that they audited.

- I can then create a new, malicious version of the library that has the same hash and use it to infect popular sites.

Allowing collisions breaks the immutability requirement, which impacts security in many important cases.

[wyager]

You're describing a second-preimage attack. You can not use a birthday attack to pull this off. The expected difficulty of pulling of a second-preimage attack on RIPEMD-160 is close to 2^159, which is more than sufficient.

The reason SHA-1 is insecure is that it is cryptographically broken, and the same attack takes less than 2^60 attempts.

[Aloisius]

> Allowing collisions breaks the immutability requirement, which impacts security in many important cases.

All hashes have collisions. There are no cryptographic hashes that can promise zero collisions.

[timmclean]

Of course; I was speaking informally. "allowing collisions" == "allowing it to be feasible to find a collision"