RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

[Doug Lea]

On 12/04/2014 04:40 AM, Paul Sandoz wrote:
>
> There is already a mechanism to create a cryptographically strong seed by
> setting a system property and using SecureRandom. That has a high
> initialization cost, but i think under those circumstances that cost is
> acceptable (it may well be possible to reduce that cost but i consider that
> to be a separate issue).
>
> For the default case what we need is something with low initialization cost
> that is *good enough* for the majority of cases e.g. documents the lower
> bound of cryptographic strength.

Further, in these cases, we are not concerned about cryptographic strength
in terms of algorithmic unpredictability by attackers. The default
constructor methods promise only to use a seed that is highly
likely to differ across invocations, including those of different programs
running on different machines. Using initial system seeds that include
some environmental entropy is the best way to get the first seed.
It just so happens that crypto-based RNGs need to do this as well,
so we use the cheapest forms of them that we can (or just use a time
based seed on failure). Good-quality PRNG techniques produce
more default-constructor seeds after the first one.
Because Random, SplittableRandom, and ThreadLocalRandom all use the
same basic approach, they can/should use the same mechanism.
Placing the mechanics in TLR seems to work out best.
In which case only TLR needs a static atomically updated seed
initialized from system seed, further reducing static init overhead.
I think I've convinced myself that this is the most promising approach,
so hope to try it out based on Peter's versions some time in
the next few days.

Relately, Guy Steele and I have been sporadically investigating
minor algorithmic and implementation improvements for SR and TLR
(including systematic tests of more than 2500 variants). I suspect
that we will settle on one of these sometime in the next few months.

(Also, at some point we might reconsider our cowardice about not
improving the internal java.util.Random algorithm. j.u.Random is
much more commonly used, and does not fare well on quality tests.
On the other hand, the more that users instead choose to use
SR or TLR, the better.)

-Doug