Are dices for generating seed words fair?

[dkbit98]

I recently saw interesting discussion about casino dices that are being used for generating seed words for Bitcoin, and someone asked a question can you really trust dices.
Dices need to be properly balanced if we want to have real random number generation, and many cheap chinese dices are often not balanced at all.
Easy way to check if your dices are balanced is by using something called Dice Caliper, and you can easily find them in Vegas and other places where gambling is popular.
There is also a way to 3d print your dice caliper (like shown in image below) or use alternative way for testing if your dices are balanced is by using salt water.


https://orange.surf/dice-calipers/

If you have 3d printer available you can even go step further and print your own weighted balanced dices, and be 100% sure you are getting random results.
OrangeSurf made all .stl and .step files available for free on his github page, but you can always support his work with donations.
I personally prefer version 1 dices with sharp edges, like they are used in casinos, version V3 is chamfered and it works just fine, version 4 is containing m8 nut inside and printer needs to pause for this.


https://github.com/orangesurf/weighted-die

Now let's start 3d printing and generating some true randomness

PS
If you find this information useful consider visiting OrangeSurf donation page.

[1713418601]

1713418601

[1713418601]

1713418601

[Welsh]

Anyone that's willing to use a known weighted dice, and compare the results to one that is completely balanced, would be appreciated . I'm guessing there would be some sort of bias, but I imagine it would still largely depend on the power/speed of the person throwing it.

In casinos, the throwers (if they aren't using a automatic machine) have very likely got into a habit, and therefore throw the same dice, the same way, at the same projective/angle/technique. However, my technique, and speed/power will differ from if you threw it. So, even though the dice might be weighted, you would assume we would get vastly different results regardless. There could be a small bias to a certain side of the dice due to the balancing issues, but without knowing what sort of bias that is, as it could be very small, I don't think it's something we really need to be worried about.

Personally, while it might be something to consider, I don't think checking if your dice are weighted perfectly is something that's totally necessary. If you are going to be generating a seed with dice, then just make sure you're throwing at a different angle, and intensity every time.

[pooya87]

Here is a complementary idea: mix the result

You want to make sure that the final key/seed you produce is not affected by any kind of bias then generate your entropy using the dice then generate another entropy using another source (easiest is using a computer RNG) and then mix the two results.
It could be a simple computation of HMACSHA256 to derive a 256 key (used as a private key or a seed to BIP39/32) where one entropy is your key and another is your message.

This way you aren't relying on one source of entropy and can eliminate the bias well enough.

[BlackHatCoiner]

Here is a complementary idea: mix the result

Extending the proposal: Use the hash function thousands of times. Not only you ensure that a dice bias isn't enough to betray you, but you also make it much harder for an attacker to find your entropy.

For example, let's assume that one of the dices you use has a 50% chance of returning the number 6. Let's also assume that your RNG is weakened. Now it's much easier for an attacker to hash the dices' entropy mixed with the semipredictable generated number. But, if you use the hash function twice, you've just made it two times more difficult. Do it a few million times and you've made it realistically impossible.

I can't believe how paranoid, schizophrenic and miserable I've become since I made an account here. 

[DaveF]

When throwing dice at a casino the shooter has to have the dice hit the back wall of the table. The casinos want that to happen because when the dice hit the back wall they believe the dice then become fully random. Many casinos tend have the wall covered in a multi angled surface. Doing it a home, not so much if you are just throwing them on your computer desk.

However, with the availability of dice with up to 120 sides you can actually come up with some really ways to do things.

-Dave

[pooya87]

Here is a complementary idea: mix the result

Extending the proposal: Use the hash function thousands of times. Not only you ensure that a dice bias isn't enough to betray you, but you also make it much harder for an attacker to find your entropy.

For example, let's assume that one of the dices you use has a 50% chance of returning the number 6. Let's also assume that your RNG is weakened. Now it's much easier for an attacker to hash the dices' entropy mixed with the semipredictable generated number. But, if you use the hash function twice, you've just made it two times more difficult. Do it a few million times and you've made it realistically impossible.

I can't believe how paranoid, schizophrenic and miserable I've become since I made an account here. 

That sounds like overkill to me because the dice has to be really broken to create a bias big enough to make the end result weak, same with the RNG. But hey it never hurts to add more cost to your process as long as you can endure the extra time it needs.
In that case I'd suggest using an expensive KDF such as scrypt to derive the key instead of increasing the number of hashes you compute. You can change scrypt parameters to use a lot of memory to maximize the expense.

[Dabs]

There is an analog method of using 2 or 3 dice rolls to "unbias" any biased dice rolls. Then you can use that as your RNG. Of course, for 256 bit equivalent, instead of rolling 100 times, you would roll 200 or 300 times. Or more. Not sure of the math.

I just bough a pack of 100 colored dice from amazon for kids to play with, but I keep it. They seem random enough and you can toss the whole bunch all at once, line them up at the bottom of a box and use that. Your physical security is more important than the perceived bias of the dice. Do it in a room where it is very noisy and under a blanket so that no one else can see or hear the dice rolls.

If you are writing it down, make sure there are no impressions left under the paper (use a clipboard or other hard surface to write on top of.)

[o_e_l_e_o]

Now i wonder how many throw deemed enough for comparison between 2 dices. I wouldn't bother throw 100 times for each dice.

You wouldn't need to roll both dice - you assume the fair die would produce a perfect spread of results given enough rolls, so 1/6th one, 1/6th two, and so on.

To test a die against this ideal, then you would want to use a Chi Squared test. Very simply, the steps would be:

• Roll the die x number of times
• Record how many times each number (from 1 to 6) shows up
• For each number, calculate the difference between how many times it actually showed up and how many times you would expect it to show up (which would be x/6)
• Square this number
• Divide the result by the number of times you would expect it to show up (x/6)
• Add up the 6 results to find your Chi Squared value
• Look up your result in a Chi Squared look up table (with 5 degrees of freedom for a 6 sided die), such as this one: https://people.richland.edu/james/lecture/m170/tbl-chi.html

The closer your Chi Squared result is to zero, the better. So, for example, at 5 degrees of freedom and a critical value of 0.10, that means that a fair die would produce a Chi Squared value of higher than 9.236 on only 10% of trials.

Now, this requires a minimum of 5 expected observations per possibility, so 30 rolls for a 6 sided die. But there fewer rolls you use, then the less certainty you have and the less likely you are to detect any bias, particularly small bias. I would be rolling at least 100 times to have a reasonable amount of certainty.

[LoyceV]

I'm all for paranoid security, but isn't this too much unnecessary? Even if your dice isn't perfect, and even if it throws a 6 for 20% of the time, there's no way someone is going to reproduce your results to get your private key.

[o_e_l_e_o]

Even if your dice isn't perfect, and even if it throws a 6 for 20% of the time, there's no way someone is going to reproduce your results to get your private key.

But how are you going to known your dice is "safe enough" unless you test it? Perhaps it throws a six 40% of the time instead. If you ended up with a string with more sixes than you expect, how do you know if it is just random chance or if your dice is flawed?

In your example of a dice which rolls a six 20% of the time, then you reduce the min-entropy of each dice roll from 2.585 bits to 2.322 bits. That's 0.263 bits per roll. Might not seem like much, but over 50 rolls, that becomes significant.

[Dabs]

Just go buy casino dice. They are clear so you can see inside and through, and the ones that actually are used or come out of casinos have been "tested".

Most dice, even low quality ones, are random enough, particularly if you are going to roll them a hundred times to generate a private key or a seed or something. Besides, you'll only do this once (or very few times.)

There are coin flips, shuffled decks of cards, and dice. Dice are a cheap method, if rather inconvenient.

If you plan to generate a whole bunch of random numbers, you might want to go with hardware RNGs; there are some you can plug into USB ports and are basically the equivalent of rolling dice continuously.

If you are going to make a seed phrase or use something like Electrum on an offline / airgapped machine, the OS takes care of all that for you, just leave the device running for a few hours, maybe a day or two, so it can collect entropy before generating the cold wallet.

[LoyceV]

But how are you going to known your dice is "safe enough" unless you test it?

I must admit it was based on an assumption, but given my own personal experience, I think I can affirm this statement:

Most dice, even low quality ones, are random enough

In your example of a dice which rolls a six 20% of the time, then you reduce the min-entropy of each dice roll from 2.585 bits to 2.322 bits. That's 0.263 bits per roll. Might not seem like much, but over 50 rolls, that becomes significant.

My point was that 20% is a huge deviation, much larger than any real flaw in a simple standard dice. So I personally wouldn't worry about someone brute-forcing my 100 dice throws.

[Dabs]

As an interesting project or experiment, go do a thousand dice rolls (which is good for 10 seeds) and track the results. I mean, write down how many got 1 and how many got 6, and everything in between.

You should be able to see a pattern, or if there is no bias then you should be able to see that each number is about 1/6 of a thousand. Basically 166 for each number, more or less. Since it is random, you might get 200, you might get 100, but the more rolls you do, the more each number will approach the 1/6 of xxxx.

If you have more than one dice, you'll have to do it for each one, or you do it as a whole for all of them. Since I have a hundred actual physical dice of different colors, I wouldn't even bother to check if each one is "fair" or square. I'd go measure the whole thing (in this case, roll them all at once, 10 times.)

That should be a fun afternoon... "Papa, why are you rolling dice but not playing any game?"

[o_e_l_e_o]

I don't agree with the premise that dice will be "random enough" without testing that. If you don't trust the randomness of your OS, which has been designed, built, and tested by experts in the field of cryptography, and want to do things manually, then just picking up a bunch of random dice and shrugging your shoulders is irresponsible. If you don't test your dice, how can guarantee your min-entropy is sufficient? How can you guarantee your Shannon entropy is sufficient? How can you be sure whatever randomness extraction algorithm you choose won't amplify your weak entropy?

I see this as similar to people who don't double check addresses and fall victim to clipboard malware. If you are planning to use dice to generate a super secure offline wallet, then you can spend 10 minutes to ensure those dice are fair. If you don't want to do that, then you should use something like a von Neumann debiasing approach, but given its inherent inefficiency, you'll probably end up rolling more dice than if you just tested whether your dice are fair to start with.

[LoyceV]

If you don't trust the randomness of your OS, which has been designed, built, and tested by experts in the field of cryptography, and want to do things manually, then just picking up a bunch of random dice and shrugging your shoulders is irresponsible. If you don't test your dice, how can guarantee your min-entropy is sufficient?

The main difference is that I can easily verify a dice is (more or less) random, but it's very difficult to verify any wallet doesn't produce a pre-recorded seed. The wallet is a black box, while the dice has a very obvious "user interface".

[dkbit98]

Personally, while it might be something to consider, I don't think checking if your dice are weighted perfectly is something that's totally necessary. If you are going to be generating a seed with dice, then just make sure you're throwing at a different angle, and intensity every time.

This is not enough, and why would you use anything that is not fair and verified from beginning in the first place.
For truly random results you need random tools that is not dependent on your arm angle or intensity you throw them.

You want to make sure that the final key/seed you produce is not affected by any kind of bias then generate your entropy using the dice then generate another entropy using another source (easiest is using a computer RNG) and then mix the two results.
It could be a simple computation of HMACSHA256 to derive a 256 key (used as a private key or a seed to BIP39/32) where one entropy is your key and another is your message.

That is something like Trezor hardware wallet is doing, I don't like it and I think it's not good enough.
Computer RNG is not truly random, so I don't see any point in mixing random stuff with non-random, you are probably just reducing randomness.

Cool idea. But since since most people don't have 3D printer, i'll just stick to OS RNG and optionally my mouse movement.

fyi OS RNG is not generating true random result and it can be reporduced.
3d printers are very cheap today, and you can print anything locally even if you don't own one.

I'm all for paranoid security, but isn't this too much unnecessary? Even if your dice isn't perfect, and even if it throws a 6 for 20% of the time, there's no way someone is going to reproduce your results to get your private key.

I think we all saw movies and documentaries with weighted dices used for cheating, and testing if you dices are balanced is trivial job.
It's not like you have to put aluminum thin foil and fo complex math equasion to do it.

Just go buy casino dice. They are clear so you can see inside and through, and the ones that actually are used or come out of casinos have been "tested".

I wanted to order those clear dices and I found one cheap online, but than I found more information about this dice caliper.
There are some big shipping delay now from China, so I am not sure I could wait for them to arrive, but I would like to see if they are actually balanced or not.
I don't want to wait for hours waiting for computer that just can't generate true randomness that can't be reproduced.

[o_e_l_e_o]

The main difference is that I can easily verify a dice is (more or less) random

Yes, but only if you actually verify it. Just trusting that "Well, this die is probably good enough" is, well, not good enough. That approach is fine for a game of Dungeons and Dragons or Monopoly, but not for generating a bitcoin wallet.

Don't trust; verify.

[BlackHatCoiner]

Relative thread: How can you verify the randomness that's coming from a hardware?

Don't trust; verify.

There are different levels of trust, though.

You don't like trusting banks? Use bitcoin. Less trust? Run your own full node to verify that what you're viewing is true. Less trust? Verify the authenticity of your wallet software, to avoid being a hacker's victim. Less trust? Learn the programming language(s) the wallet software is written to and check every single line of the source code, to verify that the developers aren't dishonest. Less trust? Use an open-source OS. Less trust? Do the same procedure for the source code of it. Less trust? Be your own RNG.

Sure, don't trust; verify!, but you're nuts if you do all of the above. And you still have to trust your coding skills. 

[o_e_l_e_o]

Sure, don't trust; verify!, but you're nuts if you do all of the above.

Except I do most of the above. And if I'm spending hours and hours on verifying software, running a node, examining code, running airgapped set ups, running live OSs, creating secure back ups, and all the other things I do maximize my security, then it is unforgiveable that I wouldn't spend 10 minutes to check a die is fair before using it to generate a wallet.

[BlackHatCoiner]

Except I do most of the above.

That's the spirit. I'm just pointing out how falsely it is to use this phrase. For example, I rarely look into Bitcoin Core and there's no way I'll ever look into Linux Mint, which means I take the devs' word for it. I've verified ThomasV's signature, I'm running my own node, I'm using an open-source OS, there's no way I trust my savings to a reckless system.

I can say it out loud to not trust, but to verify; but to an extent.