<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body style="background-color: rgb(255, 255, 255); color: rgb(0, 0,
0);" bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 06/24/2014 06:01 PM, Martin Buchholz
wrote:<br>
</div>
<blockquote
cite="mid:CA+kOe0-Ke7JF+HimqL2M8Dr=0c4-ux8YCOMRAZi_3k_su8F8Pw@mail.gmail.com"
type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Jun 24, 2014 at 7:03 AM,
Peter Levart <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:peter.levart@gmail.com" target="_blank">peter.levart@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
I would rather use SecureRandom.generateSeed() instance
method instead of SecureRandom.nextBytes(). Why? Because
every SecureRandom instance has to initialize it's seed
1st before getBytes() can provide the next random bytes
from the PRNG. Since we only need the 1st 8 bytes from the
SecureRandom instance to initialize TLR's seeder, we might
as well directly call the SecureRandom.generateSeed()
method. <br>
</blockquote>
<div><br>
</div>
<div>If I strace this program on Linux using strace -ff -q
java SecureRandoms:</div>
<div><br>
</div>
<div>public class SecureRandoms {</div>
<div> public static void main(String[] args) throws
Throwable {</div>
<div> byte[] bytes = new byte[8];</div>
<div> new
java.security.SecureRandom().nextBytes(bytes);</div>
<div> }</div>
<div>}</div>
<div><br>
</div>
<div>I see a read from /dev/urandom, but not from
/dev/random, so I conclude your intuitive understanding of
how the seeding works must be wrong. It makes sense that
NativePRNG doesn't need to do any special seeding of its
own, since it reuses the operating system's.</div>
</div>
</div>
</div>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
You're right. I checked again. The NativePRNG is actually using
/dev/urandom (by default unless java.security.egd or
securerandom.source is defined). It's mixing the /dev/urandom stream
with the stream obtained from SHA1 generator which is seeded by 20
bytes from /dev/urandom too. So by default yes, plain NativePRNG
(the default on UNIX-es) is using /dev/urandom for nextBytes(), but
this can be changed by defining java.security.egd or
securerandom.source system property. I still think that for
configuration-independent PRNG seed on UNIX-es it's better to invoke
generateSeed() on NativePRNG$NonBlocking, which hard-codes
/dev/urandom and doesn't mix it with SHA1 stream.<br>
<br>
On Windows, there's a different story, since the default
SecureRandom algorithm is SHA1, seeded by
SeedGenerator.getSystemEntropy() and SeedGenerator.generateSeed().
The former call includes invoking networking code and resolving
local host name. Which we would like to avoid. So I think we need a
nicer story on windows then just: new SecureRandom().nextBytes(). I
propose requesting explicit algorithm / provider on each particular
platform that we know does best what we want, rather than using
default which can still be used as a fall-back.<br>
<br>
Regards, Peter<br>
<br>
</body>
</html>