Actually, I've had this idea of using frequently changing websites, including the random number websites, however, they are all still on the internet. No matter what anyone says, even if it were through a secure session (SSL, TLS) it still came from somewhere else.
Random numbers can be generated from hashes of all of those, and then include local (specific to the computer you are using) unpredictable numbers, such as mouse input, keyboard input, hard drive input, operating system input, pictures of lava lamps, pictures of the sky or the ocean or your aquarium. But these are all already provided for by CryptGenRandom or /dev/random.
How about, I use a fast PRNG together with the slow CryptGenRandom as the seed? Or I do something like this:
1. Get a 256-bit number seed from CryptGenRandom.
2. Hash this number with SHA256
3. add 1 to the original number
4. Hash this next number with SHA256.
5. Rinse, Repeat.
Basically use CryptGenRandom as the basis for the next bunch of operations, which can be a hash, or blum blum shub or mersenne or something.
According to some other internet something I read somewhere:
One good trick for generating very good non-random-but-nearly-random bits is to use /dev/random's entropy to seed a fast symmetric stream cipher, and redirect it's output to the application that needs it.
I could also use AES in some sort of counter mode.
For purposes of discussion, can I safely assume that CryptGenRandom on Windows is equivalent to /dev/random on Linux ?
For truly secure purposes, I am guessing that I will have to call CryptGenRandom for each brand new private key I want to generate.