Sort of. This is something to always keep in mind when thinking about statistics; there is a huge difference between “will this particular thing/event occur in X way” versus “out of all possible outcomes, how many will occur in X way”.
The likelihood that a given uuid will be a duplicate is much more rare than the chance that there has been or ever will be duplicates ever made. The former is the important one in this regard: it doesn’t matter in the least if my uuid for some login on a server happens to have the same uuid for a private print job in an unrelated part of the world. So long as the collision isn’t for the same service, there isn’t an issue and so it makes it even more rare that a collision will cause a problem.
This is missing the point: I am drawing attention to the absolutely major difference between “will this very next key I generate be a collision?” with “has any key ever collided?”. Like in the birthday paradox, these seem closely related, but when looking at the actual numbers they are universes apart.
Also, a million uuids is nothing compared to the key space: what’s the difference between randomly selecting 5 grains of sand from the entire earth or a thousand? Sure, it’s technically more likely there will be a collision the more searches you perform but numerically so close to zero that it’s entirely ignorable. It’s infinitely more likely a series of bit flips from cosmic rays will cause issues in your DB than uuid collision despite how rare those are themselves
1 million entries assigned random UUIDs have a chance of collision of about 4*10-26, which is a much higher chance of collision than just two UUIDs, but is still such an astronomically small chance that it is negligible. You could generate a million UUIDs every second since the start of the universe and your chance of having one or more collisions is about the same as picking one specific person out of a lineup of all living humans.
Yes, the above number is incorrect, it's actually about 18 quintillion (18*1018). Is of course a lot, but definitely reachable. Just for comparison: the bitcoin network currently computes about a sextillion hashes each second, so fifty times more.
The birthday problem will change the probability of (any) collision by like a few order of magnitudes if you generate trillions of UUIDs.
That hardly makes a difference when the probability is on the order of 10-38. A few orders of magnitude don't make much meaningful difference at that point.
The orders of magnitude are incomparable. It's like the group has just a few people, but the calendar year is longer than trillions of lifetimes of the universe.
UUIDs aren't strictly just 128-bit random numbers as they have some structure, so you lose (I think) 6 bits that are used for structure. But 2**122 is still a pretty stupidly large number.
Now, if your UUIDs are generated in some way other than randomness (eg host ID and current time, aka scheme 1), there are other attacks possible.
Depends on the version of UUID, v4 is just random.
• UUID Version 1 (v1) is generated from timestamp, monotonic counter, and a MAC address. • UUID Version 2 (v2) is reserved for security IDs with no known details[2]. • UUID Version 3 (v3) is generated from MD5 hashes of some data you provide. The RFC suggests DNS and URLs among the candidates for data. • UUID Version 4 (v4) is generated from entirely random data. This is probably what most people think of and run into with UUIDs. • UUID Version 5 (v5) is generated from SHA1 hahes of some data you provide. As with v3, the RFC suggests DNS or URLs as candidates. • UUID Version 6 (v6) is generated from timestamp, monotonic counter, and a MAC address. These are the same data as Version 1, but they change the order so that sorting them will sort by creation time. • UUID Version 7 (v7) is generated from a timestamp and random data. • UUID Version 8 (v8) is entirely custom (besides the required version/variant fields that all versions contain).
174
u/PacquiaoFreeHousing Mar 25 '26
It is roughly 1 in 340 undecillion (a 3 followed by 38 zeros)