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

Reply via email to