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.

  • I am not sure this community is the proper place to ask such the question. – Alexey R. Mar 20 '18 at 9:29
  • 2
    I would suggest that if this community doesn't give a good result, we look to migrate to Software Engineering stack exchange. It's on topic here, but equally on topic there. – Kate Paulk Mar 20 '18 at 11:52
  • I view this as mostly a "quality" problem, so at first glance this seemed like the right place. But on second glance, I'm not so sure. Maybe the "engineering" aspect includes more of the right people? – Russ Lenth Mar 20 '18 at 13:33
  • 1
    In "Beatiful Testing" book there is a chapter on testing random numbers generators: johndcook.com/Beautiful_Testing_ch10.pdf. Similar questions are also asked in the Security/Crypthography area, e.g.: security.stackexchange.com/questions/83254/…, Of course those sources focus mainly on mathematical aspects, ignoring the human aspect of the process. – dzieciou Mar 21 '18 at 22:40
  • 1
    @dzieciou Yes, testing for randomness is extremely important. But that doesn't ensure the code isn't rigged in a way that is described in the posting and the linked articles, or that an appropriate system is in place to ensure the generator is seeded in an unpredictable way. Those are my chief questions. – Russ Lenth Mar 22 '18 at 0:20

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.

| improve this answer | |
  • 1
    Thanks for the thoughtful answer. I can see that such processes probably would have stopped Tipton’s scheme. I know from earlier coverage that he had been going around asking people about rootkits and such. If people had been paying attention they would have caught him much, much earlier. – Russ Lenth Mar 21 '18 at 21:47

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.

| improve this answer | |
  • I agree that the dysfunction of the organization was mind-boggling. But I’m still interested in the general question of what would comprise an adequate system for providing reasonable security for a lottery. I think more than just code review is needed. – Russ Lenth Mar 27 '18 at 0:48
  • @rvl Without technical competency from management, adding more layers of technology contraptions will NOT increase the security. Just the opposite, it will increase the attack surface. . – Peter M. - stands for Monica Mar 27 '18 at 2:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.