SecureRandom gotcha

If you need a random number you are usually advised to use SecureRandom because it gives a cryptographically secure random number.

Typical way of calling SecureRandom would be:

From a random generator seeding perspective this is also the correct way. You might be tempted to call the setSeed in order to seed with some long that you provide. Resist that temptation unless you can prove that the seed obeys the constraints of your application (like that it is different between different instantiations and invocations of SecureRandom). And no, seeding with the System.currentTimeMillis() will not work: multiple threads can get the same value.

Here’s an excerpt from the setSeed documentation:

The interesting part here is that it says that the seed “supplements” the internal seed. This is not what I found. The given seed will completely replace the internal seed. This means that when seeded the same way two SecureRandom will return the same value. Probably not what you would expect.