[Tfug] /dev/random

[Stephen Hooper]

On Sat, 2005-06-11 at 21:38 -0400, Charles R Kiss wrote:

> generates random numbers quickly, but I guess I'm feeling like I'm 
> missing a check on the entropy pool (something I don't yet understand); 
> but I haven't figured that out yet, I'm just guessing.   How fast and 
> for how long can I generate these numbers; which are rather large.
> 

The use of "/dev/random" does block after you read too many, how long
depends on how fast your processor is, and what the size of the pool is:
AFAIK, the processor fills up a "buffer" with pseudo random numbers, and
when you read over a certain number of them (half I think), starts
filling up the buffer with more.  Of course, reading is much quicker
than generation.

> Is there a way of limiting the random numbers output to three or four 
> numbers numbers without using the modulus function?   Say, reading 
> straight off a 2-bit byte random stream, or a 3-bit byte stream, or an 
> n-bit byte stream?

See the attached bit of "C" code.  I haven't done C++ in ages, but I am
sure the concept is similar.  Hopefully, this list allows attachments...

> 
> For now, I just need fast zeros and ones randomly distributed; but most 
> highly random.   Basically, super-fast, super-random, but only 0's and 
> 1's; then, later, I guess, not-so-fast, but just as random, values 
> betwen 0 and 4 [is this possible, or is the randomness a function of the 
> byte size??]; ie. controlling the size of the byte, then dumping the 
> values into a array.   Just for fun, obviously I have much more reading 
> to do.

Between 0, and 4 is a little harder than what I have posted, because 4
is not all set from a bit boundary.  So it would require an extra check,
and a discard of the 2 low bits if the high bit was set.   In other
words: 4 binary is 100, so we need to mask at 0x07.  That clears
everything but the first three low order bits making this number from
000 to 111 which is seven (last I checked).  Seven is out of your range
so you would need, roughly:

(buffer[counter] & 0x04)?'4':buffer[counter] & 0x07)

// byte & 0x07 -- the first three bits 
// byte & 0x04 -- the value of the third bit

Which still has problems, because this is likely to give you more fours
than anything else. You will have a 3 in 7 chance of hitting a number
which you would have to count as a four.  

I am not sure how to get around that, except maybe to either choose to
randomly keep the low bits, or randomly keep the high bit (sure you want
more random problems :) ).  

The  way I can think of that is somewhat elegant in implementation would
be to basically: basically use a byte going through it one bit at a
time; if the bit is high then you have a four; if the bit is low then
you use another byte going through it two bits at a time to determine
the actual value.

In this case it is easier if you could confine yourself to odd numbers
(that fill up all the bits within a range) so 3,7,15,31,127.

> 
> Also, is controlling the entropy pool, as in BSD's rndcontrol function, 
> possible?  Or do I just throw the processor with keyboard and mouse down 
> the stairs while it's computing?

I am not sure, what rndcontrol does, as I can find no man pages about
it.  If you are asking to add bytes to the entropy pool, writing stuff
to /dev/random does that (according to some guys posting on the
Internet).

If you really need strong randomness, I would suggest you look for
either a true random generator (hardware), or use one of the web pages
that present you with random data (checkout random.org).

Finally, depending on what your needs are (speed/randomness), and if you
do decide to run use the "/dev/random", or "/dev/urandom" (which doesn't
block, but resorts to hashing the pool to get more numbers), then you
want to be careful not to let other things eat at your random pool... so
better to run all this stuff on a machine that is not doing crypto
(SSL/GPG), or eating into the pool in other ways.

Have fun, and hope this helps...