ThreadLocalRandom clinit troubles

[Peter Levart]

On 06/24/2014 06:01 PM, Martin Buchholz wrote:
>
>
>
> On Tue, Jun 24, 2014 at 7:03 AM, Peter Levart <peter.levart at gmail.com 
> <mailto:peter.levart at gmail.com>> wrote:
>
>
>     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.
>
>
> If I strace this program on Linux using strace -ff -q java SecureRandoms:
>
> public class SecureRandoms {
>     public static void main(String[] args) throws Throwable {
>         byte[] bytes = new byte[8];
>         new java.security.SecureRandom().nextBytes(bytes);
>     }
> }
>
> 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.

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.

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.

Regards, Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20140624/8de51882/attachment.htm>