Entropy during private key generation

[mollison]

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/

[1715361204]

1715361204

[1715361204]

1715361204

[1715361204]

1715361204

[1715361204]

1715361204

[Dabs]

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.

[jackjack]

I believe the client uses openssl to generate random bytes

[Hei_]

I believe the client uses openssl to generate random bytes

yep

[Shevek]

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

[deepceleron]

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.

[Remember remember the 5th of November]

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.

[kjj]

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.

[astor]

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

[mollison]

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.

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.

[deepceleron]

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..)

[deepceleron]

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...

[mollison]

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.

[Remember remember the 5th of November]

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.

Everything Bitcoin uses is open source, including Bitcoin itself. So I have no idea why you would want to disassemble the binary. I also think the default seeds that OpenSSL uses are MORE than enough for your needs.

[mollison]

Everything Bitcoin uses is open source, including Bitcoin itself. So I have no idea why you would want to disassemble the binary. I also think the default seeds that OpenSSL uses are MORE than enough for your needs.

I didn't say anything about disassembly. Please read what I wrote instead of ignoring it and saying ignorant things and cluttering up the thread.

And I didn't ask for your opinion about OpenSSL, I asked for specific information (which you have ignored).

[grue]

Everything Bitcoin uses is open source, including Bitcoin itself. So I have no idea why you would want to disassemble the binary. I also think the default seeds that OpenSSL uses are MORE than enough for your needs.

I didn't say anything about disassembly. Please read what I wrote instead of ignoring it and saying ignorant things and cluttering up the thread.

And I didn't ask for your opinion about OpenSSL, I asked for specific information (which you have ignored).

that's what you pretty much said:

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.

just look at the openssl code.

[deepceleron]

I suppose I should have posted that rand_bytes returns an error if there is insufficient entropy pool, so any answer it returns should be as strongly crypto-random as the first.

[mollison]

just look at the openssl code.

I would rather defer to experts than look at crypto code and trust my own shaky assumptions about which code paths are being executed and under what circumstances.

[mollison]

I suppose I should have posted that rand_getbytes returns an error if there is insufficient entropy pool, so any answer it returns should be as strongly crypto-random as the first.

Thanks. I really appreciate the help. I couldn't find rand_getbytes, grepping through both the bitcoin source and the openssl source, though. Did you misremember the function name, perhaps?

As long as there is some verification (either in bitcoin or whatever part of openssl that bitcoin uses) that there is sufficient entropy before generating the first address in a new wallet, that would definitely put my concerns to rest.

[AlphaWolf]

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".


*Note, I mention the requirement of AES-NI with RDRAND because there are several documented cases where manufacturers have disabled AES-NI in BIOS, which causes rngd to fail at startup if there is no TPM or other hardware RNG.