Should I seed a SecureRandom?

Question

Found the following code in our code base:

public static final int DEFAULT_LENGTH = 16;
private static SecureRandom SR;
static
{
   try
   {
      SecureRand         


        

Answer 1

Just an addendum to this answer. According to Google, if you are using this code in android you should definitely seed the SecureRandom using a high entropy source like /dev/urandom or /dev/random.

Even the post below is an year old now, perhaps this has already been corrected but I couldn't confirm if it was.

https://plus.google.com/+AndroidDevelopers/posts/YxWzeNQMJS2

EDIT:

It seems that the default behavior of the class is now the one specified in the post so seeding is again deemed unnecessary:

http://developer.android.com/reference/java/security/SecureRandom.html

Answer 2

I think this is completely unneccessary, because as the Javadoc you quote clearly states: Default-constructed SecureRandom instances seed themselves. The person who wrote this probably didn't know that.

They might also actually decrease security by forcing a fixed seed length that could be less-than-ideal for the RNG implementation.

Finally, assuming the snippet is posted unaltered, the silent exception swallowing isn't very good coding style either.

Answer 3

Sad, that javadoc does not say, what the minimum seed size "DEFAULT_LENGTH" is to reach the intended security level of algorithm design, not even for some default implementation. :(

Essentially security depends on true random; there is nothing like "an algorithm seeding itself without exterior data". Unless the inputs of a seed generator are revealed, it is not possible to certify any security level.

Providers of true random are 1.) https://www.random.org/ 2.) Tools as VeraCrypt derive white noise from mouse motion.

If your goal is real security, you will combine numbers from anonymous random generators with self-cerified white noise.

Answer 4

This is not only completely unnecessary, it may actually increase the predictability of the numbers generated by the SecureRandom object.

A SecureRandom that does not have an explicit seed set will self-seed. It uses a highly random data source to perform this operation, and is quite secure. The first SecureRandom in your code sample will use such a seed.

The second is seeded from the first by producing 256 random bits. Assuming the system-default SHA1PRNG is used, this is good enough. It uses 160 bits of state, so 256 random bits will completely satisfy it's requirements. But assume now somebody decides this isn't enough, and switches the default to a SHA512PRNG (they can do this without even looking at your code by changing java's security properties). Now you're providing too few seed bits to it: only half as many as it needs.

Get rid of it, and just use the self-seeded object, unless you have a better source of seed data than the system has available.

Answer 5

Avoid using the default algorithm which is the case when doing new SecureRandom();

Instead do:

SecureRandom.getInstance("SHA1PRNG", "SUN");

If someone changes the default algorithm (as stated by @Jules) you won't be impacted.

---

Edited for Android:

For android, take a look at :

• https://android-developers.googleblog.com/2016/06/security-crypto-provider-deprecated-in.html
• http://www.infosecisland.com/blogview/24773-Android-N-Deprecating-Crypto-Provider-and-SHA1PRNG-Algorithm.html
• https://security.stackexchange.com/questions/128144/android-n-security-crypto-provider-is-deprecated
• Security "Crypto" provider deprecated in Android N

On Android, we don’t recommend specifying the provider. In general, any call to the Java Cryptography Extension (JCE) APIs specifying a provider should only be done if the provider is included in the application or if the application is able to deal with a possible ProviderNotFoundException.

...

in Android N we are deprecating the implementation of the SHA1PRNG algorithm and the Crypto provider altogether