Is SecureRandom thread safe?

JavaThread Safety

Java Problem Overview


Is SecureRandom thread safe? That is, after initializing it, can access to the next random number be relied on to be thread safe? Examining the source code seems to show that it is, and this bug report seems to indicate that its lack of documentation as thread safe is a javadoc issue. Has anyone confirmed that it is in fact thread safe?

Java Solutions


Solution 1 - Java

Yes, it is. It extends Random, which always had a de facto threadsafe implementation, and, from Java 7, explicitly guarantees threadsafety.

If many threads are using a single SecureRandom, there might be contention that hurts performance. On the other hand, initializing a SecureRandom instance can be relatively slow. Whether it is best to share a global RNG, or to create a new one for each thread will depend on your application. The ThreadLocalRandom class could be used as a pattern to provide a solution that supports SecureRandom.

Solution 2 - Java

The current implementation of SecureRandom is thread safe, specifically the two mutating methods nextBytes(bytes[]) and setSeed(byte[]) are synchronized.

Well, as far as I've been able to tell, all mutating methods are eventually routed through those two methods, and SecureRandom overrides a few methods in Random to ensure that. Which works but could be brittle if the implementation is changed in the future.

The best solution is to manually synchronize on the SecureRandom instance first. This means each call stack will acquire two locks on the same object, but that is usually very cheap on modern JVMs. That is, there is not much harm in explicitly synchronizing yourself. For example:

    SecureRandom rnd = ...;

    byte[] b = new byte[NRANDOM_BYTES];
    synchronized (rnd) {
        rnd.nextBytes(b);
    }

Solution 3 - Java

Please see https://bugs.openjdk.java.net/browse/JDK-8165115 which was fixed in Java 9.

It says:

> SecureRandom objects are safe for use by multiple concurrent > threads. A SecureRandom service provider can advertise that it is > thread-safe by setting the service provider attribute "ThreadSafe" to > "true" when registering the provider. Otherwise, the SecureRandom > class will synchronize access to the following SecureRandomSpi > methods: SecureRandomSpi.engineSetSeed(byte[]), > SecureRandomSpi.engineNextBytes(byte[]), > SecureRandomSpi.engineNextBytes(byte[], SecureRandomParameters), > SecureRandomSpi.engineGenerateSeed(int), and > SecureRandomSpi.engineReseed(SecureRandomParameters).

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionYishaiView Question on Stackoverflow
Solution 1 - JavaericksonView Answer on Stackoverflow
Solution 2 - JavaMatt QuailView Answer on Stackoverflow
Solution 3 - JavaYosephView Answer on Stackoverflow