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