3

I want to create an online roulette game. Is it OK if the PRNG is seeded only once, when the user starts the game, or is it recommended to re-seed sometimes during game? Maybe just seeded once a day on the server and every players would get a next random number without re-seeding? How would you do? How do they do it at online casinos?

Please note that the following edit does not contain any relevant information regarding the original question. It is maintained because the given answers have been updated to reflect the additional information contained herein. Most - if not all - of the answers do not agree on the security of using the Mersenne Twister for generating secure random numbers.

EDIT (in response to comments & answers)

Everybody says I should use a CSRNG.I understand why MT is not cryptographically secure.
But guys, maybe you forget that we reduce the range, you forget that for a roulette I need numbers from 0 to 36 only.

MT can generate $2^{32}$ different numbers. Sharing these possible numbers between the roulette numbers uniformly, we can have $(2^{32})/37$ different numbers for each roulette number. To each number belongs one state number. MT for generating the next number, uses the numbers with these indexes: $i$, $i+1$ and $i+397$. That means we have $(2^{32})/37 * (2^{32})/37 * (2^{32})/37$ possibilities to generate the next state. If you want to crack my RNG knowing that it's not C-secure, you have a super-fast computer, and it takes only 1 second to calculate $(2^{32})/37$ possibilities, then the whole thing will still take for a very very long period of time, and you will get a huge amount of possible values for the next state.

Given a small amount of output, it is relatively straightforward to compute all future outputs.

It's simply not true, because you have to calculate all 624 states if you want to be able to predict all future states, and you can see only the results from 0 to 36. (I don't want to explain it now, but actually we need even more (much more) then 624 states to get only one number for one state, if we have a reduced range.) But let's say you want to crack the RNG and you ask your friends to calculate different parts of the states , and you together can finish it quite quickly, then I have a trick: when you spin the wheel of the roulette, I generate two numbers, I use one for the roulette, and I discard the other one. The RNG is still uniformly distributed, and you can never have the state with the index i+1 (because I discarded it), and it becomes impossible for you to find out the state of the MT. (Generating the second random number can happen while the wheel is spinning, so we don't lose much time.) If I am right and it works, it can solve the seeding problem too. Does this argument hold?

EDIT 2 (after getting new comments)

Reason of editing: The comments and the highest rated answer on this site make the visitor think that Mersenne twister can't be modified to get secure output.

Cryptographically secure modification of Mersenne twister from Mr. Matsumoto's website – he is one of the two creaters of Mersenne twister. Check the C codes on this site, the modification is that you can seed the algorithm with an array of seeds.

An other solution to make Mersenne twister cryptographically secure (written by Mr. Matsumoto):

To make it secure, you need to use some Secure Hashing Algorithm with MT. For example, you may gather every eight words of outputs, and compress them into one word (thus the length of the output sequence is 1/8 of the original one).

On this forum we have a long argument about my statement: if we hide many results of Mersenne twister randomly and the range of outcoming integers is limited, then these modifications make MT cryptographically secure. If my statement is correct, you don't need an array of seeds and this method can be more efficient then using hashing algorithms.

Warning: I didn't do cryptoanalysis, I just tried to prove that it's secure by arguing about it as you can learn from comments below. Do not use this method if you are not sure it will work. Nonetheless, the following statement is correct from my point of view: “Mersenne-twister can be used for a roulette game if you modified it properly. (Although we recommend to use a CSPRNG.) Can be seeded daily by a good quality seed.”

Mike Edward Moras
  • 18,161
  • 12
  • 87
  • 240

4 Answers4

23

You don't want to use something like the Mersenne Twister for gambling. It is not cryptographically secure.

Given a small amount of output, it is relatively straightforward to compute all future outputs. These algorithms are designed for things like Monte-Carlo simulations and things of that ilk.

A better option is to select a 128-bit key at random and run AES in counter-mode. Another option is simply to pipe input from /dev/urandom.

Either of these will give you a secure stream of bits you can use for your gaming application.

Mike Edward Moras
  • 18,161
  • 12
  • 87
  • 240
Simon Johnson
  • 3,236
  • 17
  • 21
8

Quoting Poncho's answer:

Well, the chief vulnerability is that if an attacker is given a large enough sample of Mersenne Twister output, he can then predict future (and past) outputs. This is a gross violation of the properties that a cryptographically secure random number generator is supposed to have (where you're supposed to not even be able to tell if the random bit string could have been produced by the RNG in question).

In other words: you should not use something like the Mersenne Twister for your project.

For a RealLife™ example of what can go wrong if you do, you might want to read the article "How We Learned to Cheat at Online Poker: A Study in Software Security" (September 28, 1999) by Brad Arkin, Frank Hill, Scott Marks, Matt Schmid, Thomas John Walls, and Gary McGraw Reliable Software Technologies Software Security Group.

What you need is a cryptographically secure random number generator. There are a multitude of those available, so there is practically no reason for you to use anything else for your “casino” purposes. Implementing a secure and fair system is not overly difficult… and your players will demand it.

EDIT as a reply to your edit

You are missing the point. MT is predictable as soon as someone observes only a tiny part of the period. After that, reconstructing the whole period merely takes a blink of an eye. Check my related question which talks about the MWC — which has a has near-record period… more than 1033000 times as long as that of the Mersenne Twister. Yet, also MWC would fail to provide the RNG security needed for your project. The main point you need is "unpredictability" & non-CSRNGs do not provide that.

Also, an attacker does not need 624 consecutive states to break the Mersenne Twister… so dropping numbers won't save you. (Also note that the provided link is showing merely one of many ways to reconstruct the period).

Addendum

Since you seem to be fixed on your decision to use nothing but the Mersenne Twister, I thought it might be interesting for you to know some pitfalls related to it's seeding.

Python seeds the Twister with 256 bits (32 bytes) of “real” randomness (read from /dev/urandom if available). This means that, theoretically, it would be enough to know a few output bytes to restore the whole state, but an attacker would need an efficient attack on the seeding algorithm since 32 bytes is pretty much for a brute-force attack.

Other implementations however use much less randomness to seed their random number generators! PHP for example seems to use only 32 bits for seeding mt_random as it's mt_srand seeding function only accepts an int. In this case an attacker might find it easier to use a brute-force attack on the seed.

As you did not specify the programming language you are planning to use, I can only give you a general warning that — depending on the programming language and implementation — you'll probably want to reseed more frequently than just once a day, to minimize the chances of successful brute-force attacks.

Community
  • 1
Mike Edward Moras
  • 18,161
  • 12
  • 87
  • 240
4

I'd rather add this as a comment. Alas, I lack the reputation for that.

I'm a programmer, not a cryptography expert, but for some strange reason I like to lurk here regardless. The cryptography aspect aside (others are much better at that) I'd like to focus on the programming perspective, and why your reasoning is wrong.

  • First of all: lurking here taught me that it's exceedingly easy to create something that appears secure at first sight but is fundamentally flawed. Don't be clever, it'll probably turn out to be the opposite. You're playing Roulette with your system's security..
  • You state that you prefer MT because 'it's simpler for me'. Note that you don't need to be a mechanic to drive a car. If you take any crypto library (as Erwan points out) you'll be generating pseudo-random numbers with a few lines of code. That's simple in my book.
  • Regardless of whether dropping every other number is secure (which I highly doubt because elements in the state array are not independent) you've also halved the effective performance of MT. Thus, the 'performance benefit argument' becomes much weaker and you may as well switch to a CS algorithm.
  • In addition to the previous point: I highly doubt that a CSPRNG would be a bottleneck in the system.

To conclude: regardless of why you think it would be a good idea to use MT, there's no reason to not use a better alternative. If you are absolutely sure that your reasoning is correct, post a proof and put on a helmet.

pauluss86
  • 283
  • 1
  • 6
3

You need a CSPRNG. And yes, a good CSPRNG should mix some new random data in the pool (reseed) periodically.

Here are a few options:

  • SecureRandom in Java
  • RNGCryptoServiceProvider in .Net
  • openssl_random_pseudo_bytes() or mcrypt_create_iv() in PHP
  • RAND_bytes() from OpenSSL
  • /dev/urandom on some Unix-like systems
Erwan Legrand
  • 239
  • 1
  • 7