Using six sided dice to generate 12 random words from electrum wordlist

[bitcoiner422]

Since most people use six sided dice and since I don't trust any function within operating systems that claims to collect sufficient entropy for cryptography, I have made a table to choose randomly and uniformly a word from the electrum wordlist using a six sided die or dice. The table can be downloaded here as a .htm file:

https://mega.nz/#!uY5BnDjT!3ak0BqR5aujJMpQDzi3kPDkVd-FVwecXUDP-yTNAnro

Feel free to spread this file.

The table can be used to generate 12 random words using true randomness (dice) thus allowing you to create a private key with electrum. This can for example be used for a brainwallet.

[1713991454]

1713991454

[1713991454]

1713991454

[btchris]

This looks pretty good, but it has a couple of issues...

First, you need a deterministic way to decide which die is #1, which is #2, etc. For example, you could roll them each one at a time, or you could use six different colored dice with each color always representing the same die #, or you could just always read the dice from left-most to right-most however they happen to fall (easy to do objectively if you have Travel Yahtzee). If you don't have some such deterministic method, you will almost certainly introduce bias as you read off the dice in your own personal order.

Second, although your method does create a uniformly distributed mnemonic (sequence of 12 words), a uniformly distributed mnemonic does not produce a uniformly distributed binary seed. That's because about 4 out of every 1000 seeds can be represented by two different mnemonic sequences even though they result in the same list of addresses & keys. To avoid this without changing your method much, you need to:

  1. Create a new wallet from the randomly created word sequence.
  2. Retrieve the seed (from the Wallet menu).
  3. If the word sequence you generated is different from the one you checked in step 2, discard the wallet and start from scratch.

There's a less than 0.4% chance you'll need to do this. If you don't believe that this can happen, restore any wallet whose seed starts with "weary weapon unseen" (and then any 9 words from the list), and you'll see that the seed you later retrieve differs from the one you restored.

Finally... please don't call it a brainwallet. A brainwallet is something that's easy to remember, and typically has very little entropy (bad). Your method has plenty of entropy (good), and is definitely not in the same category as a brainwallet. There are quicker methods, but your method is simple and transparent which I like.

[jonald_fyookball]

don't know what you mean by 4/1000. can you provide example?

also don't really agree with your definition of brain wallet. IMO, defining characteristic of brain wallet is if you can get your coins out using a passphrase without needing any special device or storage, NOT whether it is high or low entropy.

[btchris]

don't know what you mean by 4/1000. can you provide example?

I did, but it was a bit vague...

This mnemonic: "weary weapon unseen like like like like like like like like like" and this one: "sister glide dude near muse sent like like like like like like" both produce the same binary seed (which is this in hex: 0x1003ca7a7000000000000000000000000) and they both produce the same address list (starting with 17A2fgCpcKEbg7CbfiJwAb8sjdEzUWD2y2). Feel free to try restoring both. That means that this address list is two times more likely to be created via your method. If you follow those three steps I mentioned, you eliminate this bias.

4/1000 number comes from this: (# of mnemonic permutations / # of binary seeds) - 1 == (1626^12 / 2^128) - 1 == about 4/1000. So about 4 in 1000 mnemonics correspond to two binary seeds / two address lists.

edited to add: it's much like your REROLL lines. When Electrum goes from a mnemonic to a binary seed, instead of choosing to REROLL (and declare the mnemonic invalid) when it hits a duplicate, it just "rolls over" to the next binary seed instead (via modulus math, it's like saying your NR 1627 would be "like" instead of "REROLL").

When Electrum creates a seed, it starts from the binary seed (one of 2^128), and creates the mnemonic from it, so it doesn't introduce any bias when creating a seed (assuming its CSRNG is good of course).

also don't really agree with your definition of brain wallet. IMO, defining characteristic of brain wallet is if you can get your coins out using a passphrase without needing any special device or storage, NOT whether it is high or low entropy.

Fair enough, but in my experience (not IMO, but rather what I think most people believe them to be) the defining feature of a brainwallet is something human-created and possible to remember (which leads to poor entropy and danger). I have no trouble with a randomly-created brainwallet such as yours, though.

[dabura667]

Since most people use six sided dice and since I don't trust any function within operating systems that claims to collect sufficient entropy for cryptography, I have made a table to choose randomly and uniformly a word from the electrum wordlist using a six sided die or dice. The table can be downloaded here as a .htm file:

http://s000.tinyupload.com/index.php?file_id=85824502831582364441

Feel free to spread this file.

The table can be used to generate 12 random words using true randomness (dice) thus allowing you to create a private key with electrum. This can for example be used for a brainwallet.

http://www.reddit.com/r/Bitcoin/comments/2akdl5/howto_use_your_own_dice_rolls_to_generate_an/

This is better imo.

[btchris]

http://www.reddit.com/r/Bitcoin/comments/2akdl5/howto_use_your_own_dice_rolls_to_generate_an/

This is better imo.

As the redditor eventually figured out, it's vulnerable to modulo bias (even after the improvement, albeit less so). Using a truncated SHA-256 of enough truly random data (e.g. 50 dice rolls or a deck of cards (at least the first 25 cards cards of a very well shuffled deck)) as the initial seed would eliminate any bias (at least any predictable bias, so long as SHA-256 isn't broken, and if it were there'd be much bigger Bitcoin problems).

More concretely, I'd do this (25+ cards seem easier to me than 50+ dice rolls, but pick your poison...)

  1. Shuffle a deck of cards very well.
  2. Record at least the first 25 cards in the deck, e.g. if the first three are king of spades, 9 of diamonds, and ten of hearts, you'd have: ks9dth
  3. Plug your random data into this one-liner in Linux (assuming you have Electrum installed):

Code:

python /usr/local/lib/python2.7/dist-packages/electrum/mnemonic.py `echo ks9dthac3d7d4s... | sha256sum | cut -c1-32`

[jonald_fyookball]

don't know what you mean by 4/1000. can you provide example?

I did, but it was a bit vague...

This mnemonic: "weary weapon unseen like like like like like like like like like" and this one: "sister glide dude near muse sent like like like like like like" both produce the same binary seed (which is this in hex: 0x1003ca7a7000000000000000000000000) and they both produce the same address list (starting with 17A2fgCpcKEbg7CbfiJwAb8sjdEzUWD2y2). Feel free to try restoring both. That means that this address list is two times more likely to be created via your method. If you follow those three steps I mentioned, you eliminate this bias.

4/1000 number comes from this: (# of mnemonic permutations / # of binary seeds) - 1 == (1626^12 / 2^128) - 1 == about 4/1000. So about 4 in 1000 mnemonics correspond to two binary seeds / two address lists.

edited to add: it's much like your REROLL lines. When Electrum goes from a mnemonic to a binary seed, instead of choosing to REROLL (and declare the mnemonic invalid) when it hits a duplicate, it just "rolls over" to the next binary seed instead (via modulus math, it's like saying your NR 1627 would be "like" instead of "REROLL").

When Electrum creates a seed, it starts from the binary seed (one of 2^128), and creates the mnemonic from it, so it doesn't introduce any bias when creating a seed (assuming its CSRNG is good of course).

also don't really agree with your definition of brain wallet. IMO, defining characteristic of brain wallet is if you can get your coins out using a passphrase without needing any special device or storage, NOT whether it is high or low entropy.

Fair enough, but in my experience (not IMO, but rather what I think most people believe them to be) the defining feature of a brainwallet is something human-created and possible to remember (which leads to poor entropy and danger). I have no trouble with a randomly-created brainwallet such as yours, though.

it isn't my method.

But why are we going from mnemonic to binary? once we have seed, that's it.  we plug into electrum and done.

[btchris]

it isn't my method.

But why are we going from mnemonic to binary? once we have seed, that's it.  we plug into electrum and done.

I don't understand what you're asking.... (edited- sorry that I called OP's method yours, my mistake)

In case you don't realize this, Electrum's seed isn't a sequence of words, it's actually a sequence of 16 bytes. When you ask Electrum for the current wallet's seed, it takes its binary seed of 16 bytes, and converts it to the sequence of words (the mnemonic) you see for convenience. Likewise when you restore a seed, it immediately converts the mnemonic back to the original 16 bytes, and saves that to the wallet.

The source of the bias is that some mnemonic sequences (like the example I gave above) convert to the same internal 16 seed bytes, and therefore generate the same list of addresses. These internal seeds are more likely to be created by you algorithm unless you "throw out" the extras using the steps from this post above. Am I being any more clear now?

[jonald_fyookball]

ok, sooooooooo., if those 1626^12 combos give you 0.4% more the 2^128 bits of entropy, so be it.
but is OP method any worse than that?

[btchris]

ok, sooooooooo., if those 1626^12 combos give you 0.4% more the 2^128 bits of entropy, so be it.
but is OP method any worse than that?

Well, I thought the whole point was to replace a potentially faulty OS-provided CSPRNG with true entropy that has near-perfect uniformity.

I don't really see the point with replacing it with one that has obvious bias (even if it's not a lot of bias). In other words, an OS-provided CSPRNG, especially if it's an open-source one, is probably better than any method that definitely has some bias (and it's not like removing that bias is all that hard).

edited to add- practically speaking I think you're right in that it probably doesn't matter, but I'm no cryptographer, so I'd personally prefer to err on the side of safety and not use a method that introduces bias...

[jonald_fyookball]

ok, sooooooooo., if those 1626^12 combos give you 0.4% more the 2^128 bits of entropy, so be it.
but is OP method any worse than that?

Well, I thought the whole point was to replace a potentially faulty OS-provided CSPRNG with true entropy that has near-perfect uniformity.

I don't really see the point with replacing it with one that has obvious bias (even if it's not a lot of bias). In other words, an OS-provided CSPRNG, especially if it's an open-source one, is probably better than any method that definitely has some bias (and it's not like removing that bias is all that hard).

edited to add- practically speaking I think you're right in that it probably doesn't matter, but I'm no cryptographer, so I'd personally prefer to err on the side of safety and not use a method that introduces bias...

probably dice roll is safer and more certain even if it has a slight bias than anything done on a computer.

[btchris]

probably dice roll is safer and more certain even if it has a slight bias than anything done on a computer.

It's pretty hard to say... it seems pretty likely that Linux's and BSDs' CSPRNGs for the most part have a lot of randomness from the environment to use. Of course it's much harder to predict when it comes to closed-source implementations (Microsoft, Intel).

Why use OPs method unmodified when simple changes remove the bias (or when alternatives exist with no bias)?

[jonald_fyookball]

probably dice roll is safer and more certain even if it has a slight bias than anything done on a computer.

It's pretty hard to say... it seems pretty likely that Linux's and BSDs' CSPRNGs for the most part have a lot of randomness from the environment to use. Of course it's much harder to predict when it comes to closed-source implementations (Microsoft, Intel).

Why use OPs method unmodified when simple changes remove the bias (or when alternatives exist with no bias)?

not sayin to use it...just sayin dice and cards are infinitely more transparent than computers.