A member of the SHA2 (or SHA3) family would be more appropriate. RIPEMD-160 is slower and less resistant to collisions. I agree however that the use of SHA1 is problematic!
N-bit hashes have at best (N/2)-bit collision resistance (see birthday attack[1]). An 80-bit security level does not have a large enough margin of safety nowadays.
RIPEMD has a 256-bit variant, but it hasn't received enough scrutiny.
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
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.
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.
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.
Edit: If you're downvoting, please explain. This is more or less factually correct.