-
Notifications
You must be signed in to change notification settings - Fork 13
CypherPoker: The Peer to Peer Poker Protocol
This section describes the Peer to Peer Poker Protocol, P2P3, which uses the operations described in the "Core Cryptographic Operations" section. Other commutative cryptosystems may be suitable but are not currently implemented. P2P3 is designed primarily for peer to peer community card poker game exchanges in which card recycling is not required.
CB length or CBL – The Cryptographic Byte Length of the parameters: P, KE, KD, TP, TE
P – A prime number. This value is shared publicly.
K – A crypto key pair, KE and KD, used for encryption and decryption.
TP – Plaintext token. In the context of P2P3 this is a face-up or known card.
TE – Encrypted token. In the context of P2P3 this is a face-down or unknown card.
In the context of P2P3, a participant is a player. A dealer is a special type of player with additional requirements.
No privacy in communications is assumed and all exchanges should be logged. An exchange is an asynchronous message broadcast either to all players or to a specific player. When a communication is described as being broadcast to a specific player, what is meant is that the message will be received by all players but is intended to be acted on or processed by one specific player.
An encryption or decryption path is a list of players that will perform a requested operation(s) in the order specified. A path for four players, for example: player1;player2;player4;player3
Paths may be randomized or algorithmically generated for security, performance and optimal load balancing. For any decryption operations that result in secret values (hole cards, for example), a path must always be self-terminating; in other words, it must terminate at the initiating player.
In the context of P2P3, a clique is a number of players engaged in a mutual game. A game is considered terminated when less than two players remain in a clique.
-
The dealer generates P. This value is broadcast to all players.
-
The dealer generates 52 plaintext tokens, TPs, mapped sequentially to cards in a static "deck". More than one set of tokens may be generated and mapped in this step if desired.
-
All players generate their own K using P.
-
The dealer establishes a random or algorithmically generated betting order, terminating at themselves, and broadcasts it to all players.
-
The dealer randomly shuffles and encrypts all TPs with their K, establishes a random encryption path and broadcasts the resulting TEs to the next player specified in the path.
-
The next player randomly shuffles and encrypts the received TEs, passing the results to the next player in the path established in step 5.
-
Step 5 is repeated until all players have encrypted and shuffled the TEs from previous operations. The final result is a randomized, multi-encrypted token "deck", or RED (Randomized Encrypted Deck). The dealer broadcasts the RED to all players.
-
The dealer generates a random path and broadcasts a selection operation request to the first player in the path.
-
The next player player selects two TEs from the RED as their private cards, either automatically or manually, and broadcasts the remaining RED values to the next player specified in the path created in step 1. At this point the player begins Process C asynchronously.
-
Step 2 is repeated until the final player in the path specified in step 1 has completed step 2. This final player broadcasts the remaining RED to all players.
-
The player establishes a random decryption path terminating at themselves and broadcasts a decryption request along with their chosen TEs to the first player specified in the path.
-
The next player performs a decryption operation using their private KD on the received TEs, in the path order specified by the initiating player in step 1, and broadcasts the results to the next player specified in the path.
-
Step 2 is repeated until the final player, the initiating player, decrypts the TEs using their private KD. The resulting TPs should map to the card value(s) from Process A step 2.
-
The dealer generates a random decryption path and the appropriate number of TEs for the game phase. The chosen cards are broadcast to the next player specified in the path. This step may also be initiated by a player and without requiring a self-terminating path since the operations produce public (community) card values.
-
The next player in the path specified in step 1 decrypts the chosen cards using their KD and broadcasts the partially-decrypted TEs to the next player specified in step 1.
-
The final player in the path specified in step 1 completes the final decryption of the chosen TEs to produce TPs that map to the card value(s) from Process A step 2. The chosen TPs are broadcast to all players.
-
Betting limits, blinds values, and other betting settings are broadcast by the dealer to all players.
-
If not yet established, the dealer establishes a random path for the betting order, including blinds, and broadcasts it to all players.
-
Betting initiates at the first blind and completes at the dealer. Each player maintains betting statistics for other players to properly render bet, call, and raise functionality. Once a bet is committed, the next player in the betting path is given control via a broadcast.
-
Each player takes a turn to bet, call, raise, or fold in the specified path order. Any players that fold are flagged and skipped during subsequent betting operations, in effect becoming observes for the remaining duration of the game.
-
When a betting round completes the dealer initiates Process D to determine the next community card(s).
-
When all community cards have been dealt and the final betting round has completed, all players broadcast their KCs for analysis and display of the winning hand. This step may also involve a submission of both KCs and game logs to third-party verification services.
-
If a new game is initiated, all values are re-generated starting with Process A with the exception of the betting order, as established in step 2, which remains in place until the game is terminated or a winning player is established.
-
When a peer disconnects from a clique or when a peer is virtually disconnected through group consensus or timeout, a re-keying operation is activated by all remaining peers.
-
Each player stores their old K along with a timestamp, generates a new K using the established P, and encrypts all of the TPs established in Process A with the new K to produce a re-keying deck, RKD, which omits public cards and the cards in their hand. For example, if a player is holding 2 cards and 3 additional cards are publicly face-up from a 52 card deck they will encrypt the 47 remaining TPs. The player then generates a random encryption path and broadcasts their RKD to the next player for further encryption.
-
The next player to receive a RKD encrypts the included TEs with their newly generated K and broadcasts the results to the next player in the path specified in step 2.
-
Once the final player has encrypted the RKD they broadcast the result to all players.
-
Once RKDs have been fully encrypted the are compared by players. Any TEs not found in all the RKDs are discarded and the remaining TEs become the new RED. The dealer can resume game play by resuming Process E (or whatever is appropriate to continue the game). Since each player keeps a log of transactions it is possible to verify that an individual player received specific cards simply by decrypting the pre-terminating broadcast (Process C, step 2) using their K at that time.
Upon completion of the game it is possible to deduce what private cards dropped-out players had, but not necessarily how those cards were distributed.
Steps 1 and 2 were revised on April 24, 2015 to correctly reflect implemented drop-out functionality.
The following protocol is used to determine the initial leader or dealer role and is invoked by each player when either a remote or local "start game" signal is received. This signal may be manually or automatically invoked, for example, when a specific number of players have joined a clique.
Secure integer: a positive integer sufficiently secure for use as a plaintext value; for example, a non-zero quadratic residue
Mapping: a secure value mapped directly to a single (usually sequential) numeric value
N: the number of connected players
K: encryption key
D: decryption key
- Generate K and matching D using a predetermined shared prime value for a sufficiently secure, shared CBL
- Generate N+1 secure integer mappings that map sequentially to integers 1 through N+1
- Using K, encrypt and shuffle the mappings generated in step 2 and send the results to next player for encryption.
- The next player generates their own K* and uses it to encrypt the received values, shuffles the results, and sends them to the next player.
- Step 4 is repeated until all players have shuffled and encrypted the values. The final result is broadcast to all players.
- Select a multi-encrypted value and send the selection to the next player.
- The next player selects a multi-encrypted value that has not yet been selected and sends their selection to the next player.
- Step 7 is repeated until all multi-encypted values except one have been selected.
- All players broadcast their K for this operation. The selected multi-encrypted values are decrypted and compared.
* Players may pre-generate their K prior to this step.
As with the game of Rochambeau, every sequential mapped integer from step 2 defeats the one before it and the first defeats the last.
For example, in a two player scenario the sequentially mapped integers are: 1, 2, 3
In this illustration 3 defeats 2, 2 defeats 1, and 1 defeats 3. An "upwards" defeat cycle is also suitable but is not currently implemented.
Because each player executes this protocol, often repeatedly, N results with exactly one winner each are produced. If more than one player has the highest number of wins, those players repeat the protocol until only one player remains. That player becomes the leader/dealer.
Note: Where values are described as "random" it's understood that algorithmically-generated values are pseudo-random. Pseudo-random sources must have sufficient entropy to be considered cryptographically secure but truly random sources such as hardware generators are ideal.