If you create a new instance of SecureRandom with the default constructor, you get an instance of the SHA1PRNG that hasn't been seeded with anything but a constant value. As a result, if you repeatedly run the attached test case, you will get the same output each time; on other VMs, the SecureRandom you get is seeded with some random value. This has security implications. If some application is relying on a default SecureRandom to be seeded with random data, they will in fact be using an unseeded one, and the output of an unseeded PRNG is completely guessable. Sun-derived VMs use the security property `securerandom.source' and the system property `java.security.egd' to control where to look for random bits to get a seed. By default, the former points to `/dev/random,' and is accompanied by the comment: # On Windows systems, the URL file:/dev/random enables use of the # Microsoft CryptoAPI seed functionality. We should at least try to use `/dev/[u]random' on Unix systems. Also, SHA1PRNG is a good, but not great random number generator. We have an implementation of Yarrow in Classpath, which may be a better choice for our default algorithm.
Created attachment 11240 [details] SecureRandom test Attached SecureRandom test file. Run this multiple times on jamvm or GCJ, and note that the output is the same on each run. Also, Classpath contains an implementation of Fortuna, not Yarrow. But my recommendation still stands.
The situation is a bit different: according to the spec, we need to seed the instance if it is not seeded by the caller. To quote the Javadoc for the default SecureRandom constructor: "Note that this instance of SecureRandom has not been seeded. A call to the setSeed method will seed the SecureRandom object. If a call is not made to setSeed, the first call to the nextBytes method will force the SecureRandom object to seed itself." The same is true for SecureRandom objects created through the `getInstance' factory methods.
*** This bug has been marked as a duplicate of 24642 ***