RSS Feed

Tag Archives: hexadecimal dice

Bitcoin Key app: Better than rolling dice?

Posted on

Bitcoin Key app for iOSAs a result of the apparently poor numerical distribution observed rolling my hex dice (see this earlier post), I was inspired to create an app to take the place of hex dice for the purpose of creating off-line Bitcoin private keys.

Bitcoin Key is now in the iOS App Store.

(At present it’s available only in the U.S., until I can figure out if it’s exempt from U.S. export regulations.)

The app generates a never-ending stream of random hexadecimal digits. The timer in the top-left corner counts down to the next digit, with a new one every two seconds. The previous digit is also shown here.

Move your finger around the screen to add your own randomness.

To create a Bitcoin private key, simply jot down (or enter into your offline computer running a live CD) 64 of the randomly-generated hexadecimal digits.

Worried that the app is recording every single digit produced and sending it somewhere? It’s not. You’re welcome to watch the wi-fi or your home network with a packet sniffer. Besides, even if it was, the collector of the data would have know way of knowing which of the endless stream of digits you’re actually writing down. Heck, maybe you’re only using every 2nd or 3rd digit produced.

Bitcoin Key uses ANSI X9.31 cryptographically secure random number generation via 256-bit AES in counter mode. The 256-bit key that’s fed into the AES comes from the system’s entropy source (SecRandomCopyBytes on iOS). The RNG is re-keyed from system entropy every minute (the timer in the top-right corner).

AES takes a 128-bit block as input. ANSI X9.31 specifies that this is to be a monotonically increasing value for secure random number generation. For this value, Bitcoin Key uses the system’s high-resolution timer (mach_absolute_time on iOS) as the upper 64 bits, and the user entropy value as the lower 64 bits.

The user entropy value is computed as follows: any time finger motion on the screen is sensed, the x,y coordinates of the finger are multiplied together, and the result is then added to the user entropy value.

Is it better than rolling dice? It depends on how you define “better.” Bitcoin Key includes a stats page that shows you a count of how many times each digit has appeared. I personally find that it has more even distribution compared to the hexadecimal dice I used previously.

And, at $0.99, Bitcoin Key is certainly cheaper than the dice I purchased. Although admittedly, hexadecimal dice have a certain charming appeal, and are a great conversation piece. 🙂

Roll Dice for Bitcoin Keys… Good Idea?

Posted on

I recently read about using physical dice to roll private Bitcoin keys, for example here. Intrigued, I ordered a pair of hexadecimal dice from GameStation.

Hexadecimal Die

Soon I began to wonder… How random are they? Do rolls result in an expected distribution? Can knowledge of the actual distribution characteristics of the dice be used to narrow private keys generated by this method into a practically searchable space, making such keys more susceptible to discovery?

I rolled my pair of hexadecimal dice 1,014 times for a total of 2,028 samples for the pair. Here are the results:

Hex rolls, raw data

Hex dice rolls, histogram

Already a severe underrepresentation of the values 3 and C is observed.

But how about a goodness of fit test? We begin with a null hypothesis that the dice are fair and distribute evenly. The data yield \chi^2 \approx 105. Using a chi square table such as this one and looking at the row for 15 degrees of freedom, we see that the value 105 is off the chart, or p < 0.01. In fact, using this calculator, we see that p < 0.0001. This means the data are very much statistically significant to reject the null hypothesis — indicating that the dice are not observed to be fair over these 2,028 rolls.

Here’s a good article that examines the question of how many rolls give good results for the goodness of fit test.

However, commenter Matthew Neagly makes an interesting point in this post that “the larger your sample size, the more exactly you have to match a potential distribution to not reject a match. So eventually you hit a point where you’re ‘cursed’ to always reject your hypothesis.” In other words, the more rolls, the higher the probability that the test will reject a die as unfair. (He mentions two terms for this phenomenon, “curse of significance” and “doomed to significance,” but I was unable to find any discussion or related use of these terms.)

He also says, “This is one of the reasons why some statisticians favor visual interpretation of plots.” From that perspective, the histogram above is pretty clear.

The dice didn’t have fair distribution for my test… So what? It’s a fair (pun!) question.

At what point are dice “good enough”? Can these dice I’ve acquired, given the apparent wildly uneven distribution observed, be used to create private Bitcoin keys no more susceptible to discovery than keys generated by other means? Is the unevenness attributable to something specific or unique to these two dice or the rolling method/conditions? Or would a similar pattern be observed with other dice, that is, attributable to systemic or common causes in the manufacturing process? Finally, if they are truly fair and random dice, then certainly the exact sequence observed for this test is a valid possibility, however “unfair” it may seem.