Thanks.
I'm having a hard time believing that the answer is that non-straightforward. I mean, probably it uses /dev/urandom except in some weird circumstances that can be ruled out given certain basic assumptions (e.g., standard Linux on x86 without any special-purpose entropy-producing hardware). But yeah, this is just my intuition, I can't actually give evidence for this.
I guess one way to find out (for my particular instance) would be to do some kind of tracing of the actual binary I have to see what files it opens. Assuming it does use /dev/urandom, do you have any idea of how much entropy actually needs to be accumulated before creating another wallet?
And I don't suppose there is any easy way to guarantee some other process doesn't suck up the entropy right before bitcoin uses it?
Honestly, it seems like /dev/random would be better for my purposes, since it'll block until it gets enough entropy. I wonder if I can symlink /dev/urandom to /dev/random or something crazy like that.
Topic: Entropy during private key generation - page 2. (Read 4262 times)
So, again, my question is, can someone who knows about the client code confirm that it's ultimately using /dev/urandom?
The ultimate source of random data for keys is OpenSSL's rand_lib.c. This is where the build options will cause the answer to diverge; when you build Bitcoin, the answer is ultimately dependent upon build config options such as OPENSSL_FIPS (use the FIPS140 engine) and platform.One would need to investigate the gitian-reproducible Bitcoin builds to give an answer about the official binaries; I've read enough OpenSSL code for this answer that I'm not gonna do this...
You might want to buy an entropykey.
Or, a newish Intel CPU with the RDRAND instruction, but that won't feed the entropy pool in linux directly, so you'd need an offline key generator that was written to use it.
Or, a newish Intel CPU with the RDRAND instruction, but that won't feed the entropy pool in linux directly, so you'd need an offline key generator that was written to use it.
Here it is.
https://github.com/bjencks/rngd-rdrand
And surprise, that's not a hardware true RNG, "sorry about your encryption, we lied": http://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed
"RdSeed is to RdRand as /dev/random is to /dev/urandom. It returns 100% entropy (minus epsilon if you're picky)."
...
"In contrast, RDRAND is the output of a 128-bit PRNG (pseudorandom number generator) that is compliant to NIST SP 800-90A. It is intended for applications that simply need high-quality random numbers ."
You'll need a future Intel CPU with the announced RDSEED instruction for a real hardware source (although non-convergent, as good as flipping an unfair coin), or a 1999-vintage Intel 810 or 840 chipset, for a real hardware RNG from Intel (I've got one of those in my firewall..)
Nobody has answered my question. Thanks anyway for those who said intelligent things. However, if someone can provide an actual answer, I'd appreciate it.
It's not true that OpenSSL uses /dev/random, or at least, that's a misleading thing to say.
[1] http://www.openssl.org/support/faq.html
So, again, my question is, can someone who knows about the client code confirm that it's ultimately using /dev/urandom?
If so, is making sure /proc/sys/kernel/random/entropy_avail is a high enough number (and what number is "high enough"?) sufficient?
Personally, I think I know the answers to these things, but I'm not certain, so I wanted to see if someone who knows can back me up. I tried looking at the code before I started this thread, but the answer wasn't obvious, and I'd rather avoid sinking hours into reading the code more carefully.
It's not true that OpenSSL uses /dev/random, or at least, that's a misleading thing to say.
Quote
All OpenSSL versions try to use /dev/urandom by default; starting with version 0.9.7, OpenSSL also tries /dev/random if /dev/urandom is not available. [1]
[1] http://www.openssl.org/support/faq.html
So, again, my question is, can someone who knows about the client code confirm that it's ultimately using /dev/urandom?
If so, is making sure /proc/sys/kernel/random/entropy_avail is a high enough number (and what number is "high enough"?) sufficient?
Personally, I think I know the answers to these things, but I'm not certain, so I wanted to see if someone who knows can back me up. I tried looking at the code before I started this thread, but the answer wasn't obvious, and I'd rather avoid sinking hours into reading the code more carefully.
You might want to buy an entropykey.
Or, a newish Intel CPU with the RDRAND instruction, but that won't feed the entropy pool in linux directly, so you'd need an offline key generator that was written to use it.
Or, a newish Intel CPU with the RDRAND instruction, but that won't feed the entropy pool in linux directly, so you'd need an offline key generator that was written to use it.
Here it is.
https://github.com/bjencks/rngd-rdrand
You might want to buy an entropykey.
Or, a newish Intel CPU with the RDRAND instruction, but that won't feed the entropy pool in linux directly, so you'd need an offline key generator that was written to use it.
Or, a newish Intel CPU with the RDRAND instruction, but that won't feed the entropy pool in linux directly, so you'd need an offline key generator that was written to use it.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
I believe the client uses openssl to generate random bytes
On Windows it creates random bits from a "screenshot" of the screen if I understood it correctly, additionally it also calls CryptGenRandom API for even more random bits. I believe the client uses openssl to generate random bytes
And openssl harvests the entropy from /dev/random
dev/random can have seed data written to it. More data can be fed with a patch: http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt to use hardware sources like sound card or webcam noise.
I believe the client uses openssl to generate random bytes
And openssl harvests the entropy from /dev/random
EDIT: I've just remembered that I installed the package haveged to keep a good pool of entropy in /dev/random
I believe the client uses openssl to generate random bytes
yep
I believe the client uses openssl to generate random bytes
Dunno about linux, but in general you can boot it, do random stuff (without connecting to the internet), then create several wallets.
You launch bitcoin-qt, let it create a wallet, encrypt it (optional), then shut it down.
rename that wallet.dat to wallet-01.dat or something.
Repeat.
rename the new wallet to wallet-02.dat or something.
Repeat.
You could also use the standard client to just generate lots of addresses by using -keypool 500 or 1000. Then extract those addresses from all the wallets using pywallet.
If you are concerned about entropy, you simply discard the first wallet.
You launch bitcoin-qt, let it create a wallet, encrypt it (optional), then shut it down.
rename that wallet.dat to wallet-01.dat or something.
Repeat.
rename the new wallet to wallet-02.dat or something.
Repeat.
You could also use the standard client to just generate lots of addresses by using -keypool 500 or 1000. Then extract those addresses from all the wallets using pywallet.
If you are concerned about entropy, you simply discard the first wallet.
I want to create a bunch of fresh, empty wallets with the standard client. (Why? Having multiple wallets is something I want for security reasons, and this is just a relatively hassle-free way to do it.)
The most convenient way for me to do this is using a Linux live distro, but I'm worried there my not be enough entropy on such a system.
Can I just check /proc/sys/kernel/random/entropy_avail and make sure this number is above 200? (I'm getting this advice from [1]).
In other words, does the client (or the libraries it's using) actually use /dev/urandom, and if so, what is "enough" entropy?
Thanks.
[1] http://major.io/2007/07/01/check-available-entropy-in-linux/
The most convenient way for me to do this is using a Linux live distro, but I'm worried there my not be enough entropy on such a system.
Can I just check /proc/sys/kernel/random/entropy_avail and make sure this number is above 200? (I'm getting this advice from [1]).
In other words, does the client (or the libraries it's using) actually use /dev/urandom, and if so, what is "enough" entropy?
Thanks.
[1] http://major.io/2007/07/01/check-available-entropy-in-linux/
Jump to: