SecureRandom with NativePRNG vs SHA1PRNG

I need to generate cryptographically strong random numbers and byte arrays. For this purpose, I'm using Java's SecureRandom class. But I'm not sure to choose which PRNG algorithm in terms of their cryptographic strength.

Which of the following instances generates a more unpredictable numbers? Or are they equal?

SecureRandom nativePrng = SecureRandom.getInstance("NativePRNG")
SecureRandom sha1Prng = SecureRandom.getInstance("SHA1PRNG")

Moreover, we are able to generate these instances with "SUN" provider (e.g. SecureRandom.getInstance("SHA1PRNG", "SUN")). Do this make a difference?

Thanks in advance.

回答1:

TL;DR: Use new SecureRandom() when you're not sure and let the system figure it out. Possibly use SecureRandom.getInstanceStrong() for long term key generation.

Do not expect a random number generator to generate a specific output sequence within a runtime application, not even if you seed it yourself.

With random number generators it is always hard to say which is best. Linux and most Unixes have a pretty well thought out random number generator, so it doesn't hurt to use /dev/random or /dev/urandom, i.e. "NativePRNG". Problem with using /dev/random is that it blocks until enough entropy is available. So I would advice against it unless you've got some special requirements with regards to key generation.

"SHA1PRNG" uses a hash function and a counter, together with a seed. The algorithm is relatively simple, but it hasn't been described well. It is generally thought of to be secure. As it only seeds from one of the system generators during startup and therefore requires fewer calls to the kernel it is likely to be less resource intensive - on my system it runs about 9 times faster than the "NativePRNG" (which is configured to use /dev/urandom). Both seem to tax only one core of my dual core Ubuntu laptop (at a time, it frequently switched from one core to another, that's probably kernel scheduling that's which is to blame). If you need high performance, choose this one, especially if the /dev/urandom device is slow on the specific system configuration.

Note that the "SHA1PRNG" present in the retired Apache Harmony implementation is different from the one in the SUN provider (used by Oracle in the standard Java SE implementation). The version within Jakarta was used in older versions of Android as well. Although I haven't been able to do a full review, it doesn't look to be very secure.

EDIT: and I wasn't half wrong about this, SHA1PRNG has been shown not to be pseudo-random for versions < 4.2.2 and more here.

Beware that "SHA1PRNG" is not an implementation requirement for Java SE. On most runtimes it will be present, but directly referencing it from code will make your code less portable.

In general it's not a good idea to require a specific provider either. Specifying a provider may hurt interoperability; not every Java runtime may have access to the SUN provider for instance - Android certainly hasn't. It also makes your application less flexible at runtime, i.e. you cannot put a provider higher in the list and use that instead.

So only indicate a provider if you are dependent on one of the features that it supplies. For instance, you might want to specify a provider if you have a specific hardware device that generates the randoms, or a cryptographic library that has been FIPS certified. It's probably a good idea to make the algorithm/provider a configuration option for your application if you have to specify a provider.

The idea of not specifying a provider is also present in this Android developer Security Blog.

So try and refrain from choosing any specific random generator. Instead, simply go for the empty argument constructor: new SecureRandom() and let the system choose the best random number generator. It is possible to use the new configurable SecureRandom.getInstanceStrong() in Java 8 and higher if you have any specific requirements for e.g. long term key generation.

Don't cache instances of SecureRandom, just let them seed themselves initially and let the VM handle them. I did not see a noticeable difference in operation.

When not to use SecureRandom at all:

As a general warning I strongly advice against using the random number generator for anything other than random number generation. Even if you can seed it yourself and even if you choose Sun's SHA1PRNG, don't count on being able to extract the same sequence of random numbers from the random number generator. So do not use it for key derivation from passwords, to name one example.

If you do require a repeating sequence then use a stream cipher and use the seed information for the key and IV. Encrypt plaintext consisting of zeros to retrieve the key stream of pseudo random values. Alternatively you could use a extendable-output function (XOF) such as SHAKE128 or SHAKE256 (where available).

You may want to consider a different, non-secure random number generator instead of SecureRandom if the available RNG's deliver insufficient performance and if security is not an issue. No SecureRandom implementation will be as fast as non secure random number generators such as the Mersenne Twister algorithm or the algorithm implemented by the Random class. Those have been optimized for simplicity and speed rather than security or quality.

回答2:

As from a ref. here:

Native PRNG implementation for Solaris/Linux. It interacts with /dev/random and /dev/urandom, so it is only available if those files are present. Otherwise, SHA1PRNG is used instead of this class.

The SUN provider might be used as default (mainly dependent on the order of the provider which is present).