/dev/random broken?
A message that is not in the archive (sent off-list or not yet received): E19WOvK-0001I7-00@andromeda
/dev/urandom is what you want; it makes up its own entropy. /dev/random uses entropy from user input (low order bits I imagine). I assume that this is how other unixes work, too.
Justin
Quoted 26 lines · Luca T.
Hello,
i am not sure if this is a kernel/module problem but so it seems to me. My computer is an AMD 2000+ with an ABIT motherboard, my kernel version is 2.4.21-0.13mdk (but i tried it with 2.4.21-0.18mdk too and it doesn't work either).If i give this command:
dd if=/dev/zero of=./xxx bs=1024 count=100
it will work perfectly. But if i try to do the same reading from/dev/randomwith this command:
dd if=/dev/random of=./xxx bs=1024 count=100
it will just sit there and stare at me until i move the mouse... and then the program will exit without any error message (i checked in/var/log/messagestoo and there is no message there either about this).Is this a bug? If yes... do you have any idea that would help me fix it?
Thank you,
Luca-
To unsubscribe from this list: send the line 'unsubscribe linux-kernel' in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · Justin Pryzby
/dev/urandomis what you want; it makes up its own entropy./dev/randomuses entropy from user input (low order bits I imagine). I assume that this is how other unixes work, too.
Actually, no. Both device files use entropy from the same location (the entropy pool), which is derived from the same sources (various interrupt timings and whatnot).
The difference between the two is that /dev/random keeps track of the inherent entropy in the pool and will block when the entropy grows too small. This is done as protection against any possible flaws in the one-way hash employed on outgoing data. Theoretically, if someone was able to break SHA-1, and they obtained a sufficiently large percentage of the output data, they could theoretically determine some theoretical state about the entropy pool. To prevent this theoretical attack, /dev/random will not return any data while the entropy estimate is not positive. This ensures there is enough entropy in the pool such that, even if a single attacker has seen all the output thus far, they cannot learn of the pool's state.
Also, as far as other Unix systems, I think /dev/random was first in Linux. I know Mac OS X has /dev/random and /dev/urandom, but they both behave like Linux's /dev/urandom.
Robert Love
Quoted 2 lines · Justin Pryzby
/dev/urandomis what you want; it makes up its own entropy./dev/randomuses entropy from user input (low order bits I imagine).
Strictly speaking, urandom doesn't "make up" any entropy - it generates a pseudorandom stream of bits of arbitrary length using a small chunk of entropy from the entropy pool. That's why it's able to generate multi-megabyte streams of bits even when the entropy pool is empty - it is generating a fixed but unpredictable stream based on the initial entropy.
The distinction is important mostly to cryptographers - for almost all practical uses, the pseudorandom stream of bits produced by urandom is quite sufficient, much faster, and leaves the entropy pool untouched for those applications that *do* care about the difference....