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
