> Perhaps trying to read large
> amounts of data from either is misuse.
It is. /dev/random will only return a maximum of the amount of randomness
it has before blocking, whereas /dev/urandom will return bytes that are
significantly less random at that point.
> Either way, I took what I said
> straight from devices.txt:
>
> 8 = /dev/random Nondeterministic random number gen.
> 9 = /dev/urandom Faster, less secure random number gen.
I suguest that you read drivers/char/random.c, which is very understandable
to laypeople (the comments, anyway <G>). Specificly, lines 107-119 are
significant here:
* The two other interfaces are two character devices /dev/random and
* /dev/urandom. /dev/random is suitable for use when very high
* quality randomness is desired (for example, for key generation or
* one-time pads), as it will only return a maximum of the number of
* bits of randomness (as estimated by the random number generator)
* contained in the entropy pool.
*
* The /dev/urandom device does not have this limit, and will return
* as many bytes as are requested. As more and more random bytes are
* requested without giving time for the entropy pool to recharge,
* this will result in random numbers that are merely cryptographically
* strong. For many applications, however, this is acceptable.
> If you want to generate large amounts of random data, like for creating
> big files full of junk for testing new disks, using something like
> putchar(rand()); is considerably faster than reading /dev/urandom.
Not surprising. I don't think rand() uses the kernel-baised random number
generator -- glibc's rand() manpage only describes rand() as returning
"psudo-random" numbers. Also, straceing the program "main () {while (1)
rand();}" revals no syscalls. This means that rand() produces psudo-random
numbers with significantly less randomness.
-=- James Mastros
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu