CypherPoker: Software Architecture - monicanagent/cypherpoker GitHub Wiki

The CypherPoker software stack is split into two major sections: the Core Architecture and the Modular Architecture.

The Core Architecture provides generic services such as loading of global data and assets, managing cryptographic operations, handling peer to peer communications, and bootstrapping the Modular Architecture.

The Modular Architecture is typically loaded at runtime by the Core Architecture and contains or loads the main game logic, data, and assets.

###Core Architecture: Cryptographic Subsystem###

To implement the extended SRA cryptosystem the first required component is an arbitrary-length integer math library as the ability of modern computers to natively compute 64-bit and smaller numbers precludes their use in secure games. This library must be capable of efficiently handling modular math such as exponentiation and the ability to work with large prime numbers. Leemon Baird's public domain BigInt.js (http://leemon.com/crypto/BigInt.html) serves this purpose.

An error in the Miller-Rabin primality test identified by Alexei Kourbatov (http://www.javascripter.net/math/primes/millerrabinbug-bigint54.htm) is an important section of Baird's library to address.

Additionally, Kourbatov's implementation of Euler's totient function (http://www.javascripter.net/math/calculators/eulertotientfunction.htm) serves as a good reference to round out the required algorithmic building blocks.

Martin Leslie's extended, hot-seat implementation of SRA in MatLab (http://math.arizona.edu/~mleslie/files/mp.pdf) is an excellent blueprint for the construction of the required cryptographic primitives including a useful subroutine for calculating the Legendre symbol. This addresses the known cryptographic weaknesses of SRA identified by Don Coppersmith (http://link.springer.com/chapter/10.1007%2F3-540-39799-X_10).

Memory areas occupied by unused keys are scrubbed (not simply nulled) when not in use and at the earliest possible moment. Offline keys are stored in protected / privileged memory whenever possible.

###Core Architecture: Multi-threading & Performance Tuning###

The cryptosystem is encapsulated into a threaded process so that it can be employed independently and in tandem where possible. Functions such as generating true primes and computing the Legendre symbol for each card at high CB lengths are computationally intensive so the implementation benefits greatly from multi-threaded operations. In JavaScript this can be accomplished through the Worker API.

A dynamic thread manager is added to enable players to fine-tune the cooperative performance of the cryptosystem processes at runtime as well as to prevent certain types of side-channel attack. At startup, further fine tuning can be applied to the CB length to increase performance at a trade-off in security. Additional optimizations can be made by precomputing P and accompanying TPs which cuts the initial game startup time significantly as the CB length increases.

###Core Architecture: Communications###

A peer to peer communication system may be defined as either Direct or Assisted. In the Direct model players already know of each others' presence (for example, their public IP addresses) and therefore connect directly to each other without any additional aid. In the Assisted model players first connect to a central server to discover each others' presence.

A modular peer to peer communication system is added to the software stack. Initially this is implemented as an Assisted (sometimes Direct) low-latency UDP-based peer to peer protocol. In this implementation the binary messages are encrypted by default but privacy is not essential as all completed actions are broadcast to all participants and stored in local game transaction logs. In JavaScript an API such as WebRTC would be suitable to produce an Assisted implementation.

The core architecture may support more than one concurrent and asynchronous communication system.

###Modular Architecture: Lounge###

A "lounge" module is loaded into the core at runtime to provide player introductions and to form game groups, cliques, as well as to establish an initiating leader / dealer role. In CypherPoker the assumption of a leader / dealer role offers no advantage to the player but does impose on them the additional overhead of initializing the cryptographic parameters for the current game. Additionally, the leader / dealer role is shifted to other players during successive rounds of game play thereby eliminating even a perceived advantage. A commitment scheme or proof of work system would nevertheless benefit this initiating operation by providing a provable initial game play order.

###Modular Architecture: Game Engine###

The Lounge system initiates the loading and initialization of a modular Game Engine once a clique has been fully established. In CypherPoker this is a peer to peer poker variant. The abstraction between Modular and Core Architectures allows other game types and projects to be loaded at runtime with ease.

Generally speaking the Game Engine and its components store game and transaction logs since the Lounge level can't, and shouldn't make assumptions about which messages are relevant for post-game verification.

###Modular Architecture: Game Engine Components###

The final piece in the software stack includes a variety of components that plug into the Game Engine. In CypherPoker, for example, a betting module is included with the game engine to provide betting services. When cryptocurrencies are employed, this module can either be updated or swapped out without affecting other game logic, user interface management, and so on. This modular configurability also extends to non-technical users via XML files and external assets.

Other game engine components include the currency formatter, hand analyzer, and blinds timer.