I find dice very interesting, and I'm also a big radio and cipher enthusiast and started thinking about how random numbers are generated. In theory dice should provide really good random numbers, a lot better than if I had to create them my self. Good random numbers are important for both games and encryption, and they are often created with a computer doing a chaos algorithm together with some kind of seed(mouse speed, time between key presses etc). Throwing a dice should be just as good, and probably better for generating the entropy needed for a good random number. In theory dice could have problems with entropy since the different number of dots makes the dice more or less likely to snag on one side, and they are probably also slightly unbalanced in the micro grams level.
For this experiment I got a number of Chessex D6 dice in different colors, a Raspberry Pi 4 with a Picamera 2.1, and a geared 12v DC motor from Amazon(JGY370), together with a bunch of 3d-printed parts.
The working principle for this dice testing machine is that the dice are all placed in the bottom of a barrel, a rotating mechanism together with a ramp in the bottom rotates at 100 rpm for 5 seconds. After this the Picamera takes an image of the dice and uses OpenCV to read their values. Software is written in Python with a lot of help from AI and connecting different example codes together. The Raspberry Pi controls the electric motor with a BC547c transistor.
OpenCV uses Blob-detection to find the dots on the dice, these are all dots that have the right size, circularity and contrast. This helps the program to avoid counting dots on the sides as dots, since they are not circular viewed from above. After this they are clustered with DBSCAN, to get them counted in the correct way. This is a bit tricky and needs some fine adjustment, otherwise two dice showing 2 and 1 could be counted as one die showing 3. Detecting the blobs/dots also needs a bit of work since its sensitive to contrast, light and shadows. I found that the dark read dice with white dots was easiest to work with, especially on the green bottom.
The results!The code does a quick quality control to check that there are 5 dice and no die has more than 6 dots, if this is the case the results are scrapped. Otherwise the result is written to a text file. The main issues here has been that the die that are on top of the ramp are at a slight angle towards the camera, and the blob detection some times miss the dots. I had to put a couple of stickers over screw holes in the bottom, they were falsely detected as dots sometimes.
During testing the dice testing machine run for 200 throws with 5 dice, a total of 1070 approved die readings. I put the results into a histogram to try and see if they were truly random, and the value 1 seams more common than the other results. It might just be coincidence, but I have a feeling that some it the dice has been read as a lower value due to the angle they present to the camera lying on the ramp. Compared to computer generated random dice results below, its not that bad.
One throw of a dice contains 2.585 bits or information, in comparison a coin toss has 1 bit. One toss in the machine takes about 8 seconds, so we can produce somewhere around 100 bits(with 5 dice in the barrel) of entropy per minute. A good encryption key these days is around 256 bits. This was a fun project, and for anyone interested in dice or randomness you need only a little bit of experience with computers to pull it off, and a 3D printer helps a lot. I might build a better version of this machine without the ramp, and a better throwing mechanism.
More randomness or less bias?Since there is a hint of bias in my 1070 number row of dice rolls, I was wondering about if this could be approved. I have 2585 bits of entropy, but some bias. Using the Von Neumann extractor I can remove the bias, but need to pay with some entropy.
This strain of dice generated random numers: 4 2 4 1 2 6 5 5 4 6 5 1 2....
(4>2) = 1
(4>1) = 1
(2<6) = 0
(5 = 5) = discard
Von Neuman extracted values = 1 1 0....
By using this formula there is only 400 bits of entropy left. This is still enough for a AES-256 key.











Comments