Probability of GUID collisions with different versions
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
* Some types of UUID uniquely identify the machine they were generated on (one version contains the MAC address + current time, another contains the POSIX UID/GID + domain name) - this got Microsoft into hot water in the 1990s when Word added GUIDs to documents, which meant you could trace documents Stasi-style
* Some types of UUID are based on insecure hashing algorithms (MD5 and SHA1)
* Some types of UUID are namespaced, because everything needs namespaces, obviously
* There's a specially reserved type for Microsoft to use for special COM objects
There's only one mode you should actually use, which is the random bits.
UUIDs and GUIDs also have a weird spacing of dashes. You'd expect three dashes, splitting it into a sequence of 4-byte chunks, but no: it's split into 4-2-2-2-6, for some reason. And which chunk it is matters, because different chunks have different endianness. Some of them are considered numbers, some of them bytes, even though they all look the same. Some of them have special significance (it contains two different version numbers!), with no especially obvious rhyme or reason to their placement. Oh, and the endianness is implementation-defined: GUIDs are partly "native" endian (usually little-endian, then), partly big-endian, whereas UUIDs are typically big-endian. How do you tell them apart? Well, GUIDs are usually written in capitals, and UUIDs are usually written in lowercase.
I just use 16 random bytes encoded in hexadecimal, separated by three dashes at 4-byte increments. No hashing algorithms, versions, endianness issues, namespacing, severe privacy problems, just random bytes. It's not only simpler, it has more bits of entropy, and is easier to generate.
Also be careful of what you think is 'random'. Calling the OS random-number-generator may not be random enough. I'd recommend in every case to use the system library to generate a UUID.
Why not avoid UUID altogether? It is an overly complicated format. It is simpler to just generate 16 random bytes and represent them as you wish.
Beware that 16 random bytes, at least currently, is not a valid UUID. You have to include version and variant numbers.
> Go ahead and render it any way you like, but there are no endianness issues. The bytes are random and meaningless.
Endianness absolutely matters. If you don't encode it and decode it correctly from the binary formats, you will end up with a different identifier.
> Also be careful of what you think is 'random'. Calling the OS random-number-generator may not be random enough.
If it's just a regular PRNG, sure. What you want is a CSPRNG, like /dev/urandom.
To have endianness implies scalar subfields, which implies meaningful values in those fields. This goes back to when the fields had meaning (mac address, timestamp and so on). Nowadays they are random bytes and the breakdown into scalar parts has no useful purpose.
Now, you can print UUIDs any way you like. And if you print them different places with different rendering libraries they can look different, sure. Don't confuse that with the underlying value, which is a random string.
If you're passing around the string representation, then endianness isn't an issue, sure. But you need to care about it if you store UUIDs efficiently as bytes.
> To have endianness implies scalar subfields, which implies meaningful values in those fields. This goes back to when the fields had meaning (mac address, timestamp and so on). Nowadays they are random bytes and the breakdown into scalar parts has no useful purpose.
Even if you're only using random UUIDs, you need to worry about this, because UUIDs always contain a version and variant number.
> Now, you can print UUIDs any way you like. And if you print them different places with different rendering libraries they can look different, sure. Don't confuse that with the underlying value, which is a random string.
The string is only mostly random. It contains version information.
Huh? Strings are stored and transmitted as bytes, there is no need to interpret the subfields as any given endianness if the whole thing is stored as 16 bytes.
Alternatively you can interpret the hexadecimal encoding of the subfields to raw values, and compact things into a single 16 byte / 128-bit value, which I'm assuming is what's being referred to by "storing UUIDs efficiently as bytes".
To perform this compacting requires some interpretation - if only from hexadecimal to bytes. In implementing this, you might feed the entire first subfield to your hex parsing function. The result, however, will be an integer with more bits than a byte, at which point you need to care about endianness.
You can choose to instead parse two hex characters as a time and treat each as a byte. You could argue that this is "not" interpreting the subfield as any given endianness - but this is semantically identical to interpreting the field as big endian, so I'd argue that you are.
Issues that don't exist if you don't use a hideously complex format like UUID in the first place.
> Yes there are many bad ways to generate them, but your library should offer the right way to generate them.
Yes, a UUID library will have a way to generate the random kind of UUID, but it's telling that you need a library for it.
You can generate 16 random bytes without a library, by using fopen() and fread().
> Yes the string format is weird, but why would you write that by hand? Let the library print it, let the library parse it.
You shouldn't need a library to handle your identifiers. If you do, your identifiers are too complicated.
> Want to store it in a database? There's a column type for that. Want to send it over the network? There's probably a datatype for it in whatever protocol you're using (whereas with your approach you immediately have endianness issues).
With the approach of random bytes, there's at least a consistent endianness throughout. And you can solve the endianness issue by treating it as a byte string. Job done.
Sounds more complicated and easier to get wrong. I'd rather have a single function call with an obvious name.
Yeah but then good luck getting the right /dev/random vs /dev/urandom on the right platform, and also good luck getting it to work on windows and ios.
Although if you were using GUIDs in indexes in SQL Server, it made sense for them to have some similarity and allow ordering [1]
Last time I benchmarked this, however, I couldn't detect any difference.
[1] http://blogs.msdn.com/b/sqlserverfaq/archive/2010/05/27/guid...
MD5 and SHA-1 being broken only matter if you let users choose your keys, to which the answer is don't do that.
Another thing to consider, is that due to the birthday paradox once you build 2.7 * 10^18 GUID, the probability that you have at lest a collision is bigger than 50%. And 2.7 * 10^18 is only 2^61.2.
In any case, I should have been more clear. I'm not necessarily worried about this case. But if you design systems and miss a factor of a square root, you tend to break things that we're all relying on to work.
It's going to be a while before the birthday paradox is really going to be problematic.
There may be duplicate GUID:s used in different contexts and that's just fine. If there is single system and context where storing just GUID:s takes several exabytes we may start worrying.
Be careful there. Parts of Europe including here (the UK) officially use short scale like the US.
When looking at historical figures it is important to be extra careful as scale use has flipped back and forth over time in places. "Historical" doesn't go as far back as you think either: short scale becoming the standard number naming convention in the UK happened in 1974 so there are still people alive who use long scale and remember it being the most common form.
To really confuse things some places use a half-way house of "short scale with milliard"...
It is safer to stick with "scientific" prefixes (kilo, mega, giga, tera, ...) as they are consistently interpreted the same way except where someone is being deliberately difficult (for "deliberately difficult" read "just plain wrong"). It sometimes sounds odd referring to things like "giga pounds" instead of "billions of pounds" (or "thousand millions of pounds" or "milliards of pounds") but it reduces the risk of misinterpretation and anyone who doesn't understand probably wouldn't truly understand any of the above terms without explanation.
For more see https://en.wikipedia.org/wiki/Long_and_short_scales
https://en.wikipedia.org/wiki/Globally_unique_identifier#Bin...
http://stackoverflow.com/questions/246930/is-there-any-diffe...
A UUID generated or used by any of Microsoft's APIs or tools named with "Guid" are 100% standard UUIDs. It is not possible to create a a UUID with these APIs or tools that does not conform to the standard.