[kdps]

My main concern with random-based UUIDs always has been running out of entropy and cause the application to remain in a blocking state (e.g. as described here: https://blog.fastthread.io/2022/03/09/java-uuid-generation-p...). Not due to any negative experiences that I made myself, but due to a particular colleague of mine who sees it as a dealbreaker.

Is this an actual issue? Most people don't seem to care when talking about random UUIDs. The target platform of our applications is mostly Kubernetes on cloud environments, if that makes any difference.

Why I'm asking: UUID Version 7 looks quite interesting to me, and the document describes rand_a and rand_b just as "pseudo-random data"... which made me think that in the context of "uniqueness per millisecond", a source of entropy is conceptually not required. However, chapter 6.6 clearly advises the usage of CSPRNGs, so I guess the overall problem remains :(

[astrange]

“Running out of entropy” is not possible; that’s a property of ancient PRNGs written by confused people.

Even if your PRNG could run out of entropy, rdrand would give it all it needs.

[ciupicri]

From the documentation for java.security.SecureRandom from Java 17 [1]:

> Note: Depending on the implementation, the generateSeed, reseed and nextBytes methods may block as entropy is being gathered, for example, if the entropy source is /dev/random on various Unix-like operating systems.

[1]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base...

[astrange]

Like I said, ancient PRNGs written by confused people.

[yencabulator]

On current day Linux, /dev/random will only block during bootup, never after it has once started.