whispering

Absolutely 100% no advantage whatsoever.

Absolutely 100% more fun.

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.

Me neither, and I'm the author. But whatever.

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

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 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

Fair point.

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.

Definitely a slow method! It outputs about 1 byte every second. Not great performance! This 22KB sample took several hours to collect: https://github.com/valerionew/Banana-Random-Number-Generator...

Didn't we agree on the fact that if an attacker gains physical access the security is already compromised?

Otherwise you could just inject whatever you want from the uart, no need for any x-ray gun.

KCl is definitely detectable. And the same goes for KOH. And it significantly increases the throughput.

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.

[0]: https://www.valerionappi.it/chi-squared/

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

Nice! Are you the author?

Looks very similar to mine in the principles of operation! I wonder if the author got some inspiration from my work, that would be amazing!

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.

Btw here is a sample of the data gathered, if you want to further analyze it. It's plain binary: https://github.com/valerionew/Banana-Random-Number-Generator...

Author here!

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.