rsaenh and /dev/urandom

[Michael Jung]

Hello,

some more thoughts on the security of using /dev/urandom. This is from MSDN 
(CryptGenRandom):

> 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 (2.6.8.1 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.

Greetings,
Michael