harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Date Fri, 11 Jan 2008 14:31:53 GMT
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 


> 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

View raw message