Re: Using /dev/random or /dev/urandom in C code

Schraalhans Keukenmeester wrote:
> Richard Heathfield wrote:
> > Schraalhans Keukenmeester said:
> >
> >
> >>I would like to seed my C random function (an implementation of the
> >>Mersenne Twister) using either of the random devices my Linux server has
> >>to offer.
> >>
> >>Three questions.
> >>
> >>1. Which of the two is the more 'reliable' (least predictable)
> >
> >
> > It hardly matters in your case, since you're just using it as a seed, but
> > /dev/urandom is probably your best bet.
> >
> >
> >>2. How do I get a nice set of random bits/bytes I can use as a seed in
> >>my C prog ? I am not familiar with using devices like these and have no
> >>real clue how to access the byte-stream they produce.
> >
> >
> > As far as Linux is concerned, it's just a file. Simply fopen() it like you
> > would any other file, and read from it. Use fread() or whatever. Then
> > fclose() it when you've got enough stuff out of it.
> >
> >
> >>3. Are there better entropy sources available/usable from within C code
> >> (and how?)
> >
> >
> > Given that you're only using this as a Twister seed, it hardly matters.
> > Still: people have used all kinds of stuff - atmospheric white noise,
> > radioactive sources, lava lamps, even a TV picture. Any bit source that you
> > can rig up in such a way that Linux thinks it's a file, is trivially
> > readable from C.
> >
> Richard, thanks very much for your very clear tips.
> I have read some document suggesting I might give /dev/audio a go, with
> NO mic plugged in. I think I will have to do some adjustments to ensure
> all bits are equally likely to be 1 or 0. Too bad I haven't got a Geiger
> counter and a nice lump of U235 available...
>
> By the way, it's not 'just a Twister' randomizer, it is going to be used
> in both a poker sim (I need 53 bits at least) as well as a statistical
> analysis environment, hence the use of the superior MT instead of the
> defult rand() function, which hardly qualifies as a random source.
>
> Would you guess (I am not sure how far your knowledge of randomizers
> goes) /dev/urandom itself could compete with the Mersenne Twister ? Any
> idea how fast /dev/urandom fires new bits at me?
>

Well.. any random number generator can in theory be reverse-engineered,
that is given a sequence of random numbers it may be possible to
perdict the next number, because a random number generator uses an
algorithm to generate random numbers. This makes random number
generators unsuitable for security applications (simply run tcpdump to
get the sequence of random numbers and you can perdict the next number
to be used for spoofing).

The /dev/random and /dev/urandom gets around this by trying hard not to
be random number generators (they fall back to being a random number
generator if they run out of random numbers). They do this by
"collecting entropy". This is done by mixing and mangling things like
the last entropy value, the date, the time, the process id, a hash of
all available process names, cpu temperature, phase of the moon, black
magic etc. depending on implementation. The point is it generates
random numbers by getting bits of information in your system which are
usually random. The fall back mechanism of a regular random number
generator is there if you read them too fast.

I is important to understand that the design criteria for your Mersenne
Twister and /dev/urandom are different. The Mersenne Twister attempts
to ensure all bits are as likely to be 0 or 1. Less effort is made to
ensure that the random numbers can't be reverse-engineered. The
/dev/urandom device attempts to ensure that each number in the sequence
of random numbers have no relationship with the next. Less effort is
made to ensure if all bits are as likely to be 0 or 1.

.

Relevant Pages

  • Re: rand() pattern in texture?
    ... >The random number generator has a certain period after which it repeats. ... >Lookup Mersenne Twister. ... >Python uses the Mersenne Twister as the core generator. ... >Perl seems to be much faster than Python but Perl fails the DieHard test ...
    (sci.math)
  • Re: SHA-based subclass for Random module
    ... Mersenne Twister is a pretty spiffy pseudo random number ... random-number generator through updating the hash with a constant string ... suggesting that short cycles in state are rare, ...
    (comp.lang.python)
  • Re: Mersenne Twister -- A Revised C++ Implementation
    ... >> eight bitwise operations ... Mersenne Twister is as faster or faster than any ... > other generator that has similar statistical properties. ... Marsaglia has many high quality random number generators involving far less ...
    (comp.lang.cpp)
  • Re: rand() pattern in texture?
    ... Somebody suggested that not all seeds ... The random number generator has a certain period after which it repeats. ... Lookup Mersenne Twister. ... Python uses the Mersenne Twister as the core generator. ...
    (sci.math)
  • Re: generate white noise in assembly
    ... generate a white noise in assembly, something like a random function in C. ... A linear congruential generator is probably good enough. ... In the second edition of NR, they say that all LC PRNG are about ...
    (comp.dsp)