Random numbers
This week I have implemented a new feature in OCTGN 2.0: random number generation. This is a very much required feature, since it is the fundation of many useful actions like:
- Rolling a die
- Flipping a coin
- Randomly discarding a card
- and the list goes on…
Just like every other feature, special care has been taken to keep cheaters out of OCTGN. This means that even if you take the source code and modify your client it would still be impossible for you to:
- influence the result of a random number generation. E.g., trying to roll a high number (6).
- predict what the next random number will be. E.g., guessing if you should call head or tails.
Those are two different aspect of cheating and neither of them is achievable in OCTGN 2.0, at the very least not without your opponent noticing.
Have a nice week,
jods
OCTGN.net development 
November 11, 2007 at 8:34 pm
Nice!
I find it very good, that you implemented a way to restrict cheating!
Don’t let us wait to long, to try the new OCTGN client. (;
Impressed by your work,
Koryu
November 13, 2007 at 5:57 pm
out of curiosity how did you do this? just a basic overview, or even a reference to where you learned how to do this would be nice. (i am a programmer so dont worry about dumbing things down)
November 14, 2007 at 10:36 pm
Keep up the good work man!! I started on OCTGN a few months back and cant wait to see what you do with 2.0 🙂
November 17, 2007 at 11:39 pm
@kbi:
I assume “this” means “the cheating-proof part”. Because it would be boring to go into all the nitty-gritty details I am just exposing the fundamental idea. Actual implementation is slightly different.
Let’s say we have two players: A and B. A wants to pick a random number. The protocol works like that:
– A randomly chooses a number, let’s call it Ra.
– B does the same, let’s call this one Rb.
How Ra and Rb are chosen really doesn’t matter. You can try to cheat if you want to 😉
Let’s consider k() a one-way function. A one-way function is a function which is very easy to compute but whose inverse is extremely hard to compute. It’s a very useful cryptographic tool because it means that computing y = k(x) is easy but you can’t find x from y and k().
– Now A sends k(Ra) to B.
– B sends k(Rb) to A.
This step is important. When A receives k(Rb) he can be sure that B has chosen his number but A still doesn’t know what the actual number is. At this point the final random number is decided, but neither A nor B actually know what it is.
– After receiving k(Rb), A can send his value Ra in clear to B.
– B does the same.
– Now both A and B know Ra and Rb.
– Each one can check that the received k(Ra) – resp. k(Rb) – match the received Ra – resp. Rb – by computing it themselves. If the numbers don’t match, it means that the other player has changed his mind after receiving the second number, which means he’s trying to cheat.
– If everything is ok, the chosen number is defined as Ra XOR Rb.
I am over-simplifying the process, there are many issues I have not even mentionned. But you get the idea.
November 18, 2007 at 2:11 am
random generation is good, as it would be the core for TRUE shuffling.
November 18, 2007 at 5:56 pm
@roblethal:
the random numbers described in this post aren’t actually used for shuffling. Because:
1. It would be a very inefficient protocol
2. There’s more than the position to protect against cheaters during a shuffle. Card identity should be hidden, which is done with a more complex algorithm.
As for what TRUE shuffling really means, that’s a very sloppy discussion which I won’t get into right now 😉