class SplittableRandom

Mike Duigou mike.duigou at
Fri Jul 19 18:00:20 UTC 2013

On Jul 19 2013, at 10:43 , Kasper Nielsen wrote:

> On Fri, Jul 19, 2013 at 5:10 PM, Guy Steele <guy.steele at> wrote:
>> On Jul 19, 2013, at 1:05 AM, Kasper Nielsen <kasperni at> wrote:
>> Thanks so much for your feedback!  Your points are well taken.
>> I agree that this is a problem, and in fact have already looked at ways to
>> get
>> other environmental information to mix into the initial seed.  The problem
>> is making it Write Once, Run Anywhere---what environmental information
>> other than time-of-day is reliably available on all platforms?
> Adding a high quality PRNG that does not have a quality initial default
> seed makes no sense. It is highly unlikely that even power users will be
> able to come up with a better seed than whatever we figure out.
> Using a shared static SecureRandom.generateSeed() to generate the seed is
> probably the easiest way to get a good seed that is portable.
> Or maybe
> can be used in some way. See also this JEP

I have previous experience mucking in this area. Attempting to use SecureRandom will likely encounter order of initialization issues as it is loaded from security providers and is only functional/available very late in the VM boot process. Solutions which use lousy seeding until SecureRandom is available won't be acceptable.

I had considered suggesting adding a vm interface to access the platform native secure random number generation (/dev/random or rand_s). This would be useful for early boot and perhaps for speeding up seeding of SecureRandom.

A mechanism to get entropy very early in VM boot would definitely be useful.


More information about the core-libs-dev mailing list