What can be done to ensure that a lottery is fair?

Question

A recent series of newspaper articles in my local area details the schemes of a guy named Eddie Tipton who at one time headed the IT department for the Multi-State Lottery Association. He planted extra code in the lottery systems that made it possible to predict future drawings on certain dates, and he and some of his relatives scammed these lotteries out of several million dollars by being provided this inside information. Tipton has been convicted for these crimes. One article describes Tipton's methods; and another article quotes Tipton as saying that lotteries are still fatally flawed -- a claim vehemently denied by lottery officials, claiming they now have security processes that are "100 times better;" but given Tipton's "expertise," I am inclined to believe he knows what he's talking about.

So my question is: What can be done, in the way of coding and administering a lottery system's random-number generator(s), to provide a high level of reassurance that the system is fair and cannot be or have been invaded by scammers, either inside or outside of the lottery-administering organization? There are obvious things like maintaining physical security of the system, but I'm talking specifically about dealing with the fact that pseudo-random number algorithms are inherently deterministic, albeit chaotic. So we need to ensure that there is no way to rig it or to predict in any way the sequence that is generated. I have a few ideas of my own, but I'll hold on to them for a while.

I want to emphasize that I am asking about quality by design, not by inspection. No post-hoc testing will answer this. Once those numbers are generated, it's too late to ask questions about the integrity of the system. The system must already exist to ensure that the next numbers drawn can be trusted by all regulators and by the public as coming from a fair process.

Answer 1

For existing code rather than "Ad-Hoc" testing you can test against the design, ideally as black box testing - where the test authors do not know or see the code but rather test against the design.

Once you have your tests you run them, hopefully passing, with a code coverage tool in place and examine any the code that not executed during your testing. If it is simply corner cases covering possible but unlikely error cases you clarify your specification and extend your tests. But basically any code that still doesn't get executed needs to be examined to determine the effect of running it and the trigger(s) that will cause it to run.

For a new system the other practice which is used to try to ensure that such systems are tamper proof is to partition your design into two or more sections, with clear interfaces between the sections and give the development task to two, or more, separate groups or companies with no overlap between them. You also give the task of writing the tests, (both unit and system), to yet another group or company and then follow the approach above of ensuring that all of the code is executed (100% Code & Decision Coverage). Ideally you build heavy penalties into the contracts for things like staff overlap, etc. and for the presence of any unexplained code.

You could even, in your design, specify that one company produces a bucket of n sets of random numbers and that the other produce a number to select one of those sets. Specifying that the companies use differing programming languages & platforms could also help to ensure fairness of the process.

Answer 2

To avoid scams like Tipton's, good old code review should have detected it. I bet there was no code review for that two lines. Nobody audited his code. Even if he suggested such review should be made.

And convicted felons already should not work in such positions, so the person who hired him is partially responsible for neglecting due diligence too.

This is personal problem and competency problem and leadership problem, and it is not effective to pile layers of complicated technology to solve those.