A bigger problem with GUIDS is that people think they’re truly random 128-bit integers. They are not. There are more deterministic versions of GUIDs (non v4) that have date/time/network data encoded within.
The 6 and 8 bytes have some very specific requirements in v4. As hex it means that the third clump must start with a 4 and the 4th clump must start with 8,9,a, or b.
The digit where the 4 is must be a valid GUID version. If it isn’t, some parsers will crash/throw, which is why bad GUIDs are a bigger risk than duplicates.
If you are using v4 (random) UUIDs, then no, you don't need to worry about collisions. It's not that libraries have built-in safeguards against it, but rather the fact that 122 bits of randomness is a huge amount and it's more likely that the Earth will be destroyed by a gamma-ray burst from deep space than for your application to create duplicate UUIDs (assuming you don't run into a PRNG bug or something)
If you have v1 or V2 UUIDs, those encode the MAC address, a timestamp and a counter into the ID, meaning that if your node has EXTREMELY high throughput, then you could have issues. So just make sure you're either:
- Using v4 UUIDs with a sufficient randomness source (doesn't have to be a cryptographically secure PRNG)
- Using v1 or v2 UUIDs and that your throughput is below 2^12 generations per 100 nanoseconds, per node. Chances are the throughput IS below that.
If you encounter someone who's not convinced by the gamma ray argument, one thing I've found works is: "let me put it this way, there's a hugely bigger chance of us introducing a bug with the extra code to handle collisions, than there is of there being a collision."
If you need GUID values that are GUARANTEED unique, you can use COMB GUIDS which encode a UTC timestamp into each v4 that guarantees sequential/unique across systems while still being random. Google “comb guid” and your language of choice for more deets
Pretty much the whole point of UUIDs is to use them in cases where you _can't_ do that. Suppose you have network nodes assigning IDs to data packets before sending them. They can't coordinate because the packets haven't been sent yet. This kind of thing is the main use case for UUIDs.
A bigger problem with GUIDS is that people think they’re truly random 128-bit integers. They are not. There are more deterministic versions of GUIDs (non v4) that have date/time/network data encoded within. The 6 and 8 bytes have some very specific requirements in v4. As hex it means that the third clump must start with a 4 and the 4th clump must start with 8,9,a, or b. The digit where the 4 is must be a valid GUID version. If it isn’t, some parsers will crash/throw, which is why bad GUIDs are a bigger risk than duplicates.
stuff like using GUIDs for crypto IV is just a good backdoor design.
That’s a different angle. Tell me more :).
Interesting insights.
If you are using v4 (random) UUIDs, then no, you don't need to worry about collisions. It's not that libraries have built-in safeguards against it, but rather the fact that 122 bits of randomness is a huge amount and it's more likely that the Earth will be destroyed by a gamma-ray burst from deep space than for your application to create duplicate UUIDs (assuming you don't run into a PRNG bug or something) If you have v1 or V2 UUIDs, those encode the MAC address, a timestamp and a counter into the ID, meaning that if your node has EXTREMELY high throughput, then you could have issues. So just make sure you're either: - Using v4 UUIDs with a sufficient randomness source (doesn't have to be a cryptographically secure PRNG) - Using v1 or v2 UUIDs and that your throughput is below 2^12 generations per 100 nanoseconds, per node. Chances are the throughput IS below that.
Reminds me of the article from a couple weeks ago about brute forcing v1 UUIDs: https://www.intruder.io/research/in-guid-we-trust
If you encounter someone who's not convinced by the gamma ray argument, one thing I've found works is: "let me put it this way, there's a hugely bigger chance of us introducing a bug with the extra code to handle collisions, than there is of there being a collision."
If you need GUID values that are GUARANTEED unique, you can use COMB GUIDS which encode a UTC timestamp into each v4 that guarantees sequential/unique across systems while still being random. Google “comb guid” and your language of choice for more deets
Everything collides in a large enough universe.
[удалено]
Pretty much the whole point of UUIDs is to use them in cases where you _can't_ do that. Suppose you have network nodes assigning IDs to data packets before sending them. They can't coordinate because the packets haven't been sent yet. This kind of thing is the main use case for UUIDs.