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
