[vox-tech] random # gen seeds

[vox-tech@lists.lugod.org]

On Wed, Mar 13, 2002 at 08:46:07PM -0800, Mark K. Kim wrote:
> gettimeofday returns a structure with seconds as well as microseconds.
> You can use the microseconds portion as the seed.  However, there is a
> resolution issue with microseconds, which may or may not be a problem, so
> you probably want to mix up the seconds with the microseconds somehow.
> 
> Also, you can read /dev/random.
> 
> On Wed, 13 Mar 2002, Matt Holland wrote:
> > I need to generate more than one random number generator seed per second
> > within a C program (I have a program that runs about 6 times a second,
> > and I need unique seeds for each run).  time(0) only gives me a
> > resolution of 1 second... any suggestions?

Matt,

  Both of Mark's suggestions are good (gettimeofday, /dev/random)

  However, I doubt your application needs data from /dev/random and would
recommend using urandom instead (man urandom(4) for details).  When using
/dev/random there is a risk that if you try to run get too much from it 
you will starve "the entropy pool" and your application will lock up 
waiting for more entropy.
  So if possible the best option would be reading data from /dev/urandom.

  I would also suggest that you reconsider how your overall application 
works... possibly try to restructure it so that you start one application
which gets one random seed and does whatever you wanted to do 6 times
a second itself, instead of starting hundreds of very short lived 
processes.
  Can you provide any more details about what you are doing?

    TTFN,
      Mike


from urandom(4):
#      When read, the /dev/random device will only return  random
#      bytes  within the estimated number of bits of noise in the
#      entropy pool.  /dev/random should  be  suitable  for  uses
#      that  need  very  high quality randomness such as one-time
#      pad or key generation.  When the entropy  pool  is  empty,
#      reads  to /dev/random will block until additional environ-
#      mental noise is gathered.
#
#      When read, /dev/urandom device will return as  many  bytes
#      as are requested.  As a result, if there is not sufficient
#      entropy in the entropy pool, the returned values are theo-
#      retically  vulnerable  to  a  cryptographic  attack on the
#      algorithms used by the driver.  Knowledge  of  how  to  do
#      this is not available in the current non-classified liter-
#      ature, but it  is  theoretically  possible  that  such  an
#      attack  may  exist.  If this is a concern in your applica-
#      tion, use /dev/random instead.