SecureRandom Generator on Linux – Blocking or Not Blocking?

1. Introduction

The availability of good-quality random numbers is crucial for all security and cryptographic applications. Usual pseudo-random number generators provide predictable and repeatable sequences.

In contrast, Java SecureRandom uses algorithms that increase randomness by drawing random numbers from external sources. We call this pool an entropy source. However, if such a source is depleted, we can experience slowness or blocking.

In this tutorial, we’ll talk about blocking and non-blocking algorithms in the context of the Linux system.

2. The Default Algorithm

We can create an instance of SecureRandom using the constructor:

SecureRandom secureRandom = new SecureRandom();

The Java Virtual Machine (JVM) then delivers the default algorithm, which is available on any operating system.

The choice depends on the settings in java.security properties file, the JVM option java.security.egd, and existing security providers.

3. Predefined Algorithms

The Java documentation lists standard algorithms that we can use out of the box. We specify a desired algorithm when calling the getInstance() method:

SecureRandom random = SecureRandom.getInstance("NativePRNG");

When asking for a particular algorithm, we can receive the NoSuchAlgorithmException if the requested algorithm isn’t present.

Let’s check all predefined algorithms:

public class SecureRandomAvailableAlgorithms {
    static String [] algorithmNames = {"NativePRNG", "NativePRNGBlocking", "NativePRNGNonBlocking",
     "PKCS11", "SHA1PRNG", "Windows-PRNG"};
    public static void main(String[] args) {
        for (int i = 0; i < algorithmNames.length; i++)
        {
            String name = algorithmNames[i];
            Boolean isAvailable = true;
            try {
                SecureRandom random = SecureRandom.getInstance(name);
            } catch (NoSuchAlgorithmException e) {
                isAvailable = false;
            }

            System.out.println("Algorithm " + name + (isAvailable ? " is" : " isn't") + " available");
        }
    }
}

The output may look like this (on a Linux machine):

Algorithm NativePRNG is available
Algorithm NativePRNGBlocking is available
Algorithm NativePRNGNonBlocking is available
Algorithm PKCS11 isn't available
Algorithm SHA1PRNG is available
Algorithm Windows-PRNG isn't available

4. Linux Notes

The Linux operating system provides two sources of random numbers, /dev/random and /dev/urandom. The former is blocking while the latter is non-blocking.

However, since kernel version 5.19, we don’t need to worry about available entropy. Beyond the early boot stage, we shouldn’t experience blocking during random number generation, regardless we’re using /dev/random or /dev/urandom.

On the other hand, the randomness of the /dev/urandom source became good enough for all practical applications. And it never blocks.

Taking into account the development of the modern Linux system, we can safely use the /dev/urandom device and the corresponding algorithm – NativePRNGNonBlocking.

The above-mentioned changes influenced the way the entropy amount is reported. We can check the entropy_avail kernel parameter for this amount. However, we’ll obtain the same predefined number:

$ sudo sysctl -a | grep entropy_avail
kernel.random.entropy_avail = 256

Therefore, we can ignore the guidelines for older kernel versions, which state that this number should remain at around 2000 or 3000.

5. Performance Test

We can check the performance of algorithms with the Java Microbenchmark Harness (JMH) microbenchmarking framework. We’ll compare NativePRNGBlocking and NativePRNGNonBlocking algorithms.

Let’s generate 20,000 random samples of 256 bytes each:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@State(Scope.Thread)
public class SecureRandomPerformanceTest {

    SecureRandom randomNativePRNGBlocking;
    SecureRandom randomNativePRNGNonBlocking;

    final int NBYTES = 256;
    final int NSAMPLES = 20_000;

    @Setup(Level.Trial)
    public void setup() throws NoSuchAlgorithmException {
        randomNativePRNGBlocking = SecureRandom.getInstance("NativePRNGBlocking");
        randomNativePRNGNonBlocking = SecureRandom.getInstance("NativePRNGNonBlocking");
    }

    @Benchmark
    public void measureTimePRNGBlocking() {
        byte[] randomBytes = new byte[NBYTES];
        for (int i = 0; i < NSAMPLES; i++)
        {
            randomNativePRNGBlocking.nextBytes(randomBytes);          
        }
    }

    @Benchmark
    public void measureTimePRNGNonBlocking() {
        byte[] randomBytes = new byte[NBYTES];
        for (int i = 0; i < NSAMPLES; i++)
        {
            randomNativePRNGNonBlocking.nextBytes(randomBytes);          
        }
    }

    public static void main(String[] args) throws Exception {
        org.openjdk.jmh.Main.main(args);
    }
}

Let’s check the results obtained on Ubuntu 22.04.5 LTS with the 6.8.0 kernel version:

Benchmark                                               Mode  Cnt   Score   Error  Units
SecureRandomPerformanceTest.measureTimePRNGBlocking     avgt   25  95.634 ± 1.769  ms/op
SecureRandomPerformanceTest.measureTimePRNGNonBlocking  avgt   25  95.797 ± 1.097  ms/op

We see that random number generation takes around 96 ms for both the blocking and non-blocking versions. The difference in duration between blocking and non-blocking algorithms is very small, within a measurement error.

6. Conclusion

In this article, we discussed how the SecureRandom algorithms use the randomness sources of the Linux operating system. We focused on the possibility of blocking the source by a low entropy level. However, we learned this was very unlikely on any modern Linux system.

In addition, we carried out a simple comparison test, which didn’t show a significant difference in execution time between blocking and non-blocking algorithms.

Finally, we found that the non-blocking version is sufficient for all practical applications.

As always, the code for the examples is available over on GitHub.