Should I seed a SecureRandom?

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.


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

Tags:

Java

Random

Recent Posts