I don't have any special or new hardware (so, no TPM or Ivy Bridge or later CPU). I don't want to reveal exactly my whole software setup. Not that I have _that_ many bitcoins, but revealing exactly which version of what software I'm running seems to be a very poor security practice.
If your security relies on people not knowing which distro of Linux you're running, I think you need to rethink your security strategy
Based on Bitcoin v.0.8.1, and OpenSSL 1.0.1, Bitcoin calls EC_KEY_generate_key, which is found in ec_key.c (OpenSSL). From there on, it depends on how OpenSSL was compiled as to what will happen next. Presumably FIPS_mode is not enabled... and one way or another it will end up in bn_rand_range (bn_rand.c.), on down through bnrand, and ultimately end up in either RAND_bytes or RAND_pseudo_bytes in rand_lib.c.
Then we get to this little nugget in rand_lib.c:
Code:
const RAND_METHOD *RAND_get_rand_method(void)
{
if (!default_RAND_meth)
{
#ifndef OPENSSL_NO_ENGINE
ENGINE *e = ENGINE_get_default_RAND();
if(e)
{
default_RAND_meth = ENGINE_get_RAND(e);
if(!default_RAND_meth)
{
ENGINE_finish(e);
e = NULL;
}
}
if(e)
funct_ref = e;
else
#endif
default_RAND_meth = RAND_SSLeay();
}
return default_RAND_meth;
}
{
if (!default_RAND_meth)
{
#ifndef OPENSSL_NO_ENGINE
ENGINE *e = ENGINE_get_default_RAND();
if(e)
{
default_RAND_meth = ENGINE_get_RAND(e);
if(!default_RAND_meth)
{
ENGINE_finish(e);
e = NULL;
}
}
if(e)
funct_ref = e;
else
#endif
default_RAND_meth = RAND_SSLeay();
}
return default_RAND_meth;
}
Is there a default engine set? No idea.
Was OpenSSL compiled with OPENSSL_NO_ENGINE? No idea.
If OpenSSL heads off into ENGINE_get_RAND on your system, what engines will it find? No idea.
If it makes it to RAND_SSLeay, this is OpenSSL's internal PRNG. OpenSSL claims it is a cryptographically strong PRNG suitable for generating keys. It also claims that on *nix systems this is seeded by /dev/urandom automagically.
The Bitcoin source seems to take for granted that OpenSSL will use /dev/urandom, but it also seeds the PRNG with the CPU performance counter. You'll see the note about urandom at the bottom of this excerpt (util.cpp):
Code:
void RandAddSeed()
{
// Seed with CPU performance counter
int64 nCounter = GetPerformanceCounter();
RAND_add(&nCounter, sizeof(nCounter), 1.5);
memset(&nCounter, 0, sizeof(nCounter));
}
void RandAddSeedPerfmon()
{
RandAddSeed();
// This can take up to 2 seconds, so only do it every 10 minutes
static int64 nLastPerfmon;
if (GetTime() < nLastPerfmon + 10 * 60)
return;
nLastPerfmon = GetTime();
#ifdef WIN32
// Don't need this on Linux, OpenSSL automatically uses /dev/urandom
// Seed with the entire set of perfmon data
{
// Seed with CPU performance counter
int64 nCounter = GetPerformanceCounter();
RAND_add(&nCounter, sizeof(nCounter), 1.5);
memset(&nCounter, 0, sizeof(nCounter));
}
void RandAddSeedPerfmon()
{
RandAddSeed();
// This can take up to 2 seconds, so only do it every 10 minutes
static int64 nLastPerfmon;
if (GetTime() < nLastPerfmon + 10 * 60)
return;
nLastPerfmon = GetTime();
#ifdef WIN32
// Don't need this on Linux, OpenSSL automatically uses /dev/urandom
// Seed with the entire set of perfmon data
Really, I don't think you can go wrong. You implicitly trust the Linux kernel developers and the OpenSSL developers when you use their software... You're going to get one or the other's implementation of a cryptographically strong PRNG.
EDIT:
I should add... I saw no evidence that OpenSSL checks entropy_avail when reading /dev/urandom. I wouldn't expect it to anyway -- /dev/urandom is for non-blocking access, and checking entropy_avail just to block and wait for more entropy rather defeats the purpose
