Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks)

[Paul Sandoz]

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

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