Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks

[Mike Duigou]

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