Why go through all of the trouble generating true randomness with a Geiger counter just to use the result as the seed to a PRNG, rather than using your true random method to generate the lottery numbers directly?
Why go through all of the trouble generating true randomness with a Geiger counter just to use the result as the seed to a PRNG, rather than using your true random method to generate the lottery numbers directly?
Doesn't seem to work... It depends on odd bits and even bits having the same distribution, which in many cases they won't.
That said, I don't work in this area, so you should give my comment very little weight. :)
I'm curious at how you would actually successfully hide the control flow. The only think I can think of would be some factorization, maybe a couple of mods, but that would be detectable. You don't want to explicitly modify the control flow per se. I mean you'd have to be able to hide it from code review... and then mathematical review.
I'm struggling to differentiate what's established fact and what's the author's theory in this article[0], but it sounds like he could have used a root kit on a USB thumb drive to modify the code directly on the production machine.
[0] https://privacysecuritybrainiacs.com/privacy-professor-blog/...
By using it to seed a pseudo random number generator you are making the values come out in a completely flat distribution. The geiger counter adds non-deterministic results while the pseudo random number generator adds entropy.
For all intents and purposes, using a true source of randomness as the seed for something like a one-time use of Mersenne Twister as a pseudorandom number generator (PNG) is indistinguishable to an end user of true randomness. What it does do, though, is allow for reproducible testing to ensure you don't have an xkcd PNG [0].
Source: bar chat with a couple of friends & former coworkers who had spent time in that area of gaming (e.g. working on video poker machines destined for casinos), so take it with a grain of salt.