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
