In the process of doing some research, I stumbled across the following two claims on the PokerStars website.
We do record all of the hole cards in all real money hands. This is an important tool to help us investigate fraud and collusion. However, this information is not accessible to anyone until after the conclusion of the hand; it is not transmitted to our database until all action is completed and the pot has been awarded.
To be clear: Nobody in the public or employed by us can obtain information from the servers to find out the hole cards of any hand in progress. Nobody in senior management, none of the software developers, no operational representatives. Nobody at all.
This got me thinking, how would you go about writing such an algorithm?
Let's start with the following requirement:
"Generate a collection of 52 random numbers representing a deck of cards in such a way that no malicious third party could determine which cards were generated--even if they had direct access to the memory of the computer generating the sequence. This sequence of encrypted numbers must be reversible, but not until the completion of the game."
My first attempt at designing a solution to this problem went along these lines:
- A new hand begins.
- Each client in the system generates a new public/private key pair.
- Each client in the system makes a request for a tuple of new hole cards. With this request the client sends its public key.
- The server receives the request for new hole cards and uses the public key provided by the client to encrypt the random numbers generated and return them to the client.
- At the end of the hand the client sends the private key back to the server and the server can now decrypt the hand information.
Unfortunately, such a implementation doesn't address all the requirements (it would work, more or less, if you didn't need to generate unique numbers) and has several flaws, chief among them:
- If the client disconnects prior to the completion of the hand the server can no longer decrypt the value that was sent to the client, given that it doesn't have the private key.
- The requirement that a deck of cards must not contain duplicate values ensures that somewhere in memory, at some point in time you must store a collection representing the cards which have already been dealt. This completely negates the original purpose of this algorithm as this information can now be potentially read by a malicious third party who has access to the device.
If you're going to be able to log the information you need to log in the event of someone disconnecting before the end of a hand, it seems like you're going to have to be able to reconstruct that information server side. (Is this so?) And if sufficient information is stored server side to reconstruct the data you're trying to keep hidden before the end of a hand, then anyone with access to the server should be able to do it before the end of a hand as well-- it seems like the ability to compensate for a disconnect, and the ability to read hidden information before a hand ends, go...hand-in-hand...
Can anyone suggest a potential implementation of such an algorithm or definitively prove that such an algorithm is not possible?