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
