4 ms·
When you need to generate IDs that don't reveal when they were generated.
by vore 3y ago
When you need to generate IDs that don't reveal when they were generated.
- vbezhenar 3y agoFor this case just add random(0, 2^128/N) to the previous UUID. N*2 is average number of ascending UUIDs you want to maintain for database performance. If N is low enough (like 1024), database will be happy and UUIDs will be pretty random and won’t reveal much. There won’t be global ordering, but it leaks timing information in one way or another, anyway.
- hn_throwaway_99 3y agoThe ascending order of IDs though is a great property that is used in other contexts. I.e. for many of our workflow processes we want queries to return reverse chronological order, and "ORDER BY id DESC" is our most common sort. A v7 UUID as a primary key is still great for that, so you'd usually want to keep that property.
- JdeBP 3y agoDaniel J. Bernstein addressed this the 1990s: * Construct a tuple of the current TAI64NA time, the process ID, some other IDs, and a sequence number. * Encrypt this 384-bit tuple with a 1024-bit secret using SURF. * The 256-bit result is the ID. https://github.com/bruceg/ezmlm-idx/blob/master/lib/surf.3 https://github.com/bruceg/ezmlm-idx/blob/master/lib/surf.3 One could adapt this approach to UUIDs.
- tadfisher 3y agoThis eliminates the primary benefit of V7 UUIDs, which is that keys sort temporally, which is almost always the same as the insertion order of a database table (or most collection-like data structures(
- JdeBP 3y agoBut satisfies, as v7 does not satisfy, the actually stated constraint of "IDs that don't reveal when they were generated" whilst still using timestamps, no permanent IDs from hardware, and no centralized ticket-issuing mechanism for sequence numbers. There is more than one feature of v7, and the top of this sub-thread started a discussion of how one would trade them for better security.