Quote from: AlphaWolf on April 19, 2013, 03:43:28 AM

Your answer will depend on which "Linux live distro" you're using, and on which hardware. Recent versions of Ubuntu and Fedora will have OpenSSL 1.0.1+.

As of Fedora 18, rngd is started by default. If it finds a TPM or if the RDRAND and AES-NI* instructions are available on your Ivy Bridge or later CPU, it will use these as entropy sources to feed to the kernel, keeping the entropy pool topped off. So... if you're using Fedora 18 on a system with a TPM or Ivy Bridge processor, you probably don't have to worry about it. Otherwise... seek ye the source code

If you want more help than that... we need to know which distro you're using so we can look over the specific source without worrying about "that might have changed in a later version, or was changed in a patch by X distro".

I don't have any special or new hardware (so, no TPM or Ivy Bridge or later CPU). I don't want to reveal exactly my whole software setup. Not that I have _that_ many bitcoins, but revealing exactly which version of what software I'm running seems to be a very poor security practice.

Regardless of exactly what is going on below the covers, shouldn't OpenSSL be pulling either from /dev/random or /dev/urandom? If so, what's going on beneath the covers doesn't matter, because /dev/random blocks where there is insufficient entropy, and with /dev/urandom, I can check and see how much entropy there is. That's exactly why those things are there - so that there is a standard way to make sure you have enough entropy, regardless of exactly what you are doing.

So, frankly, if bitcoin (and ultimately OpenSSL) are not using one of those two mechanisms, I would find that puzzling. And I would be curious to find out (a) why not; and (b) what is the standard procedure for someone who is not an actual OpenSSL developer to make sure their applications are getting enough entropy.

I somewhat suspect that either bitcoin or OpenSSL does make sure there is enough entropy, and the right person who can confirm that just hasn't shown up. If it doesn't, that would be a good feature to have (and arguably a bug to not have it). In other words, IMHO, the standard client should guarantee that the addresses it generates are always good addresses and you can't predict the next private key based on knowing other private keys generated around the same time on the same platform (modulo the phenomenally unlikely chance of having a collision). And I bet it does, it's just not been publicly documented yet (that I have found).

For example, deepceleron stated "rand_getbytes returns an error if there is insufficient entropy pool." That is almost good enough for me, but I wasn't able to find that function in either OpenSSL or bitcoin, and even if I did, I personally would like someone to reassure me that that function (or something equivalent) is actually going to be executed on a standard Linux setup.

Anyway, AlphaWolf, thanks very much for taking the time to help me, and hopefully you, deepceleron, or someone else can further enlighten me.