Hi Bernd, Thanks for your comments.
On 06/20/2018 05:05 PM, Bernd Eckenfels wrote:
Just a FYI under Linux when you read from urandom the Linux kernel will always XOR with random bytes generated with x64 rdrand instruction (arch_get_random_lomg() - if supported). Since it is a XOR it does not have to trust the quality of this black box hardware implementation.
Yes, I know to some extent how the use of rdrand on Intel by Linux generated debates in the past.
I would not implement a generator which does not have its own software whitening. (And most likely there is no need for one different than urandom on Linux). If you do implement whitening I would use a DRBG construction and no longer use a (low state) SHA1PRNG.
My main concern to use 'darn' on Power was to get some additional speed and throughput on obtaining true random numbers (or on cases where /dev/random - which blocks - was preferred to /dev/urandom). That concern seems valid specially when the code is not JITed yet by the C2 compiler (so for Interpreted and C1 Compiler). Anyway, the idea to have a separated provider and that the use of the intrinsic is by no means enabled by default is to let the user to decide if he/she wants to use that kind of generator. I think OpenSSL disabled by default the use of rdrand similarly but let the user to enable it if desired? The idea of DRBG looks valid. I took SHA1PRNG as a fallback. But if DRBG would be used for whitening that would need a seed from /dev/urandom? (I'm trying to think the impact on performance here). Best regards, Gustavo
Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> on behalf of Gustavo Romero <grom...@linux.vnet.ibm.com> Sent: Wednesday, June 20, 2018 2:59:47 AM To: core-libs-dev; security-dev Cc: vladimir.koz...@oracle.com; Doerr, Martin Subject: RFC: Add new JCA provider to support hardware RNGs Hi, Please, could I get comments on the following change? Since it's related to security, I would be glad if security experts could also comment on that. webrev: http://cr.openjdk.java.net/~gromero/POWER9/darn/v6_rebased/ It introduces a way to get benefits from hardware instructions in userspace that can delivery a random number and so be used to speed up and avoid blocking in some SecureRandom methods, notably generateSeed() and nextBytes(), without loosing the random number quality. Particularly on Power, the new POWER9 CPUs introduced a hardware instruction called 'darn' that can be used for that purpose. The main idea is to add a new JCA provider called "HWTRNG" (if no better name is suggested), adding new helper methods that can then be intrinsified and that will be used by generateSeed() and nextBytes(). In that sense, this change also adds the proper mechanisms in the Interpreter, C1 Compiler, and C2 compiler (for PPC64, but also paving the way for other platforms) to intrinsify these helper methods that will be used in the end by generateSeed() and nextBytes() methods. The added helpers are: byte[] getRandomSequence0(int) byte[] getRandomSequence1(byte[]) long validRandomLong(void) long randomLong(void) The helpers also take care of checking if the returned random number is valid and attempt 10 times (as recommended by ISA) get a valid random number before falling back to a software alternative (HWTRNG is based mostly on JCA provider NativePRNG and so the fall back mechanism will use the exactly same methods found in NativePRNG and hence behave similarly. Nonetheless, in my experience such a hardware failures (which are the main cause of a returned invalid random number) are quite rare: in my tests I was never able to exhaust the HW RNG and force it to generate an invalid random number). The user, besides having to specify explicitly the use of a non-default provider (HWTRNG), will have to unlock the VM experimental options to effectively use the hardware RNG as an unique random source by passing options "-XX:+UnlockExperimentalVMOptions -XX:+UseRANDOMIntrinsics". On Power, for the Interpreter and C1 Compiler, besides avoiding the blocking effect of a low entropy on /dev/random, I was able to get about 126 Mbps (3x higher than the version without 'darn') on generaSeed() and nextBytes(). The maximum theoretical value on a POWER9 machine is usually 128 Mbps. I'll address the details about the file headers (Copyright, dates, authors, versions, etc) after I get some feedback about this change. Thanks in advance. Best regards, Gustavo
