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
