Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks
Brian Burkhalter
brian.burkhalter at oracle.com
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 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).
> Urging extreme caution,
Thanks for the comments.
Brian
More information about the core-libs-dev
mailing list