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