Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks)
paul.sandoz at oracle.com
Tue Sep 3 08:21:25 UTC 2013
On Sep 3, 2013, at 7:14 AM, Bradford Wetmore <bradford.wetmore at 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.
> 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 :-)
> I know the underlying implementations are *COMPLETELY* different, but I've been working with this code for a while now.
More information about the core-libs-dev