Generating private keys for the paranoid

in #bitcoin6 years ago

I made some posts about how to generate your private keys on an offline machine. In these posts I was using os.urandom to generate entropy. But the safest way for the most paranoid is to generate the entropy yourself. Below I present a simple few lines python notebook for the people that really need to have a 100% safe key.

Note that the notebook uses hashlib, binascii and base58. But you can make sure that these work as intended by locally testing and comparing to online implementations.

il_340x270.1352009072_c6cq.jpeg

The entropy is generated from dice rolls. The clean version is to flip a coin 256 times and record the outcomes. Since that can be a bit tedious it is also possible to roll a 6-sided dice 100 times or a 10-sided one 78 times. But be aware that the dice generate a bit more entropy than the coins. While this sounds great in theory we are now left with the task to compress the entropy back into 256 bit. I use a simple modulo operation to do this, but this ends up with slightly less then 256 bits of entropy. In practice not a big deal, but why go through all this trouble and end up with less than 256 bit?

This problem is easily fixed by rolling a few extra times before taking the modulo. Now the result becomes indistinguishable form true 256 bit of entropy. Note that the coins or a 16-sided dice do not have this problem. But 16-sided dice are rare and coin-flipping is tedious.

Screenshot 2018-07-03 23.24.06.png

Sort:  

what are the chances of collision when you stuff it back into 256 bit? Seems like the cryptographic keys which use the parabolic points are better

When you are worried about collision you should use the coins or 16-sided dice as they give you exactly 256 bit. For the dice exactly 78 rolls of d10 is quite bad. 100 d6 is better. But when you roll a few extra times this problem is almost completely removed. When the random number is much bigger than the modulo, the residual bias becomes negligible.

But anyways, for an attacker to exploit this the attacker needs to know how you generated the key. And since this is not a common technique and the advantage you get is still small (one or two bit in the worst case) i dont think this a real concern.

There are certainly better ways, but the idea is to generate the entropy purely offline, without using technology. In that case the only better idea I am aware of is using a geiger counter and collect entropy from cosmic rays or radioactive decays. But that is far more complex than rolling 100 dice.

Mind blown! Here I was thinking you could just randomly make up a private key!

You can, but you still need to run two rounds of sha256 and b58 encode it to meet the bitcoin conventions. In ethereum for example you do not need to do this and the random number is your key in hex-format.
Instead of rolling dice you may choose any 78 digit number and then run the python code above on it to get a valid bitcoin private key.

But I would strongly advice against it. Humans are very bad at generating random sequences and what you end up with will have a lot less entropy than 256 bit. I dont think an attack on such an address is currently feasible, but in the future it might be possible.

Sounds like you know what you’re talking about!

Congratulations you were chosen for one of our five free daily resteems! Keep up the good work!

Resteem your Posts to 10400+ Followers — just send 0.1 SBD or STEEM to @yougotresteemed with link in memo (you also will receive a 100% upvote)!

For daily bloggers we offer a Resteem subscription including at least one Resteem a day and a daily feature + daily upvotes!

Wanna sell your Votes or looking for an Upvote-Bot? Try Smartsteem or Steemfollower for more Upvotes on your posts!

Hi i gave you an upvote dont forget to follow me for future upvotes & i always follow back
fb/john.thephotoeditor.56

Coin Marketplace

STEEM 0.26
TRX 0.11
JST 0.033
BTC 64507.66
ETH 3080.07
USDT 1.00
SBD 3.85