On Aug 23 2013, at 17:10 , Brian Burkhalter wrote: > > On Aug 23, 2013, at 5:06 PM, Mike Duigou wrote: > >> I would strongly recommend holding back on this change until someone >> familiar with the crypto implications takes a look at it. Unfortunately >> neither the random constructor nor probablePrime indicate any expectations >> regarding the quality of random numbers needed from the offered PRNG.
Should we be offering advice regarding the random number generator in the API docs? >> >> - Changing a SecureRandom to a regular non-crypto PRNG causes alarm bells >> for me. It also surprises me that a method named getSecureRandom() doesn't >> return a SecureRandom instance! I am not sure to what extent the MillerRabin >> method actually needs a secure random number generator. > > It is still a SecureRandom(): DOH. I somehow read this as using the new ThreadLocalRandom class. Sorry about the panic. I would still change the return type of getSecureRandom() and threadRandom's type to SecureRandom. > 925 protected Random initialValue() { > 926 return new java.security.SecureRandom(); > 927 } >> - I ran out of time looking but what public code path results in >> getSecureRandom() being called? The public methods which take a Random don't >> seem to allow it to be null. > > isProbablePrime(int). > > > Thanks for the comments. > > Brian