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

Brian Burkhalter brian.burkhalter at
Sat Aug 24 00:10:56 UTC 2013

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.
> - 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():
 925                 protected Random initialValue() {
 926                     return new;
 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.


> Urging extreme caution,

Thanks for the comments.


More information about the core-libs-dev mailing list