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 >
