For those curious about the technical details of how he did it:
> Here’s how the Multi-State Lottery Association’s random-number generators were supposed to work: The computer takes a reading from a Geiger counter that measures radiation in the surrounding air, specifically the radioactive isotope Americium-241. The reading is expressed as a long number of code; that number gives the generator its true randomness. The random number is called the seed, and the seed is plugged into the algorithm, a pseudorandom number generator called the Mersenne Twister. At the end, the computer spits out the winning lottery numbers.
> Tipton’s extra lines of code first checked to see if the coming lottery drawing fulfilled Tipton’s narrow circumstances. It had to be on a Wednesday or a Saturday evening, and one of three dates in a nonleap year: the 147th day of the year (May 27), the 327th day (Nov. 23) or the 363rd day (Dec. 29). Investigators noticed those dates generally fell around holidays — Memorial Day, Thanksgiving and Christmas — when Tipton was often on vacation. If those criteria were satisfied, the random-number generator was diverted to a different track. Instead, the algorithm would use a predetermined seed number that restricted the pool of potential winning numbers to a much smaller, predictable set of numbers.
Now if he'd just taken that one level deeper, and had code to pick the Julian date of the rigged draws on days that _appeared_ random, but actually weren't ...
At NSA there's a "Peter Jenks Award" for people who do this sort of thing. Great story which started with LFSRs in the 60s.
You would want to cheat only the one time, and have your program copy the original program into place, change the timestamps, and delete itself.
More obvious is don't collect it with a person who is legally not allowed to collect it. This person should also not be seen buying the ticket on camera. I would probably have someone play the same numbers every week for months before it hits.
Here's what I'm wondering, and pardon me if this is a stupid question:
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?
Besides the point about a need to generate a large number of random numbers, there's another thing: you don't know the distribution of the true random generator exactly. You know it's random, but in addition to that, the distribution needs to be flat. That's why you use a PRNG with a known-to-be flat distribution to further process the entropy. As an interesting sidenote, though, Mersenne Twister doesn't have a particularly good distribution by modern standards. For this, I would use a cryptographically secure PRNG.
You can generally turn any random binary distribution into a uniform binary distribution by generating two bits, then if they're different, output the first bit, and if they're the same, ignore the result.
I'm guessing because the lottery system needed to generate a large number of random numbers (given that they are running lots of lottery systems), and this gives a fairly verifiable way of doing that from one initial chunk of randomness.
That said, I don't work in this area, so you should give my comment very little weight. :)
A geiger counter counts from 0-9 repeatedly and stops when a muon is detected. I guess you could count longer but I think the 10 digit modulus is sufficient.. not sure. This is the random initialization.
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.
He was the Security Director with privileged access to the production system. I don't think his changes went through code 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.
You can find people that will do a job but not really question what they're doing even if it should be questioned. Developers make spyware and do all kinds of terrible things as long as they get paid they just kind of do what is asked and not ask too many questions.
This sort of implies that the developers just aren't thinking deeply about what they're building. Certainly possible, but you're also much more likely to get garbage software this way. Isn't it as likely (or more so) that the developers just believe in what they're building?
Typically true random stuff like geiger counters do not have enough entropy in a single reading to be a true secret. They are statistically predictable and produce a curve of data.
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.
My understanding is that for this type of gaming, e.g. gambling, there are regulations governing the randomness and repeatability of the randomness for computer/electronic run games. Part of it due to necessities of verification of sufficient randomness from the perspective of the gamer but also that of the gaming establishment. The game needs to be provably sufficiently random to the advertised odds for fairness to both the gamer and the gaming establishment.
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.
The amount of entropy is usually limited. For the lottery, it doesn't seem like it would be a problem, but in general, you don't want your function calls to block while gathering "random data"
Am241 source coupled to a detector sounds sophisticated, but it matches description of now-outdated type of ceiling smoke detectors. It's probably not that mechanically elaborate.
> Here’s how the Multi-State Lottery Association’s random-number generators were supposed to work: The computer takes a reading from a Geiger counter that measures radiation in the surrounding air, specifically the radioactive isotope Americium-241. The reading is expressed as a long number of code; that number gives the generator its true randomness. The random number is called the seed, and the seed is plugged into the algorithm, a pseudorandom number generator called the Mersenne Twister. At the end, the computer spits out the winning lottery numbers.
> Tipton’s extra lines of code first checked to see if the coming lottery drawing fulfilled Tipton’s narrow circumstances. It had to be on a Wednesday or a Saturday evening, and one of three dates in a nonleap year: the 147th day of the year (May 27), the 327th day (Nov. 23) or the 363rd day (Dec. 29). Investigators noticed those dates generally fell around holidays — Memorial Day, Thanksgiving and Christmas — when Tipton was often on vacation. If those criteria were satisfied, the random-number generator was diverted to a different track. Instead, the algorithm would use a predetermined seed number that restricted the pool of potential winning numbers to a much smaller, predictable set of numbers.
https://www.nytimes.com/interactive/2018/05/03/magazine/mone...