Secure generation of addresses using dice

[agent13]

Discussion of off-line secure computing, paper wallets, backups etc are beyond the scope of this post. I am aware of what steps to take. I also give these steps a lot of attention.

-----

I would like to create a bitcoin address using dice. I don't want to trust software and/or hardware RNG. I don't want to memorize anything. Therefore, I don't think Diceware is appropriate. I also want to prove to myself that my manual RNG is good. I also want to minimize potential issues with the human factor (me). I want to keep things simple.

Should I roll the equivalent of 256 bits of entropy with a standard dice (# of rolls?), and sha256 hash it for the secret exponent? What is a secure method for generating the bitcoin address from there?

I would then import the private key into Bitcoin-QT for spending (out of scope).


1. Is this a good approach?

2. If I append "1", "2", "3" etc to the original series of rolls (seed).. does this constitute a "secure" method for generating a series of addresses?

[1715534016]

1715534016

[1715534016]

1715534016

[1715534016]

1715534016

[deepceleron]

Discussion of off-line secure computing, paper wallets, backups etc are beyond the scope of this post. I am aware of what steps to take. I also give these steps a lot of attention.

-----

I would like to create a bitcoin address using dice. I don't want to trust software and/or hardware RNG. I don't want to memorize anything. Therefore, I don't think Diceware is appropriate. I also want to prove to myself that my manual RNG is good. I also want to minimize potential issues with the human factor (me). I want to keep things simple.

Should I roll the equivalent of 256 bits of entropy with a standard dice (# of rolls?), and sha256 hash it for the secret exponent? What is a secure method for generating the bitcoin address from there?

I would then import the private key into Bitcoin-QT for spending (out of scope).


1. Is this a good approach?

2. If I append "1", "2", "3" etc to the original series of rolls (seed).. does this constitute a "secure" method for generating a series of addresses?

Where were you yesterday?

https://bitcointalk.org/index.php?topic=297077

I coded some python to turn any-sided dice into a full-strength private key, no hashes. The answer is it takes a LOT of dice rolling, less than 100 d6's is not a full-strength key....

[DannyHamilton]

Should I roll the equivalent of 256 bits of entropy with a standard dice (# of rolls?), and sha256 hash it for the secret exponent?

You could, or you could write down each roll as a digit of a number in base(dice), then when you've rolled enough digits, simply use the resulting number as a private key itself.

What is a secure method for generating the bitcoin address from there?

You could just import the private key into Bitcoin-Qt.  Then Bitcoin-Qt will tell you the address.  For added security you could do this on a computer that is not, never has been, and never will be connected to the internet.

1. Is this a good approach?

It's a bit labor intensive, but sure, it'll work.

You could also leave the lens cover on a SLR camera, boost the ISO to the maximum setting available on the camera, and take a 30 second long exposure.  The resulting noise in the image should be random, and have more than 256 bits.  You could then SHA-256 hash the image for the private key.  That's a lot less labor, and you could generate multiple keys/addresses pretty fast.

2. If I append "1", "2", "3" etc to the original series of rolls (seed).. does this constitute a "secure" method for generating a series of addresses?

Or perhaps just generate a single private key as a "seed" and then increment the value of the "seed" to generate a series of private keys? I'm not 100% positive, but I think that's how Eletrum handles deterministic addresses.

[Abdussamad]

You could also leave the lens cover on a SLR camera, boost the ISO to the maximum setting available on the camera, and take a 30 second long exposure.  The resulting noise in the image should be random, and have more than 256 bits.  You could then SHA-256 hash the image for the private key.  That's a lot less labor, and you could generate multiple keys/addresses pretty fast.

Can you use any image you took? Like of a pet or an object or does it have to be high iso noise filled image?

[DannyHamilton]

Can you use any image you took? Like of a pet or an object or does it have to be high iso noise filled image?

You can SHA-256 any sort of data at all to get a private key, but the less "random" the data that you are performing the SHA-256 on the less entropy the private key will have.  Up to you to decide for yourself how concerned you are about that.

[kjj]

I no longer advocate hashing for the final transformation down to the private key.

I now always generate at least 1.5 times as many bits as I'll need (384 minimum for bitcoin, but typically 512 in practice since my tools were mostly set up for grabbing 256 bits at a time), and take the modulus against the order of our curve.*

This solves two problems at once.  It ensures that the private key is not in the wrap-around range, and it should effectively blend as much entropy as possible into the key.  As long as your entropy source isn't absolute crap, the keys generated from this method should have slightly more entropy embedded in them than keys made by hashing.

Methods for the rolling have been described in other threads.  Two two main ones are to treat your rolls as the digits of a base X number, earning log₂X bits per die per roll, and to assign a unique bit pattern to each face, up to the nearest power of two, and filling the other faces with fewer bits.  (d6=00,01,10,11,0,1; d10=000,001,010,011,100,101,110,111,0,1; d12=000,001,010,011,100,101,110,111,00,01,10,11; etc)

Stop when you have enough bits, and then use it directly, XOR the two halves, has or take the modulus.

*  I've heard this described as the NIST method, but I must've missed it when I was reading the specs, and I haven't bothered going back to check, so I'm not making that claim here.