On Sep 3, 2013, at 7:14 AM, Bradford Wetmore <bradford.wetm...@oracle.com> wrote: > Bill also wrote in that email: > > > add the following method to BigInteger > > public boolean isProbablePrime(int certainty, Random end) , > > which allows primality testing with arbitrary Random objects. > > In many cases, using a well seeded normal Random object will work > > just fine, and this will give users the ability to provide their own > > Random objects > > This sounds like a very good solution to me. That way someone can decide > whether they want to take the hit with SecureRandom, or if Random is good > enough. >
Yes. > Paul Sandoz wrote: > > > I don't know about the PRNG requirements for Miller-Rabin but the > > changes to TLR in review might be a possible substitute for SR in > > this case, since TLR will be updated to use the same PRNG algorithm > > as SplittableRandom, which passes DieHarder tests. Otherwise, i > > think we may just be stuck with SR. > > In my brief read of the Miller-Rabin tests, it just selects several random > values to use for guessing whether another number selected by a different > random number generator is prime or not. Given initial seed values (i.e. one > not set via new Random(seed) constructor), manipulating the Random > implementation to ensure a steady stream of strong liars seems rather > difficult. > > In addition we run a secondary test which reduces that attack surface > (LucasLehmer). > > So offhand, I wouldn't commit to saying if SecureRandom is necessary or not, > but it wouldn't surprise me. > My intuition is that the new algorithm for TLR might be sufficient as input to this Monte-Carlo algorithm, but i don't have any hard empirical data. > Paul Sandoz wrote: > > > Perhaps it would also allow us to deprecate Random in a future JDK? > > SecureRandom is a subclass of Random, so I'm wondering how it will be > perceived to have the "secure" version based on a deprecated base class. Yeah there is a PR thing that would have to be managed :-) Paul. > I know the underlying implementations are *COMPLETELY* different, but I've > been working with this code for a while now. >
