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

[Peter Levart]

Hi all,

There seems to be a consensus that a simpler static method would be just 
fine, since it will be used only to gather secure seed for other java 
based PRNG implementations. UNIX file as well as Windows Crypro API 
implementation are naturally exposed as open/use/close API, so I did 
that at first. But when experimenting further with Windows, I replaced 
Crypro API's CryptGenRandom function with underlying implementation 
which is RtlGenRandom. This function does not need any crypto provider 
context to be initialized upfront and then closed.

So here's the 2nd approach exposing just a static method:

http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.02/

I moved it to sun.misc as a public class/method. In JDK9 it could be 
exposed via some standard API if desired, by delegating to it. In UNIX 
version I played a little with short-term caching of open file in case 
several invocations are performed one after the other.

Here are the results of the test on 64bit Linux:

SystemRandomTest... (8 bytes / invocation)
1st invocation: 135356 ns, result: [19, -107, -121, -54, 98, 28, -6, 36]
Following 1000000 invocations: 0.648048516 s, (648 ns/invocation)

When open file caching is not used (file is opened/closed for each 
invocation):

SystemRandomTest... (8 bytes / invocation)
1st invocation: 438672 ns, result: [-84, -71, -106, -126, 21, -42, 48, 0]
Following 1000000 invocations: 3.348318113 s, (3348 ns/invocation)

And the results on 32bit Windows 7 (VirtualBox guest on the same Linux 
host):

SystemRandomTest... (8 bytes / invocation)
1st invocation: 388038 ns, result: [-121, -18, -54, 116, -31, 3, 40, -7]
Following 1000000 invocations: 1.027277209 s, (1027 ns/invocation)


The initialization latency on Windows is much lower now.

What we need now is to try this on as much environments as possible. The 
Windows version needs Windows XP/Windows Server 2003 at least 
(RtlGenRandom has been introduced at that time). If the function is not 
found, JVM most probably crashes. The native code should be changed to 
use LoadLibrary/GetProcAddress to load and get the address of the 
function dynamically, so that an exception can be thrown if this fails. 
But I couldn't get a sample program to load the library (Advapi32.dll) 
successfully (although I could find the .dll file in Windows folder).


Regards, Peter


On 12/03/2014 04:26 PM, Doug Lea wrote:
> On 12/02/2014 05:34 PM, Martin Buchholz wrote:
>> I support Peter's initiative and am willing to help review if we have
>> general consensus about the direction.
>>
>
> Peter's implementation scheme of using Unix /dev/urandom
> or the Windows Crypto API (or something else on failure) seems
> like the best options. I don't see why we shouldn't place this
> as a jdk9 public static method in one of the existing random classes
> though (Random, SplittableRandom, ThreadLocalRandom, SecureRandom),
> rather than as separate entity. (If desired, for jdk8 backport,
> it could be non-public, with cheats to access.)
>
> -Doug
>
>
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/
>>>>
>>> The API looks reasonable to me too, I'm just not sure that java.util 
>>> is the
>>> right place and whether it needs to be a Java SE API.
>>>
>>> -Alan
>>
>