harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Endre StĂžlsvik <En...@stolsvik.com>
Subject Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Date Fri, 11 Jan 2008 12:27:21 GMT
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

Mime
View raw message