Author

Topic: Trustless Hardware Random Number Generator - A Proposal (Read 944 times)

legendary
Activity: 1176
Merit: 1020
Apparently radioactive decay is said to be the only truly random event. Someone else put together a system, but it looks sorely outdated. You should check out his design and see if you can leverage something there. If you could get his design into a USB stick, that would generate a lot of interest. There are lots of low radiation sources too that you could test with, as an example, bananas are radioactive (believe it or not).

https://www.fourmilab.ch/hotbits/hardware.html
https://www.fourmilab.ch/hotbits/secure_generate.html

I agree that radioactive decay is random, but am pretty sure that detecting an emitted photon or particle is a one-time thing.  I don't think it is possible to have two Geiger counters register the same event.  So you would have to trust the Geiger counter is working as described.  And would you trust a fourmilab device if I told you they were actually a front for the NSA?

There description of timing, that is exactly what I have mind.  The main difference is the design I propose allows for multiple observer systems.
legendary
Activity: 1512
Merit: 1057
SpacePirate.io
Apparently radioactive decay is said to be the only truly random event. Someone else put together a system, but it looks sorely outdated. You should check out his design and see if you can leverage something there. If you could get his design into a USB stick, that would generate a lot of interest. There are lots of low radiation sources too that you could test with, as an example, bananas are radioactive (believe it or not).

https://www.fourmilab.ch/hotbits/hardware.html
https://www.fourmilab.ch/hotbits/secure_generate.html

legendary
Activity: 1176
Merit: 1020
I could use some assistance with this project.

•Technical expertise with the timing system - I need a way create a timestamped record of the blinking led.  I have never used any kind of direct ADC feed before, so any advice would be helpful.  24 bit, 1 MHZ minimum.  But... I only need data sent to the computer when there is a change of state of the photodiode, and all that data needs to be is [ON or OFF] and [timestamp to 1 microsecond] .  Over USB would be great!


•Does anyone have ideas about a better place to post this and get feedback?


•Please give ideas about how to accomplish something as secure, but smaller and with a high data rate.  Better kbit/s to m³ ratio


•This will be proof of concept / development prototype.  Hopefully the design can be optimized so it can be a workable solution for people critical security needs.
legendary
Activity: 1176
Merit: 1020
A Proposal for a Trustless Hardware Random Number Generator

Overview

All of the hardware random number generators I am aware of, even the allegedly “crypto secure” ones, appear to rely on the integrity of their integrated circuits.  I don’t think it is reasonable to trust any particular integrated circuit for mission critical security.  With deterministic processes, it is easy to avoid trusting specific hardware by executing in parallel and checking the results against each other.  A simulation could be run on ten separate, air-gapped computers each using different operating systems, each having been made by different hardware manufactures and each running the simulation on different implementations of the same ‘protocol’.  All results should agree.  The chance of an attack affecting all ten systems, in such a way that they all give the exact same bogus result, is vanishingly small.

Traditional hardware random number generators, non-deterministic by design, cannot have their results audited in a similar way.  The user is left to trust that the hardware functions as advertised.

The kind of trustless HRGN (TL-HRGN) that I have in mind must somehow separate the source of entropy from the digitization process, such that there can be multiple computer-observers of the same physical event.  Ideally there could be as many isolated computers as the user wanted, each recording the same phenomenon – say dice rolls - and afterwards comparing results.  The results should match.  The user would still be responsible for making sure they had fair dice – a much easier task than making sure an I.C. doesn’t have a backdoor.  In addition, each of the separate computers could be running statistics on the dice-generated entropy to make sure it met tests for randomness.

***********************************************************************************

Design

I am currently working on a TL-HRNG design for which I intend to construct a working prototype.  Design goals are as follows:

Size:          Desktop computer tower-sized or smaller
Data Rate: At least 500 bits of entropy per second. 10kbits / sec would be better
Cost:         Under $2,000 - under $500 would be better

The randomness will be motion-based, using BBs or ball bearings that cascade down from the top of the device, sliding and rolling down an inclined backboard.  There will be some ramps to limit and roughly control the flow of the bearings.  There will be sensitive electrical switches placed in locations where bearings will frequently strike.  The switches will be designed such that when struck with a bearing, they will close only momentarily, hopefully something on the order of 0.1ms.

{Insert Picture of spring-switch}

A switch will be wired to a battery and light emitting diode. Every time a bearing strikes the switch surface, the connected LED will blink.  A photodiode, connected to a high-speed analog to digital converter, will look directly at the LED.  The quantity to be measured will be the time between blinks, hopefully to the millionth, or even ten-millionth, of a second.  The high precision is important.  The data will not be random, and therefore not useful, until at least several positions to the right of the decimal.  At the same time, the data can only be considered trustless if at least two independent computer systems can agree on their observations.  The closer the agreement - in terms of time measured - the more useful bits of entropy that can be harvested per event.

Since the two computer systems are isolated from each other, they will not have any kind of clock synchronization.  Perhaps to within a second or two, as that could be accomplished by manually setting date and time, but that is not going to help with the required micro-second precision.  The idea is each computer will have a list of time-stamped events.  While the time-stamps themselves will not match, the elapsed time between events should be the same, at least to some level of precision.

This should be possible to accomplish with any number of isolated computer systems. The only thing the computers have common is they are all staring – via separate photodiodes – at the same blinking LED.  The LED blinks when cascading ball bearings strike a switch surface.  A trustless hardware random number generator.

**********************************************************************************

I was inspired by the Dice-O-Matic (http://gamesbyemail.com/news/diceomatic).  It is an automated dice rolling system.  The dice are rolled by tumbling down a curved chute.  At the bottom they settle into an elevator system for ride back to the top of the chute.  As the dice ride the elevator, a camera snaps their picture, and the dice markings are analyzed with software.  While the ingenious creator doesn’t indicated having multiple cameras and computers to corroborate each other’s record, they would be trivial to add.
Jump to: