ps -laxww for randmoness?

How about using ps -laxww as a source of randomness?  Of course it would be
run throug something like MD5 to get rid of the structure.  This would
not be good on a multi-user system because ps command may have been 
modified to log the person invoking it, time, and output to somewhere.

But on a personal workstation that you trust, it could be a pretty
good source of unpredictable data.

This is not my original idea, I think it was suggested in one of the
multiple precision math packages I looked at recently.

>From: yanek@novavax.nova.edu (Yanek Martinson)

>How about using ps -laxww as a source of randomness?

Its a rather bad source. Operations of a computer system are
suprisingly low on entropy. I'd guess that, if I needed to and had
enough resources, I could break such a generator without more than a
few months work, and even get the system to break it semi-automatic.

No one here seems to think in terms of cryptanalysis and how people do
it when they come up with their schemes.

Perry

In some email I received from Perry E. Metzger, Sie wrote:
> 
> 
> >From: yanek@novavax.nova.edu (Yanek Martinson)
> 
> >How about using ps -laxww as a source of randomness?
> 
> Its a rather bad source. Operations of a computer system are
> suprisingly low on entropy. I'd guess that, if I needed to and had
> enough resources, I could break such a generator without more than a
> few months work, and even get the system to break it semi-automatic.
>
> No one here seems to think in terms of cryptanalysis and how people do
> it when they come up with their schemes.

Well whenever I try to come up with some nifty crypto scheme, I always
seem to think it is too easy to break if you know its being used but then
I dont like doing too much 'expensive' crypting and I usually find some
cheap algo which uses a more expensive one for key trading.

Has anyone tried using the microsecond counter from unix as a random
source ?  Its obviously *not* going to be good if you want a continuous
stream of random numbers, but if you need them just 'every now and then',
what about it ?

Something like this would be used:

	struct	timeval	tv;
	long	rand;
	...
	gettimeofday(&tv, NULL);
	rand = tv.tv_usec + tv.tv_sec;
	...

Very unlikely to get a duplicate, esp. if you dont need the number
more often than 1 per second.

darren

> 	gettimeofday(&tv, NULL);
> 	rand = tv.tv_usec + tv.tv_sec;

Someone trying to break your code could find out approximately when
the number was generated, then they would have a much smaller search
space to try.

In some email I received from Yanek Martinson, Sie wrote:
> 
> > 	gettimeofday(&tv, NULL);
> > 	rand = tv.tv_usec + tv.tv_sec;
> 
> Someone trying to break your code could find out approximately when
> the number was generated, then they would have a much smaller search
> space to try.

Thats why you change key 'regularly'...even randomly ?

Then they have to 'guess' when you change keys.  It might be easy
to tell when an application starts, but how can you tell exactly or
even approximately how long ago someone picked a menu that changed
their key or it was otherwise changed ?

By using the microsecound counted as a random number, its almost
completely random unless you take steps to actually make less so.
But a table of the required million entries and 'init' strings
wouldn't be too hard for todays computers, hence the use of the
time in seconds to 'bump' the offset a bit.

For example, if you use a simple xor table for encoding/decoding,
its pretty easy to decode.  If you change the table after it has
been used, every time, then the required time to break the entire
message is significantly larger than it would otherwise have been.

Can anyone do some maths on exactly how long it would take given
a fixed table size (contains random data) ?  And also with key/
table changes at a fixed/random interval ?
(seems 1:1 :( but I maybe wrong).

darren

From: avalon@coombs.anu.edu.au (Darren Reed)
   Date: Wed, 16 Dec 92 2:30:49 EST

   Has anyone tried using the microsecond counter from unix as a random
   source ?  Its obviously *not* going to be good if you want a continuous
   stream of random numbers, but if you need them just 'every now and then',
   what about it ?

This should be in an FAQ:  Unixes have different levels of granularity
in the microsecond counter; some systems may only have a 10 ms (that's
10000 microsecond) resolution to their clock.  So you can't necessarily
depend on a getting lot of bits of randomness from this method.

						- Ted

Don Davis, of MIT Project Athena, did some research a number of years
back on getting good (physical) randomness out of a unix workstation.
If I recall correctly, the general idea was to look for trends and
biases, find explanations for them, and then filter them out or
normalize against them. Sources of "real" nondeterminism came from
things like variations in hard drive behavior (such as actual seek
time, which shows up indirectly in the paging system because it does
or does not cause time delays due to missed sectors...) I don't have a
reference handy, but if noone comes up with one I'll send him email
and see if he has it online.
	In other words, 'ps -laxww' itself is relatively useless --
but the underlying data does actually have randomness; you may have to
dig pretty hard for it, though.
							_Mark_

   SUB: Re: ps -laxww for randmoness?
   SUM: <tytso>, tytso (Theodore Ts'o)->avalon@coombs.anu.edu.au, cypherpunks@toad.com

      From: avalon@coombs.anu.edu.au (Darren Reed)
      Date: Wed, 16 Dec 92 2:30:49 EST

      Has anyone tried using the microsecond counter from unix as a random
      source ?  Its obviously *not* going to be good if you want a continuous
      stream of random numbers, but if you need them just 'every now and then',
      what about it ?

   This should be in an FAQ:  Unixes have different levels of granularity
   in the microsecond counter; some systems may only have a 10 ms (that's
   10000 microsecond) resolution to their clock.  So you can't necessarily
   depend on a getting lot of bits of randomness from this method.

						   - Ted