I wouldn't trust pronouncements like "I haven't seen this in a year of usage", unless the user has generated something approaching 2^64 (ie. (I've played with the last, and it works like a charm, BTW). True randomness can be generated from (a) radioactive decay (b) random background radio noise, often contaminated unless you're careful (c) suitably chosen electronic noise, e.g. It is actually rather difficult to ensure that this is the case. If you use a 128-bit UUID, the 'birthday effect' tells us that a collision is likely after you've generated about 2^64 keys, provided you have 128 bits of entropy in each key. I haven't found any solid research.Ī suggestion: tread very carefully here, and know your cryptography well. I don't believe it's been adequately considered in the rush to use UUIDs everywhere. If you do not trust the programmer of the other processes, then check for collisions or use a different UUID version. If you don't trust your own ability to correctly understand and use the random generator of your choice, then it is indeed a good idea to check for collisions. You're responsible for your random generator within your own application, but this and anything else is based on trust. This is not feasible, the namespace variant should be used." Must be willing to rely on the random number source at all hosts.
Distributed applications generating UUIDs at a variety of hosts This pretty much allows anything from the xkcd random generator to a hardware device using quantum noise. Randomly (or pseudo-randomly) chosen values." The version 4 UUID is meant for generating UUIDs from However, the RFC linked in the other answer defines this for version 4: But the probability only holds if the bits are perfectly random.
0 kommentar(er)
