“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.
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...
Like I said, ancient PRNGs written by confused people.
Re:New UUID Formats
by yencabulator on Monday June 13, 2022 @12:32PM
(#31727825)
On current day Linux, /dev/random will only block during bootup, never after it has once started.
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 :(