CODEWITHSUNDEEP
linuxjavarandom
PJ1
PJ1

Reputation:

Repeated set of UUIDs from java's UUID.randomUUID()

We have observed that set of almost 200,000 UUIDs has replayed two months apart, and I'm wondering if anyone has seen anything similar.

The UUIDs are generated using UUID.randomUUID(). In digging into this (looking at java source), randomUUID() uses SecureRandom() under the hood, which in turn is using NativePRNG. It is my understanding that NativePRNG uses /dev/urandom to acquire its seed. The implication of course is baffling - that somehow /dev/urandom returned the same seed to NativePRNG two months apart. From what I can tell, once instantiated the PRNG does not re-seed. This is a long running job which s listening for messages and using a UUID as an ID for it. The pseudocode is simply:

< receive message> String uuid = UUID.randomUUID().toString(); String fname = h.composeArtifact(uuid);

The OS is Centos 6, on an AWS EC2 instance running JDK1.6. Is this something that anyone has seen/experienced in the past? Seems like the kind of thing that should 'never happen'...

Upvotes: 10

Views: 5690

Answers (1)

Thomas Pornin
Thomas Pornin

Reputation: 74382

From JDK 1.6 source, indeed, UUID.randomUUID() feeds on a java.util.SecureRandom instance. If you got a repeated sequence of UUID, then either you got very lucky (or very unlucky, depending on your point of view), or someone played with VM snapshots, or there is something fishy in your Java configuration.

When taking a VM snapshot, you record the complete live state of the machine, processes and RAM included. If there was a live process with an already instantiated SecureRandom instance, restoring the snapshot will bring back that state, so the sequence of random values output by that SecureRandom will be the same each time a restore occurs, until the SecureRandom reseeds itself from /dev/urandom (/dev/urandom continuously gathers "random" physical events, but these won't impact the SecureRandom state until the next reseeding).

The Java configuration may impact SecureRandom, in that SecureRandom is NOT a PRNG, but a shell around an instance of SecureRandomSpi provided by a duly registered cryptographic provider. Sun's JDK comes with a default implementation that normally feeds on the system's resources (/dev/urandom on Linux). However, this can be configured; lookup the java.security.egd system property, and also the securerandom.source property in the java.security file. The default provider may also be replaced altogether with an alternate implementation that does things differently (and possibly very poorly). See this answer for some details. Verifying what random source is indeed used can be a bit complex, but you could try launching your process with strace, which will show system calls, hence whether /dev/random or /dev/urandom is opened at some point.

If your Java configuration is fine, and there was no game with VM snapshots, and you are sure that you indeed got the same sequence of UUID as previously, then you really really should have bought a Powerball ticket instead (but I do not honestly believe in this scenario).

Upvotes: 21

Related Questions