Creating private key from 2 different RNG:s?

[aplistir]

Is it safer to use 2 different random number generators in generating a secure private key?

If your RNG is truly random then that is excellent, and you do not need anything else in generating your private key. But how can you know?

If you suspect that one or the other RNG is perhaps not truly random, or that it might be somehow compromised, wouldn't it be a good idea to generate 2 private keys in different ways, and then XOR them together to get one that is really random?

I am planning to use bitaddress.org and urandom()  (=operating system RNG) to get 2 256bit random numbers and then XOR them together.

The problem with bittaddress.org is that it is someone else's code. I do not know if there is a bag-door/vulnerability in it. I do know bittaddress.org is well trusted, but what if a hacker has just changed the code in the web-page?
Problem with urandom() is that when it has enough entropy it is a good RNG, but if it doesn't have enough entropy, then it can give insecure random numbers. And you can not know., because urandom() does not tell you if entropy is low.

In my opinion combining these 2 by using XOR should give reliable private key even if one of the RNG:s is not as random as it should.

Opinions?

[1713937014]

1713937014

[1713937014]

1713937014

[1713937014]

1713937014

[1713937014]

1713937014

[mattcode]

You could generate the private key yourself, by rolling a dice. There are some guides on the internet, but this one using bitcoin-bash-tools seems easy enough to follow.

[bob123]

Problem with urandom() is that when it has enough entropy it is a good RNG, but if it doesn't have enough entropy, then it can give insecure random numbers. And you can not know., because urandom() does not tell you if entropy is low.

Getting 256 random bit from urandom is not too hard. Just boot your PC, do some stuff for a minute, and you will have an entropy pool which already is way bigger than just 256 bits.

You can also check the entropy pool witht his command:

Code:

cat /proc/sys/kernel/random/entropy_avail

If it returns a number >300, you are good to go to use urandom as your RNG.

You could generate the private key yourself, by rolling a dice.

I would not recommend this.
Rolling a dice with the same hand, the same dice, the same table is WAY less random than using a proper RNG (like dev/urandom).

[TheArchaeologist]

You could generate the private key yourself, by rolling a dice. There are some guides on the internet, but this one using bitcoin-bash-tools seems easy enough to follow.

Or you could flip a coin 256 times and use a 0 for heads and a 1 for tails... But I agree with bob123: there a better/faster ways!

[theymos]

Do not use xor to combine random data. If one random source is compromised, then the whole scheme is compromised. Instead, put all random data into a string and hash it with a cryptographic hash; the result is your combined random data. Bitcoin Core does this when generating private keys.

See also: https://en.bitcoin.it/wiki/Passphrase_generation

I am planning to use bitaddress.org

Using a website is insane, and even if you download it, I'd be very uneasy about using anything browser-based.

[RocketSingh]

even if you download it, I'd be very uneasy about using anything browser-based.

Why? Never heard of any security breach in offline usage of bitaddress.org!

[theymos]

Why? Never heard of any security breach in offline usage of bitaddress.org!

The reason that you don't use it online is that the owner of the site could introduce a backdoor. But if you download it, then you're exposed to basically the same risk. If bitaddress.org is compromised when you download it, then the version you download could just as easily contain a backdoor. You don't even need to be online when you use it for the backdoor to be effective, since a smart attacker can mess with the crypto in such a way that you reveal your private key to them when you publish a signed transaction (eg. by using k values calculated such that they are predictable to the attacker, but not to anyone else).

Of course, software like Bitcoin Core also could contain a backdoor, but Bitcoin Core has a lot more (justified) paranoia surrounding this, so you probably at least verify Wladimir's signatures, and you could verify additional signatures via gitian.

Also, browsers and JavaScript have a history of poor security. Browser extensions are often found spying on users, policies which are supposed to isolate JS instances are sometimes found subtly flawed, JavaScript crypto is very often found to be broken, etc.

[RocketSingh]

The reason that you don't use it online is that the owner of the site could introduce a backdoor. But if you download it, then you're exposed to basically the same risk. If bitaddress.org is compromised when you download it, then the version you download could just as easily contain a backdoor.

Why would anyone download it from bitaddress.org? Is not it standard to download from https://github.com/pointbiz/bitaddress.org, where the last commit took place on Dec 25, 2016?

[vit05]

The reason that you don't use it online is that the owner of the site could introduce a backdoor. But if you download it, then you're exposed to basically the same risk. If bitaddress.org is compromised when you download it, then the version you download could just as easily contain a backdoor.

Why would anyone download it from bitaddress.org? Is not it standard to download from https://github.com/pointbiz/bitaddress.org, where the last commit took place on Dec 25, 2016?

I also do not understand why they always imagine it. That someone will download the entire page directly from the browser. At the bottom, it has links to direct download the Git, or download a zip, which is also the git version from 2 years ago.

Caution is never too much. But in this case, it seems exaggerated. Since for more than 2 years, this page has been used frequently and I have not found any reports about security holes.

[gmaxwell]

Personally I would not use xor as a rng combiner.   If one of your functions is correlated with the other you risk canceling it it. This can happen due to error e.g. second RNG fails, first ones output is reused or if the second RNG is malicious code that can observe the output of the first. Instead, I would prefer to use a regular cryptographic hash function as the combiner.

(and, indeed, Bitcoin Core uses a hash function as the combiner)

[frankerstein]

but why?? needed?? never seen any security breaches??