[EMAIL PROTECTED] (Gaël Le Mignot) writes: > This is the current implementation, yes, but /dev/urandom doesn't guarantee > anything about the "quality" of the random bits. It can be secure, but it > can be pseudo-random too, and any program that use /dev/urandom as a secure > source of random bits is flawed,
If we assume that the pseudo randomness generator used by /dev/urandom is good, and that the entropy pool was able to pick up some 100 hard-to-guess bits at system startup (and if not, you're probably screwed anyway), then the difference between /dev/random and /dev/urandom is for most cryptographic applications *totally irrelevant*. For an enemy with limited computational power (e.g. the enemy can't invert md5 or brute force 256 bit AES), then *by definition* the enemy can't even tell the difference if you're using true random bits or a good pseudorandom generator, so how can he be better off if you use the pseudo random one? Unless you're trying to generate a one-time pad, or use some other construction that is secure even if the enemy has infinite computational power (something which openssh certainly doesn't do), it doesn't matter very much if you use /dev/random or /dev/urandom. /Niels