Oliver Deakin wrote:
Thanks Endre - that's an interesting account.
To generate the random seed I used the current system time, the running
time of the current process and an address of a local variable allocated
with the port library equivalent of malloc.
Envision a server that's booting up.
Playing the devils advocate here, assuming that no network activity
happened before our java process started, what's really random with
those three "seeds"?
I found that, although
fairly simple, this produced a good variety of seeds.
On a system that's already running, it might. On a system that is
starting up, there will be _no_ variety in those three variables except
for the time, and that isn't really "variable" either!
Time cannot be assumed to be _variable_, just because it isn't -
assuming that you synch to some proper time server, I can do it too, and
our milliseconds deviation will be just a couple of tens or maybe
hundreds if we're extremely unlucky.
If you get any variety through those seeds, I bet the true entropy is a
couple of bits at the most.
Check how linux's /dev/random works - it ONLY accepts humanly generated
entropy, because it feels that even network activity can be tricked,
e.g. (IIRC) by pounding the server with extremely regular packets for an
hour, and then start to attack it on its randomness (e.g. stealing some
SSL session).
Since entropy is so hard to get hold of, linux saves its stash of
collected randomness, the /entropy pool/, on system shutdown (IIRC).
Read:
http://en.wikipedia.org/wiki/Entropy_pool#Using_observed_events
If anyone has suggestions on improvements to the seed selection, they
would be gratefully received. A patch with the improvements in would be
even more gratefully received ;)
Sorry, can't help you there. Why not peek in other implementations? I
know that firing up the default SecureRandom on .. what was it .. Linux
.. a couple of java versions ago, took ages - so it must have been doing
some entropy-collecting in that time. What about trying to suck a couple
of bytes from /dev/random for a couple of seconds, and if it doesn't
work out, suck the rest out of /dev/urandom, with a warning on standard
error?
I nevertheless mean that you _shall not_ implement a default
_SecureRandom_ that produces entirely and absolutely predictable
values!! Throw an exception in case the underlying system cannot produce
any entropy on its own.
Don't take lightly on this - it will blow up as a huge security alert
later on if you do.
Endre
