On Aug 21, 2013, at 12:19 PM, Doug Lea <d...@cs.oswego.edu> wrote: > On 08/21/2013 05:43 AM, Paul Sandoz wrote: >> On Aug 20, 2013, at 11:50 PM, Mike Duigou <mike.dui...@oracle.com> wrote: >>>>> - Additional seed material might be desirable for "seeder". I worry >>>>> about how many of the actual bits are random. > > Backing up a bit: I tried using a SecureRandom seed. > But then discovered that on some systems, this led to > serious start-up stalls (up to 10 seconds or so) because > /dev/random can delay while collecting entropy. For a non-secure > RNG, this is unacceptable. On most Unix/linux systems, > this is a known issue, and there is a workaround to instead > use /dev/urandom. But using /dev/urandom is tantamount to > just collecting some local information, so the default > seeder does so itself which leads to faster startup. > Note that the two main ingredients, absolute time (currentTimeMillis) > and non-absolute time (nanoTime) are in general uncorrelated > (they normally use different timers, with different precisions, > on current JVMs). The hostname hash is a barely-useful tie-breaker > in case they are. > > I can't get myself to believe that adding information from > various identityHashCodes would improve this, since they are > dependent on the identityHashCode mechanics themselves > doing better than this, which I don't think they do. > >> >> I did ponder whether it is worthwhile defining a boolean system property that >> if declared and true then SecureRandom is used. >> > > Given the alternative of slowing down startup for all > usages, this now strikes me as an OK CYA move. >
OK. Unless there are strong objections i will do this. Paul.
