Re:SCRU128: Sortable, Clock and Random number-based Unique i...
by throwaway81523 on Thursday April 21, 2022 @07:40PM
(#31116534)
> SCRU128 gives some random bits a longer life to reduce the number of random number generation per a unit of time. As a result, even if each of multiple generators generates a million IDs at the same millisecond, no collision will occur as long as the random numbers generated only once per second (per_sec_random) differ.
This is perplexing and I'd like to see the assumptions spelled out about how many such generators will run at the same time. If there are 1000s of generators, that almost guarantees occasional free collisions in the per-second field. If two such colliding generators each make a million ID's in the same millisecond, that basically guarantees full 72-bit collisions. Plus the monotonically increasing counter field can be a technical challenge in its own right. If you can generate those reliably and want to make the uuid's opaque to attackers, you might as well just encrypt a 64-bit monotonic counter with a 128 bit block cipher, with your db able to decrypt the counter for indexing purposes.
This is perplexing and I'd like to see the assumptions spelled out about how many such generators will run at the same time. If there are 1000s of generators, that almost guarantees occasional free collisions in the per-second field. If two such colliding generators each make a million ID's in the same millisecond, that basically guarantees full 72-bit collisions. Plus the monotonically increasing counter field can be a technical challenge in its own right. If you can generate those reliably and want to make the uuid's opaque to attackers, you might as well just encrypt a 64-bit monotonic counter with a 128 bit block cipher, with your db able to decrypt the counter for indexing purposes.