RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom
peter.levart at gmail.com
Thu Jan 1 21:25:53 UTC 2015
On 01/01/2015 02:46 AM, Bradford Wetmore wrote:
>>> To the actual proposal:
>>> 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:
>> ...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
>>> 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.
More information about the core-libs-dev