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.”

e-sushi
  • 17,891
  • 12
  • 83
  • 229
  • 5
    Wow. There's a pretty impressive amount of misconception shown here. All I can say is: You are not qualified to write a casino game. Don't do it. There is specific technical knowledge required to do this right, and you do not have it. Try to find someone more qualified to do this aspect of design, because your instincts are leading you astray, your reasoning is wrong, your conclusion is wrong (and worse, you seem convinced that you are right). – D.W. Dec 19 '13 at 00:47
  • Thanks for the answer, I admit if I am wrong, but please write me where the mistakes are, to make me less incompetent. –  Dec 19 '13 at 05:13
  • 1
    Greg, the first step is to start by asking questions rather than drawing conclusions (such as the conclusion that Mersenne Twister is fine). You should be especially careful when your conclusions seem to run counter to what others have told you. Asking questions shows that you want to learn. Here's a starting tip: Mersenne Twister is insecure from a cryptographic perspective, and the fact that you only output partial output does not change that. You need cryptographic-level security, and the best way to get that is a CSPRNG -- which Mersenne Twister is not. – D.W. Dec 19 '13 at 06:50
  • I asked a question, there was no conclusion first, the conclusion was an answer what I wrote later, that was added automatically to my question under Edit. "You should be especially careful..." You are right, and I was very careful, because I don't think I am more clever then these guys. So I was thinking about it a lot and I checked other peoples opinion: http://stackoverflow.com/questions/426821/what-type-of-random-number-generator-is-used-in-the-gaming-industry –  Dec 19 '13 at 07:43
  • "Mersenne Twister is insecure from a cryptographic perspective, and the fact that you only output partial output does not change that." I think I explained earlier why it is much harder to get the state if you have results on limited range and if we discard some random numbers, but if you don't believe me, maybe you believe the guy at stackoverflow. (Link at previous comment.) –  Dec 19 '13 at 07:51
  • Let me ask you one question: If you are not able to see every second random numbers coming out of the algorithm, how can you calculate the states of MT??? It uses states with these indexes to generate the next state: i, i+1, i+397. If you have no information about the states (i+1) and (i+397) how can you find out what (i+624) will be??? –  Dec 19 '13 at 09:18
  • @Greg: I've edited the title of your question to take into account that the question has moved over slightly. There should be sufficiently many answers given below stating you need a CSPRNG, meaning that as I see it you're asking if your modifications turn a MT into a CSPRNG – Cryptographeur Dec 19 '13 at 14:34
  • 7
    Why do you want to use a MT when there are plenty of strong and fast standard CSPRNGs? AES-CTR can output gigabytes of data per second on a modern CPU. What can be simpler than calling a function "Give me n cryptographically secure bytes*? – CodesInChaos Dec 19 '13 at 15:00
  • 9
    You're a beginner who has no experience in cipher design and cryptoanalysis. You're inventing your own stream cipher which has seen no cryptoanalysis and hope that it's secure. Why do you think that's a good idea? – CodesInChaos Dec 19 '13 at 15:04
  • 2
    @Greg, you say "If you have no information about the states (i+1) and (i+397) how can you find out what (i+624) will be?". If you know MT[i], you do have information about (i+1) and (i+397): it's 'embedded' in MT[i], because MT[i] is a function of MT[i+1] and MT[i+397]. – pauluss86 Dec 19 '13 at 16:10
  • pauluss86, The new MT[i] is a function of the old MT[i], old MT[i+1] and old MT[i+397]. What you are saying is that you have information about the old state, it's true but that information is not enough for getting even one state number. What I say and even bigger problem for you if you want to crack: if you know the old MT[i], but you don't know the old MT[i+1] and old MT[i+397], you can't find out the new MT[i]. –  Dec 19 '13 at 19:01
  • @CodesInChaos, "What can be simpler than calling a function Give me n cryptographically secure bytes?" Hiding every second output is not so difficult, and still efficient. "Why do you think that's a good idea?" I explained it already, see previous comments. Maybe I'm a beginner, but it doesn't mean I can't be right, hope you agree. Everybody can say somebody is wrong, it's easy. Please try to give an explanation like pauluss86 tried it. –  Dec 19 '13 at 19:34
  • @Greg, it may be sufficient to reduce the search space by exploiting what you do know about the state. I had a thought: reseeding at fixed intervals (e.g. daily) may reduce security. The current and future state is ultimately determined by the seed. Assuming a 32-bit seed, I think the following is a practical attack: (1) collect a sequence of N rolls, (2) try all 2**32 possible seeds and maintain a list of best matches, by comparing the N observed values against X generated numbers. This can be done in parallel. Reseeding limits the search space (X) because it resets the state. – pauluss86 Dec 20 '13 at 11:29
  • Yes, we can Brute-force the seed(although it works only if there is just one player. More players call the rand() function more times and randomly.) Let's say we have just one player, and he wants to crack the RNG. We can have many ideas how to protect ourself. Here is one: I said before we hide every second generated numbers. We can do now that sometimes we hide the second number, sometimes we don't hide it, randomly. Or we hide two numbers. (Doesn't make the app slower, we can generate the numbers what we want to hide while the wheel is spinning.) So the attacker can't compare X with N. –  Dec 20 '13 at 16:54
  • @Greg, The observed numbers don't have to be a contiguous sequence for it to work. Even if an attacker would never be able to reduce the number of 'candidates' to one, he or she may have an edge because the Roulette wheel is no longer uniform from the attacker's perspective. Also, what would you use to generate the random numbers to randomly drop numbers from the MT? – pauluss86 Dec 21 '13 at 12:57
  • 8
    It's regrettable that the question as-is seems to imply that it's OK to do whatever the OP suggested. A shame for future visitors who may not have the insight of actually checking the rest of the thread, and end up using a homebrewed, brittle, and perhaps profoundly insecure PRNG as though it were a CSPRNG. I also like that you dismiss the entire field of cryptanalysis as if you were too good for it and just assume all your arguments are correct. Seriously, it's cool to be creative for experiments, but for a real project, no less an ONLINE CASINO GAME, you WANT to use best practices. NOT THIS. – Thomas Dec 22 '13 at 13:52
  • 2
    But again, if you think you know everything and are always right, go right ahead, no one can stop you. If you implement this, and your game becomes popular, and eventually someone discovers this, exploits it, and steals a bunch of money, you're going to have a hell of a time defending why you deviated from industry standards, tried to do better than everyone else, and lost. In fact this thread may even serve as evidence. And, yes, this does happen, very often. Good luck with your project. – Thomas Dec 22 '13 at 13:59
  • @pauluss86, an example: seed := 1000000; N := {3, 12, 6, 30}; You have the N observed numbers, and your Brute-force algorithm checks the seed = 1000000, you get an X generated numbers vector (X: = {2, 3, 13, 12, 6, 25, 31, 18, 30, 9, 21};), but you don't recognise this is the seed what you are looking for, because you don't know which indexes you should check to compare X with N. "what ..to use to generate the random numbers" Even an unsecure RNG is good for this, doesn't even have to give uniformly distributed values, we can limit the range to [1, 3] with a secret and simple algorithm. –  Dec 22 '13 at 15:05
  • 2
    "with a secret and simple algorithm" - And here we have the crux of the issue: 'securing' your scheme with a secret sampling method is fine until someone finds out what your sampling scheme is. Good crypto should be proven secure and obey Kerckhoffs principle. "Not known to be Insecure" $\neq$ "Secure" – Cryptographeur Dec 22 '13 at 16:30
  • @Thomas, I added a second Edit to my Question. I disagree with you. I don't think a professional makes serious decisions by reading a question on this forum. And I don't think anybody can steal a bunch of money who discovers these comments. Please read my Edit 2. Take care! –  Dec 22 '13 at 16:33
  • @figlesquidge, you are right. I will be busy in the near future, but in some months I will share a cryptographic proof of my statement on this forum if I can prove it. If I can't prove, I will admit it here. Is this alright? –  Dec 22 '13 at 16:49
  • 6
    Please note that Stack Exchange sites are not discussion sites, but Question-and-answer sites. Repeatedly editing a question to ask different things in reaction to answers it not really useful – better create a new follow-up question (which still should be able to stand on its own). – Paŭlo Ebermann Dec 22 '13 at 17:23
  • @Paŭlo Ebermann, I added an edit only once! First figlesquidge edited it, later somebody else. (I edited one more time because of a grammar mistake, not in reaction to answers!) Thanks for downgrading my question because of this. –  Dec 22 '13 at 17:28
  • 1
    @Greg "…On this forum we have a long argument…" I think I get it now. Maybe it isn't obvious, but this is a question-and-answer site, not a forum… meaning: things work a bit different around here. – e-sushi Dec 22 '13 at 22:59
  • you know I am not a native English speaker and I call it forum unfortunately. Although I know what it is. ;) People who have right to edit my question edited it, later other people who have the right to edit punished me because my question was edited many times. and now you want me to feel it's my fault, haha –  Dec 22 '13 at 23:41
  • 1
    You are so wrong, it's hard to know where to begin. The only CSPRNG native designed with Mersenne uses CryptMT v3, a patented algorithm partly by original authors. Array seeding only allows initial internal state to be fully specified with an external algorithm, potentially reducing internal weak initial states. Scaling or transforming randoms onto a smaller space is a simple operation trivially reverse engineered or guessed. Hashing the RNG output is a hack, but be sure your hash is truly cryptographically secure or you will be in a world of hurt. You are fighting Beowulf clusters. – ingyhere Apr 19 '14 at 15:51
  • 1
    This entire discussion should be deleted, as it serves no purpose and has no value to future readers. Even worse, if reading the question alone, non-cryptographers might be inclined to follow the question's wrong reasoning. – tylo May 23 '14 at 12:05
  • 3
    This does not seem to be a real question, but rather an attempt to argue a point or to discuss the merits of a novel cryptographic primitive. As such, it is off-topic for Cryptography Stack Exchange, as described in our [help/dont-ask]. – Ilmari Karonen May 24 '14 at 17:34
  • @pauluss86 was the best answer. "consecutiveness" is not what an attacker needs. by hiding information from the attacker, or hashing, you are correct that you make it harder for the attacker to guess what you're doing. but suppose the algorithm leaks out. if your seed/state is secure... everyone should be able to know what you are doing... and it should still require a brute force attack to guess. so anything you do to obfuscate your algo is not really useful. (unless, of course, you consider that part of your seed.... which is where the thought experiment gets fun) – Erik Aronesty Apr 25 '17 at 17:25

4 Answers4

22

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.

e-sushi
  • 17,891
  • 12
  • 83
  • 229
Simon Johnson
  • 3,216
  • 16
  • 20
  • 1
    For $s$-bit security, the output of an $n$-bit cipher in counter mode should be less than about $2^{(n-s)/2}$ blocks. If we set $s=80$, that makes "AES in counter-mode" good for a mere $16$ million blocks. – fgrieu Dec 18 '13 at 16:53
  • 3
    @fgrieu: you might want to rethink that statement, it sounds much stronger than what I think you really meant. You appear to be worried about repeated output blocks (or the lack of them with CTR mode); With 16 million blocks, a truly random source has a probability circa $2^{-80}$ of having a collision somewhere; AES-CTR has 0 probability. While a distinguisher with advantage $2^{-80}$ may violate semantic security, I can't think of a practical security issue with it. – poncho Dec 19 '13 at 17:12
  • @poncho: right, the output of AES-CTR is fine for most practical purposes, even though the distinguisher that I consider (no repeated output blocks) makes it technically not a CSPRNG. However, for certification purposes (of security devices, or one-armed bandits), who knows what kind of (admittedly pointless) red ink could be raised by not using a CSPRNG, where one is prescribed? And for data encryption, the ability for an eavesdropper to distinguish constant plaintext from changing plaintext (which could translate to: idle link from active link) is close to a practical attack. – fgrieu Dec 19 '13 at 18:03
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
e-sushi
  • 17,891
  • 12
  • 83
  • 229
  • "MT is predictable as soon as someone observes only a tiny part of the period." It's true only if the range is not limited. "Also, an attacker does not need 624 consecutive states to break the Mersenne Twister" It's also true only if the range is not limited. –  Dec 18 '13 at 21:36
  • 2
    @Greg To be honest, I do not understand why you are willing to take any risk if there are ample secure and fast solutions available. Online poker wasn't the only casino field that failed by simply using the wrong kind of RNGs… regular RNGs instead of a CSRNGs. – e-sushi Dec 18 '13 at 21:42
  • Your answer is correct that I could use CSRNGs, but I'm more confident with regular RNGs, I know how fast or slow they are and I can use them more efficiently. So if I can do with MT, I will do with that, it's simpler for me. If it's more suitable for someone else to use CSRNGs, then they can use that. It's also interesting that Mersenne twister is the number-one recommended RNG for gambling at a reputable company: http://www.itechlabs.com.au/pages/rngtesting.html I appreciate your answers. –  Dec 18 '13 at 22:06
  • 1
    @Greg Well, when it comes to finding “recommended” RNGs , I tend to look at NIST and FIPS 140-2 style testing… just like most gaming companies (for example: PokerStars RNG certification). Btw: the link you provided merely shows “a non-exclusive list” of “well known public domain RNG algorithms”. It is neither a top-6 list, nor does it state any algorithm being better or more preferred than the other ones that are listed, and there are no specific security statements related to the listed RNGs either… (guess why) – e-sushi Dec 18 '13 at 22:27
  • I like this argument:). I'm flexible, if my statement is wrong, I will admit it, but please give a mathematical explanation. "and there are no specific security statements related to the listed RNGs either… (guess why)" guess: because you can modify the RNG to make it more or less secure, hahh:) Like I modified it by dropping every second random numbers to make it more secure. –  Dec 18 '13 at 22:45
  • For your Addendum: I will do it in Java, with my own implementation of Mersenne-twister, I can do any seeding algorithm what I want. To make the seed larger we can concatenate more seeds. But it doesn't even important, I'll write soon an answer to pauluss86's comment, I'll try to give an explanation why you can't find out the seed by using Brute-force. Thank you for this addendum. –  Dec 22 '13 at 10:15
  • For your Addendum 2: You can seed MT with an array of seeds, and it will be CRYPTOGRAPHICALLY SECURE. How do I know? Matsumoto (creator of MT) wrote on his website: http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/efaq.html He has an other solution too, hashing the outcoming integers, it's similar to my version. (If mine is completely correct, faster then using hashing algorithm, but reduces the period, although in this case it's not a problem, because we hide many result, much harder to find a pattern.) –  Dec 22 '13 at 10:51
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
  • You can see people just say "you are wrong because MT is not secure", without thinking about the algorithm. I really liked your previous comment about the states of MT, because you tried to prove I am wrong and you didn't just say "Use CSPRNG". "there's no reason to not use a better alternative." true. I don't say anyone should use a modified MT instead of CSPRNG. I am just curious it can work or not. I am that kind of person who likes trying ideas and thinking about it, not just using things what other people created earlier. –  Dec 19 '13 at 20:06
  • 1
    @Greg "...not just using things what other people created earlier." You know that the Mersenne Twister was created by "other people" too, don't you? ;p (Only teasing!) – Trina Dec 20 '13 at 23:35
  • OMG, did you read what we wrote earlier??? it's not about Mersenne twister, it's about the modification of Mersenne twister. (if it's a joke, it's a bad one) –  Dec 21 '13 at 10:45
  • @Greg Unless I missed something, you didn't ask about the modification of the Mersenne Twister — you asked when to re-seed the MT and if it's secure to truncate it's output. That indeed has nothing to do with a modification of Mersenne Twister itself. I can only guess that's what she was pointing at with that obviously joking comment. But hey, please don't get angry at me now — it's not my comment; I'm only trying to help. – e-sushi Dec 22 '13 at 09:01
  • @Greg Btw.: I've just added an Addendum to my answer (which specifically considers the fact that you want to use the Mersenne Twister) giving a little heads-up on MT's seeding. Hope it helps. – e-sushi Dec 22 '13 at 09:31
  • I'm not angry. :) You missed something: truncation is a modification and discarding every second number is a modification, this is how I mean, but I think it's obvious if you read the comments. You know, the problem is when people come here, they don't read every answers and don't know about the algorithm of MT but they rate without having enough information and misleading people who will read it later. There was only one person who knows how M-twister works, the others have no idea (or just can't tell why I am wrong or right), but they rate and leave unfunny jokes. –  Dec 22 '13 at 09:52
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