Hash Collision - what are the chances? [closed]

Answer 1

There is a very simple rule to find out if any hashing algorithm would have collisions or not. If the output range of an algorithm is a finite number, one is bound to have a collision, sooner or later.

Even though SHA1 has a very large range of 2^160 hash possibilities, its still a finite number. However, the inputs which can be passed on that function are literally infinite. Given a large enough input data set, collisions are bound to happen.

Answer 2

SHA-1 produces 160 bit long digest. Therefore you are safe as long as you have less than 2^(160/2) entries. Division by 2 is due to birthday paradox.

Answer 3

If you use numerically increasing IDs as input, then chances are practically zero that SHA-1 will collide.

If the ID is the only input, then SHA-1 seems to be quite some overkill - producing a 160 bit hash from a 32-bit integer. I would rather use modular exponentiation, e.g. chose a large (32-bit) prime p, compute the modular generator g of that group, and then use g^id. This will be guaranteed collision free, and only give 32-bit "hashes".

Answer 4

I don't think sha1() is going to give you any trouble here, weak random number generation is a more likely candidate for collisions.

Stefan Esser wrote good article on the topic.

Answer 5

why not do something which guarantees there'll be no collisions, as well as makes sure that no one can change a GET parameter to view something they shouldn't: using a salt, combine the id and its hash.

$salt = "salty";
$key = sha1($salt . $id) . "-" . $id;
// 0c9ab85f8f9670a5ef2ac76beae296f47427a60a-5

even if you do accidentally stumble upon two numbers which have the exact same sha1 hash (with your salt), then the $key will still be different and you'll avoid all collisions.