On Fri, Jan 31, 2020 at 02:06:58PM -0800, Brad Peabody wrote: > I get where you're coming coming. The issue is there are common use cases > where just using cryptographic nonce does not work well. > > Random UUIDs as primary keys in databases have bad write amplification > properties. (example: > https://github.com/uuidjs/uuid/issues/303#issuecomment-575992079) A > timestamp provides locality in database indexes as well as a useful natural > order in the database. As as you point at in [1], it's trivial to covert between your "version 6" and the V1 UUID --- it's just a matter of swapping the bytes. [1] http://gh.peabody.io/uuidv6/ As it happens, I'm aware of at least one large enterprise application which swaps the bytes before storing a UUID into a database, because it uses the UUID's for keys in its system. In fact, it's *because* of this application that the Linux implementation of libuuid has an optional-to-run uuidd helper daemon: 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. This was implemented in 2007 because this particular large enterprise application (used in many Fortune 100 companies) needs a *huge* number of UUID when doing its initial database setup. But the point is they did this as a storage issue --- it's how they fold, spindle, and mutilate the UUID before they store it into the database and use it as a key. There is no need to define a new UUID version for this hack, since it's so easy to transform a v1 UUID into a more database-friendly format and back again. You can just treat it as an internal implementation detail of how the UUID is stored and lookups performed in the database. > I agree this is not a terribly complex problem and some applications can > just read from /dev/urandom and be done with it. But I also believe the > above concerns are real and affect a lot of real-world applications. /dev/urandom is a Linux specific thing. The better choice is libuuid. The libuuid library is installed on all Linux systems, so they can just link with -luuid and use uuid_generate(). It's also installed on MacOS systems (I changed the license to make it more accepted for MacOS) and since it is required by GNOME, it's generally available on all of the *BSD ports. So for most applications, the best way to go is to use uuid_generate() and link with -luuid. That's going to be more portable and more secure. - Ted
