Another recommendation: publish your proposal as an Internet-Draft,
rather than expecting people to visit a proprietary site that is known to be a serious privacy threat. Fair point, will do.
The uuidd daemon is used by the UUID library to generate universally unique identifiers (UUIDs), especially time- based UUIDs, in a secure and guaranteed-unique fashion, even in the face of large numbers of threads running on different CPUs trying to grab UUIDs.
Ted, I'll spend some more time looking through the libuuid source code (nice work, btw).
I do need to give more thought to the uniqueness property. One observation is that uniqueness guarantees can be somewhat application-specific, and specific cases can significantly reduce the complexity of implementation. Examples: Applications deployed on a cluster where each machine already has a unique number can simply include that number to ensure uniqueness. Applications only concerned about uniqueness in a single process can easily do this using the clock and a counter.
Making identifiers globally unique in a distributed fashion with high certainty (and still being reasonably short) is a harder problem to solve, but again only certain applications actually require this. But some will, so it will need to be accommodated. I've read various concerns about using the network interface MAC address and how leaking this information can be bad. My thought is that for many applications it may be workable to have an ID with a timestamp and then enough random data coming from a CSPRNG that the probability of collision is simply low enough to be workable. I need to do the math on what the collision probability is for a nanosecond-precise timestamp followed by 64 bits of random data (and for larger amounts of random data also). A lot of engineering already goes into making cryptographically strong random numbers available on modern computers. I could be wrong, but it seems to me that simply knowing the collision probability for a given id configuration (time and random data bit lengths) one can just use one long enough to push the collision probability down below whatever one considers acceptable. E.g. the probability of encountering a duplicate MAC address in the wild, or an implementation bug causing a duplicate. There is no true absolute guarantee of uniqueness, so mind as well just look at the numbers and accept the risk knowingly based on the probability. (I'm thinking this probability information could be given in the proposal, so it's clear like "use this form of ID if you XYZ probability of collision", listed out for each one, etc.) Again, am definitely willing to be wrong here, but that's my logic on it. Thoughts?
