rsaenh and /dev/urandom
mjung at iss.tu-darmstadt.de
Thu Oct 28 09:21:39 CDT 2004
some more thoughts on the security of using /dev/urandom. This is from MSDN
> With Microsoft CSPs, CryptGenRandom uses the same random number generator
> used by other security components. This allows numerous processes to
> contribute to a system-wide seed. CryptoAPI stores an intermediate random
> seed with every user. To form the seed for the random number generator, a
> calling application supplies bits it might have—for instance, mouse or
> keyboard timing input—that are then added to both the stored seed and
> various system data and user data such as the process ID and thread ID, the
> system clock, the system time, the system counter, memory status, free disk
> clusters, the hashed user environment block. This result is SHA-1 hashed,
> and the output is used to seed an RC4 stream, which is then used as the
> random stream and used to update the stored seed.
This is from the linux kernel sources (188.8.131.52 drivers/char/random.c):
> When random bytes are desired, they are obtained by taking the SHA
> hash of the contents of the "entropy pool". The SHA hash avoids
> exposing the internal state of the entropy pool. It is believed to
> be computationally infeasible to derive any useful information
> about the input of SHA from its output. Even if it is possible to
> analyze SHA in some clever way, as long as the amount of data
> returned from the generator is less than the inherent entropy in
> the pool, the output data is totally unpredictable. For this
> reason, the routine decreases its internal estimate of how many
> bits of "true randomness" are contained in the entropy pool as it
> outputs random numbers.
> If this estimate goes to zero, the routine can still generate
> random numbers; however, an attacker may (at least in theory) be
> able to infer the future output of the generator from prior
> outputs. This requires successful cryptanalysis of SHA, which is
> not believed to be feasible, but there is a remote possibility.
> Nonetheless, these numbers should be useful for the vast majority
> of purposes.
Condensed, I read this as follows:
- Microsoft uses an entropy source to seed a pseudo-random generator. If the
seed is known, then the pseudo-random numbers are predictable.
- /dev/urandom is also seeded with an entropy source. However, whenever the
kernel collects new entropy, this also affects /dev/urandom.
As I understand it, this basically means the following: In the worst case
(kernel doesn't collect new entropy), we are as good as Microsoft. In all
other cases /dev/urandom is better.
Given this and the fact that OpenSSL also seems to apply /dev/urandom, I think
rsaenh should also do it this way.
More information about the wine-devel