You're going to see a read to /dev/urandom on a Linux system one way or another.
Well, yes, and no. I mean, if you do strace -o output vim (for example), you will not see /dev/urandom. So, what the output I observed is telling me is (a) /dev/urandom is being used (though as you say, exactly how it's used is unclear); (b) /dev/random is not being used (since it doesn't appear in the trace). Of course, we pretty much highly suspected all this from looking at the OpenSSL code. Anyway, this will provide an easier test for people in the future.
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.
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.
Thanks, this is an extremely helpful clarification. Gmaxwell made very similar points in IRC, but it's helpful to see it all laid out in one place. This explains exactly why the warnings in man 4 random about long-lived GPG/SSL/SSH keys do not apply to long-lived Bitcoin keys, which I didn't quite 100% understand as of my last post (otherwise I would have said it).
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
I tried that, pretty sure I did it "correctly" (in the sense that I made the obvious changes), and the compile was fine, but there are a bunch of post-compile checks, and while a bunch of them passed just fine, eventually I hit one that did not pass. I think the problem had to do with the test blocking on /dev/random (remember, my machine tends to have very low entropy), and I think the blocking somehow triggered an error - perhaps some kind of timeout. I didn't really investigate. If someone bothers to get it working, hopefully they'll share here in this thread.