Bitte verzeih mir den Fehler, dass ich mich nicht auf Aussagen in einem Blog verlasse sondern auf den Inhalt des Manuals des Herstellers:
When read, the /dev/random device will return random bytes only within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered. If open(2) is called for /dev/random with the flag O_NONBLOCK, a subsequent read(2) will not block if the requested number of bytes is not available. Instead, the available bytes are returned. If no byte is available, read(2) will return -1 and errno will be set to EAGAIN.
A read from the /dev/urandom device will not block waiting for more entropy. If there is not sufficient entropy, a pseudorandom number generator is used to create the requested bytes. As a result, in this case the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current unclassified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead. O_NONBLOCK has no effect when opening /dev/urandom. When calling read(2) for the device /dev/urandom, signals will not be handled until after the requested random bytes have been generated.
Und wie die Dinge liegen liegt das Manual des Herstellers und meine Aussage genau auf einer Linie. Aber wenn das wirklich Mythen sein sollten, dann hätte ich einen schwarzen Tag.