This depends on the platform.
As a general case, you should consider using the OpenSSL bindings to use OpenSSL's RAND_* API. Do make sure to seed it correctly. Not reading the OpenSSL documentation will cause a security compromise on virtually all operating systems due to improper RNG seed. Even “big ones” have been bitten by this.
On Unix-like operating systems including BSD, the Hurd and Mac OS X, you should read from
/dev/arandom (if it exists), or
/dev/urandom (if it exists), or
/dev/random (only if none of the other two exist). If none of these ① exist and ② are character devices, stop with an error to prevent compromise. You really do not want to “invent” an RNG/seeding scheme yourself!
On Windows® systems… first consider if you really want to do this. This is already a potential security compromise. Then, read from
/dev/urandom if it exists (Cygwin), or use the CryptGenRandom API. I'm not sure there are Python bindings for it, but it's not hard to do in C, and can be made into a compiled Python module. Maybe with FFI…
When using OpenSSL, do consider to set
RANDFILE to keep a seed across program invocations, especially on Windows®. Consider preseeding this from known good entropy. Maybe mixing stuff from
fourmilab.ch's Hotbits service (but, again, do not only take from there, as it's transmitted over the network). Be aware that the
RANDFILE is not handled properly by OpenSSL by default: instead of read+RAND_add+write+close on program start, it's normally read at program start and written only at program end; this is better but only if your program (and all other programs using it) is not running more than one instance at any given time.
Do not use any of those:
- Process ID
- Mouse position
- Screen content
- Content of “uninitialised” memory – it is often not uninitialised (even
malloc() results, which the C library may not initialise, is initialised by the OS for the sole reason to clear what was in there before (e.g. from another process), and the simplest way to clear it is to zero it out), and if it is, this is normally Undefined Behaviour, which may lead to all sorts of mayhem
It is true that these are (some of the) input sources used by the OS and/or OpenSSL for their RNG implementations. But these people know (more or less, but a bit more than you) what they are doing, and, far more importantly, they are not the only sources. They are all not secrets, and an attacker can experiment with them. More importantly, their value range is not great. Also, do not write any “keyboard input” code (values and timing) yourself. The OS handles keypress-to-entropy conversion itself, normally. Just ask the OS for good entropy, and error out if there isn't any.
Do not use the system's hardware random number generator as only source! They can be compromised. Also, it may not even exist, or access be prohibited (think virtual machines).
Mixing any of these into a pool is good – but then again, the OS will do a much better job at that than your user-space application.