Quote from: Dabs on April 04, 2013, 03:53:40 AM

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.

Whether you are just generating a couple of keys for your personal experimental use or running a commercial site that needs a secure wallet, the poster did not mean you need to or should rely on external web sites to get random numbers. The point is that you can obtain data from multiple sources (web sites, stock prices, your own hardware/software) and then "distill" the resulting entropy.

Quote

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.

So the issue is that you do not trust the PRNG provided by the operating system (/dev/random, CryptGenRandom) even with a truly random entropy source seeding it??

Quote

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:

Quote

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.

One can use SHA or AES-CBC-MAC or whatever to distill/condition entropy, but... so you do trust the OS-provided CryptGenRandom or /dev/random to gather entropy from electronic thermal noise, OS latency, pictures of lava lamps, but do not trust their conditioning or PRNG? Why use it at all then?

I re-iterate what was said about not "rolling your own", but if you want to implement the PRNG yourself then look up e.g. the Fortuna algorithm in Practical Cryptography. Add a couple of lava lamps and you will be good to go...