Interprocess scheduling isn't currently a source of entropy for /dev/random or /dev/urandom.
Edit: I have random/urandom backwards. Still doesn't change my core point. Sorry for the confusion.
/dev/random is a PRNG, and predictable. You shouldn't use it for security applications but only for specific state/algorithm randomness.
/dev/urandom requires hardware noise/key events, etc. to generate its entropy. These become hard to find when your dealing with purely virtualized installations.
:.:.:
The key focus for this is webapps, or should be. Far to many use PRNG to give session cookies, and these are very very easy to hyjack especially if cookies can be issued whenever a user logs in/out. Its pretty trivial to generate 1,000 -> 5,000 session cookies (from login/logout) and attempt to find a PRNG pattern.
/dev/random is a PRNG, and predictable. You shouldn't use it for security applications but only for specific state/algorithm randomness.
/dev/urandom requires hardware noise/key events, etc. to generate its entropy. These become hard to find when your dealing with purely virtualized installations.
This is not true, at least on Linux. /dev/random is actually closer to what you describe as /dev/urandom. It is a cryptographically strong randomness source that blocks depending on the state of its internal "entropy pool". /dev/urandom is also a cryptographically strong randomness source (seeded from /dev/random), but it does not block.
Note: this comment is being written after the correction above concerning the mixup of /dev/random and /dev/urandom.
/dev/urandom is not a mere PRNG. It is a CSPRNG. Once it has been seeded with a good amount of entropy, say, 256 bits, it is safe to use for essentially all cryptographic purposes. That includes making long term SSH, SSL, and OpenPGP keys, and of course also includes making session cookies.
Yes, I know the Linux man page for /dev/random says otherwise. As Dan Bernstein notes, this is "superstitious nonsense" [1]:
Cryptographers are certainly not responsible for
this superstitious nonsense. Think about this for a
moment: whoever wrote the /dev/random manual page
seems to simultaneously believe that
(1) we can't figure out how to deterministically
expand one 256-bit /dev/random output into an
endless stream of unpredictable keys (this is what
we need from urandom), but
(2) we _can_ figure out how to use a single key to
safely encrypt many messages (this is what we need
from SSL, PGP, etc.).
For a cryptographer this doesn't even pass the laugh
test.
There is almost never a good reason for anyone other then the people who wrote the init scripts for your distribution to read /dev/random on a Linux system. They should read it to get entropy to initialize /dev/urandom, and to periodically reseed /dev/urandom.
> /dev/random is a PRNG, and predictable. You shouldn't use it for security applications but only for specific state/algorithm randomness.
> /dev/urandom requires hardware noise/key events, etc. to generate its entropy. These become hard to find when your dealing with purely virtualized installations.
Actually /dev/random is truly random and requires entropy inputs; once the current entropy pool is exhausted, reads from /dev/random block. /dev/urandom is similar but reuses the entropy pool to produce PR values until more entropy comes in, so it's good for games and such.
Interprocess scheduling isn't currently a source of entropy for /dev/random or /dev/urandom.
Edit: I have random/urandom backwards. Still doesn't change my core point. Sorry for the confusion.
/dev/random is a PRNG, and predictable. You shouldn't use it for security applications but only for specific state/algorithm randomness.
/dev/urandom requires hardware noise/key events, etc. to generate its entropy. These become hard to find when your dealing with purely virtualized installations.
:.:.:
The key focus for this is webapps, or should be. Far to many use PRNG to give session cookies, and these are very very easy to hyjack especially if cookies can be issued whenever a user logs in/out. Its pretty trivial to generate 1,000 -> 5,000 session cookies (from login/logout) and attempt to find a PRNG pattern.