Topic: Dice-generated random numbers and conversion into private/public key pair (Read 10478 times)

I just ordered 32 hexidice

Drop them all at a time, align them with something and you get 128 bits of entropy per drop. Nice electrum seed 

If your dice roll information is truly random, I can't make it less random by scrambling it. The only drawback is that you can't independently verify that the exe isn't doing something nefarious unless you have source code.

You can simply comment out the four scrambling functions near the end of the source (surrounding rolls_to_hex64), and you will get the base6 decoding of your dice as output mod 2²⁵⁶ (hindsight: could have been mod(N-1) + 1).

I would recommend this address generator instead, if you want to type dice into it you can; just the time you take between entering dice rolls will be enough entropy:

https://bitcointalksearch.org/topic/ann-python-paper-wallet-generator-with-strong-randomness-361092

Sorry.  I thought I read this thread fairly carefully, and did not see anyone mention the problems associated with 100-digit base 6 numbers that are > 2²⁵⁶.

Fortunately, maxmint has pointed me in the right direction.

Thanks.  This is clearly the practical solution to this problem.  I should have guessed that Casascius would have worked it out by now.

Similarly 49 six-sided dice rolls give 126.66 bits of entropy, which is still probably more than enough.

But I do think folks should be careful about blindly converting 100 digit base-6 numbers to private keys, for the reasons mentioned above.

I've asked a similar question at the bitaddress thread. I too was concerned that 99 (6 sided) dice rolls would not give 256 bits of entropy. Casascius replied with this answer: https://bitcointalksearch.org/topic/m.3798309

So 99 dice rolls give about 255.91 of entropy. That's not exactly 256 but enough for me to consider this to be safe.

You should read the rest of this thread, as everything you've typed is talked about.

I wrote something that you can type your dice (or anything) into, but it will only need 32 key presses and will be much stronger than the dice:
https://bitcointalksearch.org/topic/ann-python-paper-wallet-generator-with-strong-randomness-361092

This should end the "roll dice" talk.

I made it generate Electrum seeds with a 5 minute mod. Replace the end of the script with this "main" section:


Then run it and pick a seed.

eb3fd08cc9e5e8b84d6664df43869329
a26e94a535640cc9a3328d9623685959
312551f8084215516b09a721b00ee183
e6f9443810f3945142a52844f9d37678
74d7e7225cf22841ae2d4f7177eb1c10
ec51d3e933bdf6ac990fb611b8fb624a
9af6f28e6062f96f71866c6f7c39492f
d37411cfa6dc140bbd117376ac251312
b926a225f7a458e9d1d3d071c76cae68
e55d2eae738785407af71ca7229b9627
4cb4fcfbbc170131e7fe6fdea5fcd89f
4688605e91f5fb02cf6df254e78aaa59
6dca80cb9150f64b6b54ff078fcec946
f2adf8b925cf74d5e7c17af66853b136
238f2053f0031534e7a96a68c9963844
a653695ee91796e1a98427be2e619e6d
4098912769cd719929138edf7df12cca
5bbc479f71203c92495421ee258dad45
b9603f290a0d9cf071ee2d16ce26e65d
607ecf8b5128d1ae6ed032b809eec7de
ecc2fefa282fb169bc82f860d1dee5fc
bb8bdc8d8a8e8933842645884176066f
20d0011175644f13ca51d692f136323a
92152b46c9d5177372de0fa24cd95f05
d519871d0bacba9bd673f9eae7a7aeb2
e0510191d11e6af3ce3c45749b39fdc9
fcf7f4e0302d093ca0bd167d8051bb48
bb19bf51db6420f75fce755c001205fa
519d17f68c7220a31f8cb09c13ae1678
4eeb9f1a33e760d04a8cf1370e1410f9
37b00cf85895a689aa29151e06205a39
fe8082ec08890cc3c4df4a1bf2d35893
1c0fd63e8b75f8d8cae0d02eaa9ae1c3
2bdc23b5bf3d9f076ca1eb7051b09ac3
a3a783c06e1df0e269551f626ca696bf
909e8f72833416e036cfd29f43561fe2
43ca0039f9830c40e9067f3013db4ac2
2d54d817fb0e44e40e6874576eb17a8d
7caa7ecf06ca143a618203bd9798f6a4
3ef11dfded2c0079654f28ae83d15fac
7f7e266faef657ad7438c90ee882393c
67a069a5d418b0a20edfb276778ce570
179c6183113771710ae2d3d64c104870
2f01bf04723e908f8aee0de776c1f99b
6640898e7221f678881d6c0cba11fb9a
709a920233d6e50ea4f72c79ca761acc
e70dda0bb906d585ba05d68a8197d6ce
f1e29fc80907fb9657de73d0c92f3a5f
593fd8fcb423a0d3f8fd53d72a553044

I don't know why you'd use Electrum though, and have all your addresses rely on a number 340282366920938463463374607431768211456 times smaller than a Bitcoin private key.

I have been thinking about generating private keys, or even electrum seeds with dice, and came across some snags that maybe y'all can help me through.

Consider generating a 128 bit electrum seed using a six-sided die (it is more straightforward than generating private keys, because of the range of valid private keys required by secp256k1, but I think the discussion extends to private keys as well).

In order to ensure 128 bits of entropy, the sample-space for your dice-rolls must contain 2¹²⁸ or more elements.  Because the sample space of n dice rolls has 6ⁿ elements, and because 6⁴⁹ < 2¹²⁸ and 6⁵⁰ > 2¹²⁸, we say we need at least 50 six-sided dice rolls to generate 128 bits of entropy.

So how do you convert your 50 dice rolls into a 128 bit number?

One method mentioned in this thread is to treat your dice rolls as a 50-digit base 6 number, and just convert that number to base 2 (or hex).

The problem is not all 50-digit base 6 numbers convert to 128-digit base 2 numbers.  In fact, less than half of them do! This is because 2¹²⁸ / 6⁵⁰ ~ 0.421.

So what do you do if your 50-digit base 6 number converts to more than 128 base 2 digits?  Do you truncate the leading digits? The trailing digits?  Do you perform some other mapping to 128 digit numbers? Are you sure that your resulting set is uniformly distributed over the set of all possible 128 bit numbers?

The problem is worse with private keys, because 2²⁵⁶ / 6¹⁰⁰ ~ 0.177.

These kind of questions make me wonder how bitaddress.org is converting 99 dice rolls into private keys.  Even more concerning is that 6⁹⁹ < 2²⁵⁶! 

What seems far safer to me is do use some other methods mentioned in this thread:

• Disregard any base 6 number that is larger than your desired sample-space and re-roll (tedious)
• Hash your string of dice rolls.
• Use hex dice.

Regards,
Frito_Mosquito

I tested this with a couple of hex keys and Bitcoin QT did not accept them.

Also, I posted about dice generated private keys at the bitaddress thread:
https://bitcointalksearch.org/topic/m.3792411

This is nice. The hex format can be confirmed with this I think -

echo 'obase=16; ibase=6; 0123450123450123450123450123450123450123450123450123450123450123450123450123450 12345012345012345012' | bc

A nice way to input dice throws directly into bitaddress and not have to rely on computer rng.


Separate question - can bitcoin-qt import base16 directly?

Bitaddress.org now also supports base6 dice-generated private keys:
https://bitcointalksearch.org/topic/m.3586486

I like your little app deepceleron. Works for me.

If the input is random, then mixing it with the worst corrupted backdoored random source won't make it less random (as long as the functions are blind to the contents). If the input is not random, mixing it with a good random source will make it random.

A one-time pad is the perfect encryption, I'm using a one-time pad on your dice and throwing it away.

Before, the input was XORed with 0x00000000f (nothing), which reveals the dice rolls and any bias in them.

If your dice were heavier on the 1 side than the 6 side from the pips being drilled, then the "random" number would be biased in a way revealed by a randomness test suite over a statistically significant number of rolls. If I have 100 dice in a dice rolling machine, and die 33 is defective or a camera always reads it's bits incorrectly because a bug died on the lens, I've shuffled around that error and masked it.

Also there is the (non) issue of modulo bias when truncating a nonhex to hex-converted number. I let you type in more dice than required and use the extra bits, however, for non 2^x - sided dice, the number is "extremely slightly smaller than it should be".

Dice are not a quantum phenomena-based random source, and the mere act of putting different shaped ink on each side of a molecularly-perfect cube makes them imperfect physical objects.

Rolling dice is a paranoia level response to NSA backdoored random number generators, I'm just being more paranoid for you.

I've also extended the usefulness of your dice roll, you can continue to cut and paste the same dice into the program and not get identical results.

What taints true entropy is using a hash like sha256, or any other function that maps to a reduced set of bits. Previous hash functions have had successful reduction attacks demonstrated, there is no reason to assume that SHA2 is the perfect hash function.

There is a belief among some people that if you are rolling dice repeatedly many, many times, you can get into a bit of a rhythm such that you start to pick up the dice in almost exactly the same way, and release them in almost exactly the same way multiple times resulting in patterns in the results.

Personally, I suspect that this is generally unlikely, and if it is possible, it would be be unlikely that anyone could predict what your personal patterns would be.

However, if you want to be certain that you aren't accidentally creating predictable patterns in your rolls, I'd suggest placing multiple dice into a cup. cover the opening and give the cup a few firm shakes.  Then dump the dice out onto a flat surface.  The act of the dice bouncing off each other and the cylindrical sides of the cup should be sufficient to randomize the results even if you both drop them into the cup and shake it in exactly the same way every time.

I don't get this. The whole point of using dice was to bypass potentially compromised sources of randomness in our computers, no? Doesn't all that shuffing, seeding and XORing taint our pure dice-generated entropy?

So I am going to ask sort of an obvious question here, but maybe the answer isn't so obvious.  What is the right way to "roll" the die?  I was thinking of just dropping casino quality die from about 10cm above a hard surface.  Is this the best way?  Is there a best way?

Welp, I have plugged away like a busy little beaver, and made a proper dice -> paper wallet app.


I wasn't content merely using dice as a base-6 number. I decided to remove any bias the cryptologists might find in your dice by randomly shuffling the rolls, bits, and hex characters, seeding urandom with your dice, and XORing the private key with system entropy. It's probably idiot-safe even if you just bang on the numberpad.

There's an undocumented feature for testing. At any point when inputting dice, you can put in a special letter to let the computer complete the rest of the dice rolls for you. "g"-generate random dice rolls; "z" - generate rolls of 1; "m" - generate the highest dice rolls possible.

I could maybe make this save the paper wallet info to a file or print at your command, or make Electrum seeds, if anybody even cares.

Addresses and such are calculated with the Python Bitcoin ECC library - https://bitcointalksearch.org/topic/python-bitcoin-ecc-library-supports-signing-transactions-determinstic-wallets-271343

Download links:
http://we.lovebitco.in/dice2key.py (Python 2.7 source)
http://we.lovebitco.in/setup-dice2key.py (for py2exe)

http://we.lovebitco.in/dice2key.exe (Windows 32 bit executable (python 2.7.6/winxp))
md5: be686743bbe03ad8178c35f785e4c6fe *dice2key.exe

You shouldn't trust my exe, but there it is. I've not documented my exact build environment to make it reproducible.

What I would personally do is tack on a letter, say "x" and then use a 3 digit number with leading zeros.

For example:

3315135445366124436162446626244624624266466466622442224426424444624626624246264 464464662624246262224x001
3315135445366124436162446626244624624266466466622442224426424444624626624246264 464464662624246262224x002
3315135445366124436162446626244624624266466466622442224426424444624626624246264 464464662624246262224x003

...

3315135445366124436162446626244624624266466466622442224426424444624626624246264 464464662624246262224x998
3315135445366124436162446626244624624266466466622442224426424444624626624246264 464464662624246262224x999
3315135445366124436162446626244624624266466466622442224426424444624626624246264 464464662624246262224x000

Would give you a thousand addresses.

If it's just a few you need, I'd just roll another 100 times for every address. There is no need to roll more than that for each address, you'll be wasting rolls.

The dice rolls are secure as long as no one else is in the room, and no one else is watching you roll or can see the dice. The computer you use is secure as long as it is offline and is properly wiped or erased or encrypted or everything is run in RAM then completely powered off.

To "properly" roll the dice means you should throw it across the room, and record only the ones that bounce back from the opposite wall. (Or roll it on something similar to a craps table, where it has to bounce from the other side.)

If you're lazy and already have 100 dice, just throw them all at once against the wall and take a RAW picture of everything using a 24 megapixel DSLR camera at the highest ISO setting, then hash the 15 megabyte file for your new private key. Then delete the picture and format the memory card.

Hello there

Note above. Would some one know if above method for generating private keys from a dice-generated seed be "secure" ?

But will Bitcoin-QT import a private key directly? (not WIF) I am aware it has no checksum etc. Or would I need to rely on additional tools to ensure I generate the correct WIF key (example - bitcoin-bash-tools and bitaddress JS).




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



So, about 150 rolls of the dice?

Unfortunately I don't have that problem :p Got into bitcoin too late for that.