Nobody <nob...@nowhere.com> writes: > The problem with /dev/urandom is that it shares the same entropy pool as > /dev/random, so you're "stealing" entropy which may be needed for tasks > which really need it (e.g. generating SSL/TLS keys).
The most thorough analysis of Linux's /dev/*random that I know of is here: http://www.pinkas.net/PAPERS/gpr06.pdf It says random and urandom use separate pools, though both fed from the same primary pool. The point is that reading from one should not interfere with the other. There have been interminable threads on sci.crypt about /dev/random vs /dev/urandom and the sane conclusion seems to be that if there's enough entropy in the system, /dev/urandom is not really worse than /dev/random. Any type of userspace randomness collection is probably worse than either. If you're doing typical low-to-medium security stuff on traditional PC hardware (i.e. not virtualized, not something like OpenWRT which has few real entropy sources), /dev/urandom is fine. If you don't believe in its cryptographic PRNG, you shouldn't believe in OpenSSL either. If you're doing high security stuff (server-side financial apps, etc.) then /dev/urandom and /dev/random are both considered not good enough, and your PC is probably leaking keys, so you should be using dedicated crypto hardware. > Personally, I'd take whatever "cheap" entropy I can get and hash it. > If you're going to read from /dev/urandom, limit it to a few bytes per > minute, not per request. That's really not going to help you. -- http://mail.python.org/mailman/listinfo/python-list