Pages:
Author

Topic: Entropy during private key generation - page 2. (Read 4317 times)

full member
Activity: 157
Merit: 100
April 18, 2013, 04:56:00 PM
#13
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.
legendary
Activity: 1512
Merit: 1036
April 18, 2013, 02:48:57 PM
#12
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...
legendary
Activity: 1512
Merit: 1036
April 18, 2013, 01:41:26 PM
#11
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.

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..)
full member
Activity: 157
Merit: 100
April 18, 2013, 01:34:26 PM
#10
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.

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.
newbie
Activity: 39
Merit: 0
April 18, 2013, 11:28:15 AM
#9
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.

Here it is.

https://github.com/bjencks/rngd-rdrand
kjj
legendary
Activity: 1302
Merit: 1026
April 18, 2013, 07:30:57 AM
#8
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.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
April 18, 2013, 07:22:12 AM
#7
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.
legendary
Activity: 1512
Merit: 1036
April 18, 2013, 04:51:14 AM
#6
I believe the client uses openssl to generate random bytes

And openssl harvests the entropy from /dev/random
Or can be enhanced with Entropy Gathering Daemon.

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.
sr. member
Activity: 252
Merit: 250
April 18, 2013, 04:41:24 AM
#5
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
newbie
Activity: 42
Merit: 0
April 18, 2013, 02:46:19 AM
#4
I believe the client uses openssl to generate random bytes

yep
legendary
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
April 18, 2013, 02:28:12 AM
#3
I believe the client uses openssl to generate random bytes
legendary
Activity: 3416
Merit: 1912
The Concierge of Crypto
April 18, 2013, 01:47:49 AM
#2
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.
full member
Activity: 157
Merit: 100
April 18, 2013, 12:45:15 AM
#1
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/
Pages:
Jump to: