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

[Peter Levart]

On 12/04/2014 12:32 AM, Martin Buchholz wrote:
> On Wed, Dec 3, 2014 at 2:15 PM, Doug Lea <dl at cs.oswego.edu> wrote:
>
>> No public API because systemSeed need only be implemented
>> inside TLR, for its initial seed. Then the others can get their seeds
>> using ThreadLocalRandom.current().nextLong(), unless
>> java.util.secureRandomSeed is set (which I didn't illustrate above).
>> In other words, across all non-secure generators, you only need
>> one system-generated seed.
> That's good enough for seeding other non-cryptographically secure
> PRNGs, but if you want each caller to get a
> cryptographically secure random number, you need to avoid correlations
> between them that would arise when you use a non-CS PRNG to generate
> them from a single CS seed.

Unless java.util.Random is retrofitted to allocate new cryptographically 
secure seed for each new instance. In such case expression:

     new java.util.Random().nextLong()

...could be used to gather secure seed. Perhaps even SplittableRandom 
could allocate new seed from secure source for each new instance (only 
in public constructor - not when it is split()ed)...

What makes those workarounds unsuitable is failure mode. Gathering 
secure seed is inherently coupled with possible failure which must be 
communicated explicitly to the consumer. But one must not be bothered 
with failure in situations where security is not a necessary ingredient.

So for  non-CS PRNGs, cross-seeding is a possible solution, but it's 
nicer for all of them to just use a common (internal) API.

As far as public API is concerned, there already is one: 
SecureRandom.generateSeed(). It's as good as SystemRandom (uses same 
primary means) and has a nice cross-platform fallback 
(ThreadedSeedGenerator). It's only drawback is that it comes with all 
the baggage of security providers (Java and MS Crypto API on Windows). 
But that's ok for user code perhaps.

So what we have here is two desires:
- we want a resource-friendly / with as little dependencies as possible 
way to generate some unique seed, with implicit fall-back which need not 
be secure
- we want a resource-friendly / with as little dependencies as possible 
way to generate secure random bytes that can be pseudo-random, but still 
secure, with explicit failure mode

I'll try to address this dichotomy in the next iteration of the API.

Regards, Peter

P.S. Is anyone interested in generating truly random bytes?

http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf

https://software.intel.com/en-us/tags/35970