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

[Mike Duigou]

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.

- 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,

Mike


On Aug 23 2013, at 16:41 , Brian Burkhalter wrote:

> 
> On Aug 23, 2013, at 4:39 PM, Brian Burkhalter wrote:
> 
>> With respect to this issue
>> 
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7189139
>> 
>> any comments on this potential fix
>> 
>> file:///Users/bpb/Work/JSL/jdk/jdk8/tl8/jdk/7189139/index.html
> 
> Correction to this webrev link:
> 
> http://cr.openjdk.java.net/~bpb/7189139/
> 
> D'oh.
> 
>> 
>> would be appreciated.
>> 
>> Rudimentary testing with JMH (http://openjdk.java.net/projects/code-tools/jmh/) did not reveal any deleterious performance effects in single-threaded operation nor any obvious improvements in the dual threaded case but testing was done on on my aging Core 2 Duo notebook and is not likely representative of anything approaching real world conditions.
>> 
>> Thanks,
>> 
>> Brian
>