Sorry for my delay in responding. I'm fairly satisfied on this topic, but I'm going to give my final "conclusions" and "findings" for the sake of posterity.
First, there is a simple test to see if bitcoin-qt and openssl are using /dev/urandom or not on a particular machine with pretty high certainty:
On my system (and probably on practically all modern linux desktops), you will find a read of /dev/urandom in that trace, meaning yes, /dev/urandom is being used.
First, there is a simple test to see if bitcoin-qt and openssl are using /dev/urandom or not on a particular machine with pretty high certainty:
Code:
strace -o output bitcoin-qt
On my system (and probably on practically all modern linux desktops), you will find a read of /dev/urandom in that trace, meaning yes, /dev/urandom is being used.
You're going to see a read to /dev/urandom on a Linux system one way or another. What that doesn't tell you (unless you really analyze the strace... or attach dbg) is if the read was just to seed OpenSSL's PRNG, or if it was used as the entropy source for the entire key. I honestly have no idea which of those options is more cryptographically secure. Just seeding the PRNG with /dev/urandom would mean /dev/urandom would be less likely to run out of entropy so that seems like a plus. But then you're also seeding one PRNG with another PRNG... that "feels" wrong to me... but I, like you, am no crypto expert. However, what gmaxwell said makes sense. When /dev/urandom has run out of entropy, the obvious mode of operation would be to use the last truly random bits to seed the PRNG until more entropy is available. In order for someone to take advantage of this situation, they'd have to either:
1. Have access to your machine at the exact same time that it has run out of entropy and that you're generating keys, in order to view the seed with which each key was generated.
or
2. See a large enough sequence of numbers generated from the same seed with which your keys were generated to enable them to calculate the seed.
#1 is terribly unlikely... and if they can view the seed, they probably already have access to your keys
#2 is equally unlikely. Unless you're for some reason broadcasting lots of random numbers from /dev/urandom at the same time you're generating keys, the only way they'd see a string of numbers generated from that seed would be to see your private keys.
And just for fun... #3. Bitcoin keys are generally single-use. You sign a transaction, then your change is deposited to a new address/key. What that means is that the keys are not vulnerable to the same type of attacks that long-lived keys might be. An RSA key used for securing SSL handshakes on a website might be used billions of times, and an attacker can request new data to be encrypted by it any time he wants. A key that encrypts your harddisk might be used to encrypt terrabytes of data. A lack of entropy in a key with those types of usages might be vulnerable to some sort of statistical analysis. A key that gets used once and thrown away (like Bitcoin keys are *supposed* to) just doesn't have the kind of attack surface area that warrants a 100% random guarantee.
I applaud your security consciousness (I wish my clients would think more like this!), but in this case I think the existing implementation is more than "safe enough". If you're still wary, I think it's a matter of changing 2 lines of openssl's unix_rand.c (I might have the file name wrong) and openssl will always pick /dev/random first