Update #5: JEP 123: SecureRandom Draft and Implementation.

[Brad Wetmore]

On 4/11/2013 3:12 AM, Florian Weimer wrote:
> On 04/11/2013 12:07 AM, Brad Wetmore wrote:
>> Hi Florian,
>>
>>  > I wonder if this change to src/share/lib/security/java.security-linux
>>  >
>>  > -securerandom.source=file:/dev/urandom
>>  > +securerandom.source=file:/dev/random
>>  >
>>  > causes the return of the blocking behavior.
>>
>> Welcome to my "can of worms." [1]  I hope everything I've said below is
>> correct, and haven't made any typos!
>
> Yay for crypto pluggability. 8-/

If you were around pre-JDK 1.3.1_09/1.4, the SecureRandom performance is 
much better compared to ThreadedSeedGenerator.

> Rather than trying to find out what the code does, I tested your changes
> on Fedora 18, and here is what I found:
>
> new SecureRandom() does not block for seeding.  It reads straight from
> /dev/urandom, so it may have some impact on the kernel entropy pool.

I'm assuming you're using the default configuration, and using 
nextBytes() and not generateSeed()?  Then NativePRNG does read from 
/dev/urandom.

The Linux entropy pool has been a bit of a black box for me.  The latest 
I've read on it was "Analysis of the Linux Random Number Generator" by 
Gutterman, et.al. in 2006.  From what I understand, reads of 
/dev/urandom will indeed pull from the primary pool.  But if that's 
followed by a large of /dev/random, there's nothing in the primary pool 
to refill it.

Maybe you would know the answer to this question.  It used to be that 
the Linux entropy pools was refilled by keyboard/mouse/interrupts/disk 
activity.  On a lights-out/headless system, the first two didn't 
contribute.  There were not many kernel modules that fed the interrupts, 
so most of the entropy came from disk.  I know some vendors are adding 
network info, but from what I understand, that's not standard.  Have 
there been changes in more recent versions of Linux?

> SecureRandom.getInstance("SHA1PRNG") may block for seeding, but only
> once during startup.  After that, it does not obtain entropy from the
> kernel.

Correct.  I omitted mentioning the details for fear of causing even more 
confusion, but since you hinted at it: there is a system-wide seeder for 
initializing future SHA1PRNGs 
(sun.security.provider.SecureRandom$SeederHolder) that is itself a 
SHA1PRNG and needs to be seeded via the system entropy and the 
Native/URL/ThreadedSeedGenerator.  Once that has been seeded (via 
/dev/random by default), it generates seeds (using the 
SHA1PRNG.nextBytes()) for future SHA1PRNGs (without going through 
/dev/random).  However, calls to SecureRandom.generateSeed() will still 
always go to the Native/URL/ThreadedSeedGenerator.

When doing this project, there were many times where I said:  "Looks 
like I picked a bad week to..."  [1]

> This matches the behavior of OpenJDK 7 in that Fedora version.
>
> However, I noticed that /dev/{u,}random is opened three times each (and
> the file descriptors are kept open).

What was your application code?  Any configuration I should be aware of?

Oops, just realized there's an optimization in NativePRNG/friends.  If 
the seedFile/nextfile are both pointing to the same file, we don't need 
to open it twice.  I've filed bug JDK-8012042.  Might be able to 
optimize it further.

Brad

[1] This quote is from a classic American comedy movie called 
"Airplane."  http://www.youtube.com/watch?v=VmW-ScmGRMA