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

[Florian Weimer]

On 04/11/2013 10:10 PM, Brad Wetmore wrote:
>> 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.

Correct.  The code looks like this:

     import java.security.SecureRandom;

     public class SecureRandomLoop {
         public static void main(String[] args) {
             int count = Integer.parseInt(args[0]);
             byte[] buffer = new byte[128];
             for (int i = 0; i < count; ++i) {
                 new SecureRandom().nextBytes(buffer);
             }
         }
     }

To be clear, I liked what I saw (except the additional file 
descriptors).  Behavior does not seem to change much.

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

There have been some changes.  Adjustments to the entropy estimates have 
resulted in significant behavioral changes in practice.

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

I recall that the entropy estimates were adjusted downwards at some 
point.  These days. there appears to be some popular service/application 
which drains the pool at a fairly constant rate (but I haven't tracked 
down the culprit yet).  Both changes lead to increased blocking when 
reading from /dev/random.

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

Changing the default to /dev/urandom for this initialization would help 
to avoid blocking on startup.

-- 
Florian Weimer / Red Hat Product Security Team