<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 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>