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

[Peter Levart]

Hi Brad,

On 01/01/2015 02:46 AM, Bradford Wetmore wrote:
>
>>> To the actual proposal:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.03/
>>>
>>> Overall, I'm ok with what's proposed.  This is more straightforward to
>>> parse/understand than trying to adjust NativeSeedGenerator to
>>> create/call directly (e.g. UNIX:  new
>>> NativeSeedGenerator("/dev/urandom") or Windows:  new
>>> NativeSeedGenerator()).  But I'd still like to understand why you
>>> moved away from this.
>>>
>>> One concern is that you're duplicating native libraries in java.base,
>>> and it would be the third JDK library overall with this type of call.
>>> There's one in libjava (for java.base/WinCAPISeedGenerator for
>>> sun.security.provider.NativeSeedGenerator) and sunmscapi (for
>>> jdk.crypto.mscapi/SunMSCAPI/sun.security.mscapi).  Would it work to
>>> tweak the WinCAPISeedGenerator so you don't have to create a new dll
>>> for java.base?
>>
>> The SystemRandom JNI bindings for Windows are located in:
>>
>>      java.base/windows/native/libjava/SystemRandomImpl_md.c
>>
>> ...so as I understand they are also part of libjava. No new DLL here.
>
> True.  My thought should have been about having very similar code 
> duplicated in libjava.
>
> I'm ok with this, though it's not really clear if/when MS will drop 
> support for ADVAPI32!RtlGenRandom.  This always makes me nervous 
> because whatever is put in will likely never change until some MS 
> change breaks it.

the Microsoft C Runtime Library makes use of this function in its 
implementation of "rand_s", so it's removal would break a lot of 
programs. I think this is a relative guarantee that the function is here 
to stay.

>
>
>>> What are the fallbacks for SystemRandomImpl if /dev/urandom or the
>>> rtlGenRandomFN/CryptGenRandom aren't available?  Is that something
>>> you'll bake into TLR or will you do it here?
> >
>> I think it's better to leave it to consumers (TLR/SplittableRandom) as
>> they know what's good-enough for them. The API allows for arbitrary
>> number of bytes to be generated and I don't have an easy means of
>> generating more than 8 "random" bytes just from System.nanoTime() and
>> System.currentTimeMillis() short of using SecureRandom as a fall-back.
>
> webrev.03 only has new code, no changes yet to TLR/SplittableRandom, 
> so I'm not yet quite following where TLR/SR will be changing.  Also, 
> what is proposed for platforms that aren't Unix/Windows?  Should there 
> be a generic fallback mechanism like ThreadedSeedGenerator?  (Note, 
> I'm not suggesting using it, it's rather...SSLLLOOOWWWW...)

Are there other non-Unix and non-Windows platforms? I think the planned 
fall-back for TLR/SplittableRandom is to just use 
System.currentTimeMillis() & System.nanoTime() - these are the defaults 
now unless SecureRandom is requested.


Regards, Peter