Endre Stølsvik wrote:
Oliver Deakin wrote:
<SNIP>
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!
Actually when I tested these values I launched the VM separately for
every run, so at least for the process time (and obviously system clock)
it was as if the system was starting up every time. I still found that
the seeds generated were very variable, however I understand your
concerns - Im not convinced the seed generation would work so well if
the function were called many times in a row quickly by an application.
I see the code I committed as a starting point which can be built on as
we come up with better ideas for seed generation. This is not intended
as a replacement for reading directly from /dev/*random - my initial
post in this thread [1] was concerned with scenarios where entropy data
and random system devices are not available. We only fall back to using
random() if we cannot access random devices, so for the most part this
code will never be used. The code I have provided is not a final
solution, but enables me (and any others in my position) to work on
systems where random devices are not available whilst improving the
quality of the seeds.
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).
The difference here is that the OS is capable of constantly monitoring
human interaction with the system (which will almost certainly occur at
some point), but in our situation the user may launch the VM with a
class that requests random numbers without any kind of interaction from
the user between the time the VM launches and the time the random seed
is generated. In our case there is no source of human interaction to
generate a seed from and on a system without entropy based random
devices we have no other fallback mechanism.
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 definitely won't be peeking at any 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?
As I said above, this thread originated due to the existence of systems
that do not have these random devices. Im hoping to be able to find a
satisfactory solution to this problem.
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.
This is what we did previously. If we cannot come up with a good
solution then we may have to revert to throwing an exception.
Don't take lightly on this - it will blow up as a huge security alert
later on if you do.
That's exactly why I opened this up to the dev list for opinions and
patches.
Regards,
Oliver
[1]
http://mail-archives.apache.org/mod_mbox/harmony-dev/200712.mbox/[EMAIL PROTECTED]
Endre
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
