Comment Re:Huh? (Score 4, Informative) 243
He wasn't making an analogy between how you find a hash collision and how you win the lottery -- only comparing the odds.
Dropbox uses SHA-256 hashes. I'm assuming this is what they use for this feature, since it's what they use internally for file identification and deduplication. They actually hash 2 MB file chunks, which means that any file more than 2 MB produces multiple hashes (one per chunk, naturally).
The "many chances of winning" you're referring to here is the birthday collision problem. A good, rough approximation is that for an N-bit hash, while the number of different hashes is 2^N, the number you can generate before risking a collision is about 2^(N/2). So, with SHA-256, we run no significant risk of collision until we've generated around 2^128 ~= 10^38 hashes.
The total amount of data stored worldwide is on the order of 1 ZB. That's room enough for about 10^15 2-MB chunks. Of course, some of our files might be smaller than this 2 MB chunk size, enabling us to be more efficient with storage. We might be able to get somewhere around 10^20 different files in there.
That's a strange and untenable use of all of the world's storage, and it still puts us about 18 orders of magnitude short of being able to risk a SHA-256 collision. If you had this giant set of a ton of different files, the probability of a collision existing is about 1 in 10^37.
So, short of a flaw in SHA-256, you can assume that a hash collision will never happen. We know of no such flaws. (If we do, it will almost certainly be the case that the collision only occurs because one of the two files was specifically manipulated to produce the collision.)
On the other hand, the odds of winning the lottery are rarely worse than 1 in 10^9.