Messages in this thread | | | Date | Wed, 18 Mar 1998 10:59:49 -0500 (EST) | From | James Mastros <> | Subject | Re: kernel security questions |
| |
On Mon, 16 Mar 1998, Jon Lewis wrote: > On Mon, 16 Mar 1998, Theodore Y. Ts'o wrote: > > urandom is the faster less secure random generator. Looking at a few dd's > > from it, I would think it would work as well for this purpose. Instead of > > using isalpha and friends, just make sure the char value is between 32 and > > 126. That'll give you a better range of usable but non-alpha characters. > > > > /dev/urandom and /dev/random use the same algorithm for generating > > random numbers, and so their speed is the same. The big difference > > between the two is that the random number generator keeps traccxcxcx > > If you try to read signifigant amounts of data from both /dev/random and > /dev/urandom, you'll find urandom to be orders of magnitude faster. > Perhaps this is just because /dev/random runs out of random bytes and > makes you wait for more to accumulate. Exactly. Take a look at the output from "cat /dev/random" -- it outputs a fair amount (no more then 256 chars, though -- the max. size of the random pool), then pauses for a while.
> 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
| |