Initializing Secure Random (Reprise)

[roger riggs]

Hi Peter,

Thanks for the update, I'm just getting up to speed on this and had help 
correcting
the bug description and linking to the history from the earlier 
discussions in June.

The static initializations of SecureRandom contribute to the large 
number of classes
loaded even for the trivial program so it may be useful to delay them so
the most trivial default use of SecureRandom does not load them immediately.

Roger


On 11/25/2014 6:37 PM, Peter Levart wrote:
> Hi Roger,
>
> I see the 8060435 bug already talks about that possible solution too.
>
> I agree with Paul that a public static method on SecureRandom would be 
> better for JDK9. Or maybe even some new class in java.util, which 
> would implement just the interface to native /dev/urandom on Unixes 
> and MSCAPI on Windows (without any SHA1 mixing or such) and make java 
> security SeedGenerator depend on that rather than the other way around 
> (where TLR/SplittableRandom depend on java security). I think this is 
> better from modularization standpoint too.
>
> In case of a new java.util class (what about a method on 
> java.lang.System?) the code (together with native part on Windows) 
> could just be copied from (Native)SeedGenerator where it is already 
> tried and tested. Then NativeSeedGenerator would just become a facade 
> for invoking java.util/java.lang.System method.
>
> Regards, Peter
>
> On 11/26/2014 12:15 AM, Peter Levart wrote:
>>
>> On 11/24/2014 09:46 PM, roger riggs wrote:
>>> Hi,
>>>
>>> This topic has languished for a bit and could use a bit of expertise 
>>> from
>>> Windows developers.
>>>
>>> The improvements in entropy for initializing Secure Random in JDK 8 
>>> have
>>> some negative attributes that affect maintainability, robustness and 
>>> performance[1].
>>> The dependency on networking, can in some OS's and configurations lead
>>> to increased startup times and issues with bootstrapping the Java 
>>> runtime.
>>>
>>> Martin has proposed[2] an alternative for Linux based on /dev/urandom
>>> with a fallback to a simpler algorithm if /dev/urandom is not 
>>> available.
>>>
>>> Since /dev/urandom is not native to Windows, it seems prudent to 
>>> identify
>>> a corresponding source of entropy data.
>>>
>>> What are the recommended ways on Windows to get seeds for random?
>>> Please suggest one or more ways to initialize SecureRandom
>>
>> Hi Roger,
>>
>> Do you mean SecureRandom or ThreadLocalRandom/SplittbleRandom, since 
>> the 8060435 talks about the later two ?
>>
>> As Bernd identified, the Windows equivalent to /dev/urandom is MSCAPI.
>>
>> 5 months ago I made an attempt to expose a part of contained internal 
>> java security API to get access to /dev/urandom based and MSCAPI 
>> based seed generators. Here's the thread with the discussion:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027256.html
>>
>> The minimal patch was the following:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR_SR_SeedGenerator/webrev.01/
>>
>> Regards, Peter
>>
>>>
>>> Thanks, Roger
>>>
>>> p.s. Sorry to be covering old ground but I don't have all the context.
>>>
>>>
>>> [1] 8060435  SecureRandom initialization latency on Windows
>>> https://bugs.openjdk.java.net/browse/JDK-8060435
>>>
>>> [2] 
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ThreadLocalRandom-system-entropy/
>>
>