<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div id="x_compose-container" itemscope="" itemtype="https://schema.org/EmailMessage" style="direction:ltr">
<span itemprop="creator" itemscope="" itemtype="https://schema.org/Organization"><span itemprop="name"></span></span>
<div>
<div>
<div style="direction:ltr">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.</div>
<div><br>
</div>
<div style="direction:ltr">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.</div>
<div><br>
</div>
<div style="direction:ltr">Gruss</div>
<div style="direction:ltr">Bernd</div>
</div>
<div><br>
</div>
<div class="x_acompli_signature">
<div style="direction:ltr">Gruss</div>
<div style="direction:ltr">Bernd</div>
<div style="direction:ltr">-- </div>
<div style="direction:ltr">http://bernd.eckenfels.net</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> core-libs-dev <core-libs-dev-bounces@openjdk.java.net> on behalf of Gustavo Romero <gromero@linux.vnet.ibm.com><br>
<b>Sent:</b> Wednesday, June 20, 2018 2:59:47 AM<br>
<b>To:</b> core-libs-dev; security-dev<br>
<b>Cc:</b> vladimir.kozlov@oracle.com; Doerr, Martin<br>
<b>Subject:</b> RFC: Add new JCA provider to support hardware RNGs</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi,<br>
<br>
Please, could I get comments on the following change?<br>
<br>
Since it's related to security, I would be glad if security<br>
experts could also comment on that.<br>
<br>
webrev: <a href="http://cr.openjdk.java.net/~gromero/POWER9/darn/v6_rebased/">http://cr.openjdk.java.net/~gromero/POWER9/darn/v6_rebased/</a><br>
<br>
It introduces a way to get benefits from hardware instructions in userspace<br>
that can delivery a random number and so be used to speed up and avoid<br>
blocking in some SecureRandom methods, notably generateSeed() and<br>
nextBytes(), without loosing the random number quality. Particularly on<br>
Power, the new POWER9 CPUs introduced a hardware instruction called 'darn'<br>
that can be used for that purpose.<br>
<br>
The main idea is to add a new JCA provider called "HWTRNG" (if no better<br>
name is suggested), adding new helper methods that can then be intrinsified<br>
and that will be used by generateSeed() and nextBytes(). In that sense,<br>
this change also adds the proper mechanisms in the Interpreter,<br>
C1 Compiler, and C2 compiler (for PPC64, but also paving the way for other<br>
platforms) to intrinsify these helper methods that will be used in the end<br>
by generateSeed() and nextBytes() methods. The added helpers are:<br>
<br>
byte[] getRandomSequence0(int)<br>
byte[] getRandomSequence1(byte[])<br>
long validRandomLong(void)<br>
long randomLong(void)<br>
<br>
The helpers also take care of checking if the returned random number is<br>
valid and attempt 10 times (as recommended by ISA) get a valid random<br>
number before falling back to a software alternative (HWTRNG is based<br>
mostly on JCA provider NativePRNG and so the fall back mechanism will use<br>
the exactly same methods found in NativePRNG and hence behave similarly.<br>
Nonetheless, in my experience such a hardware failures (which are the main<br>
cause of a returned invalid random number) are quite rare: in my tests I<br>
was never able to exhaust the HW RNG and force it to generate an invalid<br>
random number).<br>
<br>
The user, besides having to specify explicitly the use of a non-default<br>
provider (HWTRNG), will have to unlock the VM experimental options to<br>
effectively use the hardware RNG as an unique random source by passing<br>
options "-XX:+UnlockExperimentalVMOptions -XX:+UseRANDOMIntrinsics".<br>
<br>
On Power, for the Interpreter and C1 Compiler, besides avoiding the<br>
blocking effect of a low entropy on /dev/random, I was able to get about<br>
126 Mbps (3x higher than the version without 'darn') on generaSeed() and<br>
nextBytes(). The maximum theoretical value on a POWER9 machine is usually<br>
128 Mbps.<br>
<br>
I'll address the details about the file headers (Copyright, dates, authors,<br>
versions, etc) after I get some feedback about this change.<br>
<br>
<br>
Thanks in advance.<br>
<br>
Best regards,<br>
Gustavo<br>
<br>
</div>
</span></font>
</body>
</html>