Well that's interesting. Thanks for responding to my post. If you agree with me, why did you name uniform distribution as requirement number 1? Is that just part of the "official" academic definition or something?
I am not able to motivate further, it's just that usually when we talk about random numbers we mean uniformly distributed random numbers. It is not a requirement in a strict sense. It's just the easier way to tell about randomness. We all have an intuitive understanding of rolling a dice or flipping a coin.
Wouldn't it be possible to build large detectors of reasonable cost and power consumption? For example, instead of a small tube like in the article, flat metal plates or arrays of long wires in a thin rectangular chamber.
The throughput is given by the frequency of the radioactive events. This can easily made bigger with a more radioactive source. The limit in this is how fast is the underlying reference timer. If you could have a fast enough timer, you could raise the radioactivity of the source and get a bigger throughput.
I wouldn't be comfortable putting the kind of strong radiation source that can increase events by some orders of magnitude close to me or my computers. Large detectors or multiple detectors to catch more natural radiation are safer.
Yep but the main point that i was trying to make is that to get a faster generator you need a faster clock and a bigger timer, not a bigger detector nor more events, if you cannot back them up with the faster clock and bigger timer
However I don't think you'd be able to easily manipulate the random stream.
By triggering the random tube you just generate a random number, but even by triggering it continuously you cannot directly manipulate the bytes. The counter is not reset after every event.
Moreover: the timer/counter is clocked at 20M, for a 16 bit timer it overflows every 3ms. The tube is inhibited for a similar amount of time by a monostable 555. And this inhibit time is controlled by an RC network that is separated from the timer/counter crystal. So even noise and fluctuation on this two clock sources generate some randomness.
I'm not saying that it is impossible to manipulate, I'm saying congrats if you figure out a way.
A Geiger-Müller tube has a dead-time after a detection event where it won't register a new event. Thus it's possible to saturate the tube. This would drastically reduce the entropy it generates, from what I can gather.
I should try and see. The inhibit from the monostable timer could somewhat "transfer" the randomness source from the geiger to the time constant of the 555
Author here. There is a part 2 that explains the generation in detail, you find it linked below the part 1, or at the link [0].
The banana does not make a significant difference (the generator can operate without it), however the potassium in general can definitely be detected. I've made some test with KCl and the increase in counts is huge. In the end this is not very important for the purpose of the project: i just wanted to tell a story involving true random number generation from radioactivity, and the radioactive banana is very functional for this purpose.
It's pretty similar to mine, you could improve yours by relying on an hardware timer/counter that can go faster and thus provide more entropy.
Also you should not reset the counter at every event, this would lead to a poisson distribution if event ever became of comparable time scale to the timer
No he's a friend of mine, I also have my nuclear RNG based on different vintage counter. I think his project is older. I like your project too! This is him:
https://news.ycombinator.com/item?id=30252171
The numbers are generated directly from the current timer/counter value at the moment of the event. I'm not at all measuring time BETWEEN events. It's just a counter that overflows ~300 times per second (20MHz clock in a 16 bit counter), while the radioactive events happen every ~1-3 seconds. This ensures that the numbers are uniformly distributed and uncorrelated.
I am actually throwing away some enthropy bits doing this, as there will be significant bits to the left that i'm discarding. A somewhat next step in the future could be the assesment of how many bits can the counter be, without impacting the quality of the output. Maybe i can get something like 20 bits per event.
IANA cryptographer. But it seems like this results in readings not being truly independent.
Also I feel like there might be some element of nonuniformity, akin to generating a number out of n possible values, and modding it by k, where n is not divisible by k. n and k being the timer period and event in this analogy.
That would be the case if i was resetting the counter at every read. Instead, it does not reset the counter, so it does not always start from 0. So the analogy would hold only for the very first number.
Absolutely 100% more fun.