Re: UUID version 6 proposal, initial feedback

[Brad Peabody <[e-mail]>]

> 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?