A commenter on my last post mentioned that although the explanation of CypherPoker’s cryptography was accessible it was altogether too long; a five-year-old’s attention span probably won’t get them through the material.

That’s fine, I replied, because understanding the underlying math is not necessary to understand how CypherPoker works. Here are a series of sketches I produced a while ago that will hopefully prove this point:

You’ll note that additional services such as those provided by Ethereum are not included here since they are not part of the *core* CypherPoker code but rather are used by the game to hold wagers and to verify the game. The Ethereum integration topic would make for a great follow-up post but what I’ve described so far describes the bulk of CypherPoker game play. And no math 🙂

patrickb May 2nd, 2016

Posted In: Internet / Web, Security

Tags: cryptography, CypherPoker, encryption, explanation, hand-drawn, sketches

I’ve recently had the opportunity to run over this topic with someone who I’m quite certain isn’t 5, mentally or otherwise, so the title isn’t meant pejoratively but rather as being reassuringly easy to understand. Please don’t be concerned by the length of the post – it’s mostly examples and demonstrations. To see all of this in action or to learn more please visit http://www.cypherpoker.org/ to join the Slack, drop by the GitHub repository, or visit the subreddit .

CypherPoker uses a short mathematical equation to encrypt (hide) or decrypt (reveal) information such as cards that can be represented by numbers (*1=Ace of Spades, 2=Two of Spades, etc.*) An important property of this mathematical equation is that when information is encrypted by multiple players, it can be decrypted by those players in any order – as long as everyone who encrypts also decrypts – kind of like a multi-lock box.

The encryption/decryption system used in CypherPoker uses numbers known as “positive integers“. This means simply that the numbers it uses are whole numbers – no fractions with remainders or decimal point values – and they’re all positive, or equal to or larger than **1**. (We omit **0** since we can’t really use it).

Here are some examples of numbers that are positive integers:

** 1**

** 5**

** 1000**

** 32**

** 999**

** 812798731901**

** 6**

Here are some examples of numbers that are *not* positive integers:

**-1**

** 0.643**

** 98.1**

** -1000**

** 1000.9**

** -198309180981**

** ¼**

** -½**

Here’s the mathematical function that’s used to encrypt or decrypt information:

Sometimes this is written as:

In JavaScript it would look like this:

Math.pow(m,K) % P

You’ll probably recognize the “m^{K}” part which means “m” to the power of “K”, or “m” multiplied by itself “K” times. (I’ll explain why we use the letters “m”, “K”, and “P” in a bit)

Here are some examples:

**6 ^{4} = 6 x 6 x 6 x 6 = 1296**

You can do this calculation by hand or on a calculator by entering the value for “m”, pressing the “x^{y}” key, entering a value for “K”, then pressing “=”.

Once we calculate m^{K} we do a *modulo* operation on the result – the “mod” part. This is also something that you can calculate by hand or on a calculator by entering the result of “m^{K}“, pressing the “MOD” key, entering a value for “P”, and pressing “=”.

Modulo simply “wraps” a number around some maximum value just like an analog clock which is why it’s sometimes called “clock math”.

To understand this, consider the standard 12-hour analog clock:

In our day we have 24 hours but on this kind of clock we can only show **12**. The first **12** hours are fine but at noon, or **12** o’clock, the clock basically resets (to 0), so that the next hour is **1** o’clock.

If we kept counting beyond **12**, **1** p.m. is actually hour **13**, **2** p.m. is hour **14**, **3** p.m. is hour **15**, and so on:

We could keep going around and around on the clock any number of times and land on some number between **0** and **11** (we would never get **12** since the count resets at that point to **0**).

The result of the modulo operation tells us which number we’ll land on if we go “x” number of hours around a clock with “y” divisions, or:

**x mod y**

An analog clock has **12** divisions so the math would look like this:

**x mod 12**

If we want to find out what hour **13** is on our analog clock with **12** divisions we would calculate:

**13 mod 12 = 1**

If **2927** hours passed on the same clock, what number would we land on?

**2927 mod 12 = 11**

The clock we use doesn’t need to have **12** divisions, it can be any positive integer such as **38**:

**x mod 38**

…or 1001:

**x mod 1001**

…or 3:

**x mod 3**

There are ways to do this math with numbers that aren’t positive integers but that doesn’t happen in CypherPoker.

Back to:

The “m” stands for the *message* to be encrypted or decrypted. This is actually just a number but it can *represent* quite a few different things; it could be a letter of the alphabet (*2=A, 3=B, 4=C…*), a coordinate on a map, or maybe a playing card (*2=Ace of Spades, 3=Two of Spades, 4=Three of Spades…*) Although we can use any positive integer for “m”, ** 1** to the power of anything will *always* produce the same value as we started out with so we don’t use it (or **0**, for similar reasons).

The “K” value is the encryption or decryption *Key*. This is a number (of a pair), that is calculated using the “P” value (below) and kept secret by the player.

The “P” value is a *Prime* number. A prime number is one that can be evenly divided only by itself and **1**. Another way to put it is that “P” divided by *any* positive integer other than itself and **1** will always produce a result that’s *not* a positive integer. For example, **5** is a prime number because:

**5/5 = 1
**

But **4** is *not* a prime number because it can be evenly divided by **2** (the result is a positive integer):

**4/4 = 1**

**4/3 = 1.333333…**

**4/2 = 2 (not a prime!)**

**4/1 = 4**

If a number isn’t a prime number we call it a “composite” number.

We use one value for “K” to encrypt, scramble, obfuscate, or hide the “m” value, and another value for “K” to decrypt it, or work in the reverse direction. Since these values come in pairs, together they’re called a “keypair”.

To find keypairs for “K” we find something called a “modular multiplicative inverse”. This simply means finding two values, the keypair “a” and “b” which make the following equation work:

**(ab) mod (P-1) = 1**

This is sometimes written as:

**(a*b) mod (P-1) = 1**

In JavaScript it would look like this:

if ((a*b) % (P-1) == 1) { //a and b are a valid keypair } else { //a and b are NOT a valid keypair }

This means that if you multiply “a” times “b” and modulo the result by “(P-1)” it must produce **1**.

In CypherPoker every player knows the value for “P” before the game begins; let’s say it’s the prime number **11**.

To find keypairs we could simply try every combination of numbers between **1** and **10** (or P-1) to see which ones satisfy the equation.

After lots of calculations we would find two pairs of numbers that work:

**a=3**

** b=7**

** ….since (3 * 7) mod 10 = 21 mod 10 = 1**

**a=9**

** b=9**

** …since (9 * 9) mod 10 = 81 mod 10 = 1**

Keypairs are usually written as *(a,b).* For example: **(3,7)** or **(9,9)**

In the above example we have only **2** keypairs available which means that the encryption system isn’t going to be very secure but the math will work regardless.

To encrypt “m” we use one of the keypairs we found above for “K” and the shared “P” value.

For example, let’s say we want to encrypt **2** (which we’ve decided represents the Ace of Spades). We already know that “P” is **11** and we used that to calculate our keypair of **(3,7)**, so the encryption calculation is:

**2 ^{3} mod 11 = 8**

To decrypt we use the same function, this time using **8** for the encrypted “m” value (from above), and the other half of the keypair for “K”:

**8 ^{7} mod 11 = 2 (Ace of Spades)**

Once we’ve encrypted “m”, the result can again be encrypted again. This can be done over and over and as long as every encryption is followed by a matching decryption we will get back the original value for “m”. Most importantly, all of the encryptions and decryptions can be done in any order.

Here’s an example using both keypairs – **(3,7)** and **(9,9)** – to encrypt the Ace of Spades twice:

**2 ^{3} mod 11 = 8
8^{9} mod 11 = 7 (the final encrypted or “face-down” card)**

Using the other half of the keypairs we can now decrypt:

**7 ^{9} mod 11 = 8
8^{7} mod 11 = 2 (Ace of Spades)
**

This works even if we decrypt in a different order:

**7 ^{7} mod 11 = 6
6^{9} mod 11 = 2 (Ace of Spades)**

Unfortunately there’s a bit of a problem with using just any number for “m”. It turns out that the “quadratic residue modulo P” of the “m” number will be the same no matter how many times you encrypt it.

Although it sounds pretty fancy, the quadratic residue calculation (also known as the Legendre symbol), is no more difficult than everything else we’ve done:

**m ^{(P-1)/2} mod P**

This may also be written as:

**(m^((P-1)/2)) % P**

…or in JavaScript:

Math.pow(m, (P-1)/2) % P

This calculation will *always *produce either **P-1, 0, or 1**. In other words, if P=**11** then the above equation will always produce either a **10**, a **0**, or a **1**.

Check it out:

**2 ^{(11-1)/2} mod 11 = 2^{10/2} mod 11 = 2^{5} mod 11 = 32 mod 11 = 10**

When the result is **1** we say that it’s a “quadratic residue” and when it’s P-1 we call it a “quadratic non-residue”. When the result is **0** it has no special name since only **0** will produce it.

Now remember when we encrypted the number **2** (the Ace of Spades) above with the keypairs **(3,7)** and **(9,9)**? Quick refresher:

**2 ^{3} mod 11 = 8
**

Here we can see that **2** is encrypted to **8** which is then encrypted to **7**. If we look at the quadratic residue calculations we did above we notice that **2**, **8**, and **7** are all quadratic non-residues (**10**).

As part of our decryption we also ended up with **6**:

**7 ^{7} mod 11 = 6**

And wouldn’t you know it, **6** is also a quadratic non-residue!

It doesn’t matter how many times or with which keypair you encrypt the value **2**; when “P” is **11** the encrypted results will *always* be quadratic non-residues. Similarly, if we encrypt the value **9** (“m” is **9**) we would find that all of the results would be quadratic residues just like **9** itself.

If **2** represents the Ace of Spades, **3** is the Two of Spades, **4** is the Three of Spades, and so on, then we know some information about cards that have been encrypted. After all, even if we don’t know exactly which card an encrypted value represents, we know that if it’s a quadratic residue it can’t be the Ace of Spades (since that is a quadratic non-residue).

It sure would be handy to be able know that your poker opponent(s) definitely can’t be holding certain cards, wouldn’t it?

That’s why in CypherPoker the numbers representing cards are only quadratic residues. For example, if “P” is **11** then our cards would be:

**3=Ace of Spades**

** 4=Two of Spades**

** 5=Three of Spades**

** 9=Four of Spades**

To make sure that our cards don’t “leak” information we can’t use any of the other numbers because they’re all quadratic non-residues.

When “P” is **11** we only have **4** *secure* cards and **2** keypairs which doesn’t make for a good or secure game of poker. In order to support a full 52-card deck (as quadratic residues) and have enough keypairs to make it nearly impossible for someone to find the one that we chose, the “P” value must be much larger.

As a security baseline, CypherPoker uses numbers that are 512 bits. That means that “m”, “K”, and “P” are all between **0** and:

**2 ^{512} = 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084096**

(here’s a large integer calculator you can use to see how I produced these results: http://www.javascripter.net/math/calculators/100digitbigintcalculator.htm)

For truly secure games we would probably want to use a 1024 bit number (or larger). That means that “m”, “K”, and “P” are all between **0** and:

**2 ^{1024} = 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216**

Once we start to work with numbers this big it’s hard just to do the basic math let alone find shortcuts to make it faster, and that’s where the security of the encryption lies.

The trick in any good implementation is to be able to perform these large-integer calculations efficiently but this is a problem for which a solution must be found specific to whatever technology is being used. Some programming languages, for example, support large or arbitrary-length integer math *natively* (without any external libraries or additions), but in most cases developers will need to find or write a suitable solution. The arbitrary-length integer math library used in CypherPoker, for example, is the JavaScript-based BigInt.js by Leemon Baird.

Nevertheless, regardless of how the math is handled it must produce the same results as we’ve covered here so it’s safe to say that if you’ve understood everything above you also understand, at a fundamental level, how CypherPoker encryption and decryption work. Congratulations! 😀

patrickb April 18th, 2016

Posted In: Development / Coding, Internet / Web, Security

Tags: Adleman, commutative, cryptography, CypherPoker, encryption, Rivest, Shamir, SRA

As I write this the Ethereum “Homestead” hard fork event has just passed and I can think of no better time to announce that the proof-of-concept integration between CypherPoker and Ethereum is now available!

This is pretty exciting news because it demonstrates how Ethereum’s smart contracts are used to provide game verification and escrow services in lieu of a trusted third party.

I’ll be the first to admit that my first kick at the can was somewhat clumsy but in my defense I hadn’t even heard of Solidity until about four months ago. Since then I’ve crafted a variety of smart contracts that together provide services for cryptographic poker game play: decryption support, poker hand analysis, betting tracker, and so on. They’re by no means ready for anything other than a proof-of-concept, but that was the point 🙂

For the POC the CypherPoker game client had to be “dumbed down” significantly, meaning that it was restricted to using numbers so small that they offer no security whatsoever. This was done in order to accommodate Ethereum’s native 256-bit limit. I’ll go into detail about this at some future time but suffice it to say that incorporating the POC game client changes into the trunk repository should be fairly easy, it’s the smart contract portion that’s going to be most challenging since it will probably require building a big or arbitrary-length integer math library.

Nevertheless, this milestone provides an excellent foundation for future development and projects like BTC Relay hint at tantalizing future directions. With the project growing I’m now taking a breather to reach out to the community – there are many new changes and new tasks that need attention, not to mention the timely discussions to be had around how a decentralized autonomous organization could reward contributors to the project. Please visit the updated CypherPoker.org site to see what’s new and what’s next, and be sure to drop by the CypherPoker Slack or subreddit to chat and discuss.

patrickb March 14th, 2016

Posted In: Development / Coding

Tags: blockchain, cryptocurrencies, CypherPoker, decentralized, encryption, Ethereum, gaming, P2P, peer-to-peer, poker

I joined Cryptologic in early 2013, about a year after it was acquired by Amaya. I’d worked in the online gaming industry for a number of years prior to this and I’m pretty sure that my experience gave me an advantage over other developers vying for the same job. Later on I would discover that I had even more of a leg up as some higher-ups has rooted for me, having known me from my past jobs.

It’s something that I already knew but the professional game development industry in Toronto, especially online gaming, is a small one indeed. A couple of years later, when Amaya made the stunning purchase or PokerStars / Full Tilt, this fact would once again be underscored as I met a number of people from my past who were now working for the online poker giant.

My interaction with PYR Software, the company that develops and maintains the PokerStars / Full Tilt software, was somewhat limited but certainly instructive. Besides getting a small peek inside their software I was given a good idea of the direction that they were heading in and why we were making regular visits to their Richmond Hill offices: we would be integrating our products in order to expand their poker-only offering. At that time Amaya was pushing hard to expand back into the once-lost US market by targeting New Jersey which was keen, or so it was claimed, to capitalize on the insatiable demand for online gambling.

Not long after the acquisition Amaya sold its Cryptologic and Chartwell divisions to NYX Gaming which decided that fat needed to be trimmed and I was let go. The New Jersey market has yet to materialize.

I was disappointed with the somewhat sudden changes but the severance package I received, not to mention my experiences working for Amaya, has left me with nothing but pleasant nostalgia. Online gambling may seem to be a shady business, and my positions prior to Amaya suggest that sometimes it is, but as an employee of the PokerStars owner I’ve had very positive experiences. Sure I may have had disagreements about how they went about things sometimes but in the end they were a damned good company to work for and I would give it serious consideration if they ever asked me to return.

I also can’t say that I ever had any indication that Amaya was anything but forthright in their dealings. Any criticisms I may have had were concerned with efficiency and priorities but I’ve always seen these as being ultimately business and process decisions, and my views as coming from a lowly developer viewpoint. I understood that my take was hardly holistic and while I expressed any concerns that I may have had I didn’t dwell on them.

I need to stress the above points because the following views are founded on much the same basis. I must also emphasize that although some people may view CypherPoker as a challenge to PokerStars / Full Tilt, it was never intended to be anything other than a very modest alternative. I was extremely careful to segregate my work on the project from my Amaya work, even going so far as to eschew the early name of CryptoPoker because it was too close to Cryptologic. Besides, CypherPoker left the starting gate as a free and open-source project that PokerStars / Full Tilt will always be welcome to incorporate into their operations with my blessings.

Having said all that, I’m genuinely perturbed by the direction that Amaya is taking PokerStars in. In a nutshell, they are limiting their higher-stakes games in 2016, sometimes quite severely, in an attempt to bolster their audience:

The reason we are focused on the highest status levels is because these rewards have become so enticing that we have inadvertently altered why some people play and how they play. We are introducing these changes to move towards a more balanced long-term poker economy and to return the game back to one that rewards skill via winning at the tables rather than playing primarily for volume.

This has stirred a considerable backlash in online forums and even inspired a player 48-hour player “strike”. PokerStars’ own celebrity spokesperson Daniel Negreanu has expressed concerns over how the company went about introducing the changes and other big names have expressed deeper misgivings over the announcement.

Personally I understand the wish to create a leaner operation under the new corporate ownership but it seems like Amaya is tinkering with a pretty well-balanced formula and perhaps to its own detriment. I was equally dubious when online rumours of a PokerStars casino, which was then in its very early and unannounced stages, were making the rounds. I knew the rumours to be true since I was actually working on the project and I also had an inkling as to how people would react to it; in short, not very positively. Online poker players were especially critical of what they viewed as a way to sucker people out of their money.

To me it came down to simple profitability as was (probably) required by new corporate demands, and it would be achieved without much input from the very community that was expected to make it happen. Even though at the time I was working at an arm’s length from PokerStars, or perhaps because of it, I was able to see a disconnect between what the corporation wanted and what the players requested. Based on the feedback I’ve seen online, the recent decision by PokerStars is continuing this trend.

Once again I must remind myself that I don’t really know what’s happening at most levels of the company so my analysis is myopic at best. However, it seems like bad practice to disenfranchise players with sweeping changes that according to the company spokesman were very poorly communicated and not requested. I don’t believe that PokerStars is in such bad shape that it can’t swallow slightly smaller profits in order to make existing players happy and encourage new ones to reach for poker stardom, so I’m left with the impression that this is all intended simply to create extra profits for shareholders and investors who may not care much about PokerStars or online poker in general.

If this is true then it doesn’t bode well for the future of online poker as it stands today. If profits are primarily what’s driving the world’s biggest online poker site then I expect that many players will either look to alternatives or resolve themselves to grinding away until something better comes along. Even though it’s not exactly the same, perhaps CypherPoker will be that thing, or perhaps PokerStars will reverse their direction. Either way it’s my sincere hope that online poker players keep hope in the future because one way or another things are bound to get better.

patrickb December 4th, 2015

Posted In: Development / Coding, Internet / Web

Tags: Amaya, Cryptologic, CypherPoker, Full Tilt, gambling, gaming, New Jersey, online poker, poker, PokerStars, PYR Software

I while ago I put together a video demonstrating how to compile CypherPoker to play over the internet (rather than just LAN/Wireless LAN).

Since then the software has been updated to support this functionality more generically and private internet games are now segmented by a “private game identifier” (that’s the name I’m using for now anyways). You can try it out at http://www.cypherpoker.org/play – instructions are found on the page.

Similarly to the video, this solution uses Adobe’s Cirrus service to introduce peers to each other when playing over the internet/web.

Unfortunately, being a developer test service means that Cirrus isn’t suitable for dependable or broad-based deployment. Besides, it’s somewhat iffy describing CypherPoker as peer-to-peer software when it requires a centralized, corporate-branded service.

Had I not discovered the OpenRTMFP/Cumulus project early on in my experiments with RTMFP I might have eschewed the protocol altogether, but not only has the rendezvous server continued to be developed but it’s also spun off the even more robust MonaServer. The software now supports a mix of RTMFP/RTMP/RTMPE, HTTP, and Websocket protocols with built-in support for JSON-RPC and XML-RPC, which should allow it to scale nicely beyond ActionScript in the future. In addition to this, both Cumulus and MonaServer come with support for the LUA scripting language which makes them suitable for a wide variety of applications.

While it’s not the *only* type of connectivity that I’d like to see in CypherPoker, in this post I’m going to briefly discuss how MonaServer can be used to establish assisted peer-to-peer networking without relying in any third-party service such as Cirrus. Put another way, we’ll be examining how to set up your own Cirrus-like rendezvous service for CypherPoker.

First you’ll need to grab a copy of MonaServer. If you want to build your own version from scratch you can follow the instructions on the project’s site, but for this tutorial we’ll use the standard precompiled Windows version as-is. For this I’ve created a ZIP file containing both MonaServer and the web version of CypherPoker that you can download here.

Just unzip the file and execute ** run.bat**; this’ll start up MonaServer with default settings and then after a brief delay it will launch two instances of CypherPoker in your default browser. MonaServer takes care of both serving the game files in the “

The server software will listen to UDP connections on port 1935, the default for RTMFP, and port 80 for HTTP transactions over TCP. These and many other defaults can be changed quite easily if desired or required – for example, if you’re already running a web server on port 80.

CypherPoker gets its default server information for internet/web play from the “*RTMFP_INET*” definition of the ** settings.xml** file in the “

The address “*rtmfp://localhost/*” will probably also work just as well and if we’re using a non-standard port it can simply be appended to the server URI. For example, if MonaServer has been configured to listen to RTMFP connections on port 2968 the *<serverAddress>* node would look like this:

In terms of client and server setup there isn’t really much more to do. However, the rendezvous service isn’t going to be terribly useful if it’s only accessible within your own local network so there are a couple of other things that need to be set up.

If this is your first time I’d recommend reading up on some of the potential pitfalls of hosting your own server as well as acquainting yourself with some of the background concepts. Be sure that you’re comfortable with changing both your router settings and Windows firewall and that you understand the implications before embarking on the next steps; you’ll be opening up part of your network and computer to random internet traffic and not all of that traffic is friendly.

First you’ll need to update your Windows firewall settings. The first time that you run MonaServer Windows will ask you what type of firewall permissions to grant it. You should enable both private and public networks:

If you missed this part or didn’t select both options you can always start the firewall manager by running ** \Windows\System32\WF.msc**, or by searching for “

Right-click on the entry and select “*Properties*” from the context menu. You’ll probably want to explore some of the other filtering features available but for now we just want to make sure that the rule is enabled, that connections are allowed in the “*General*” tab…

…and that both “*Private*” and “*Public*” profiles are selected in the “*Advanced*” tab:

Next we’ll want to make note of our machine’s subnet address. To do this, launch the command prompt by typing “*cmd*” into the START menu search field and then “*ipconfig*” in the opened command prompt window. This will display your current network adapter configuration and your machine’s local IP address:

The next step will require you to update some settings on your router in order to allow outside (internet) traffic through to your computer and to MonaServer.

Unfortunately there are many routers on the market so attempting to cover them all here isn’t possible but there’s an excellent resource available at: http://portforward.com/english/routers/port_forwarding/

What we want to accomplish is to forward external traffic on the specified ports to the computer with MonaServer. Some routers do this by binding to a specific subnet IP, which is why we looked it up earlier, and some routers identify the computer by name so you only need to select it from a list.

We’ll want to create two entries for our MonaServer computer, one for UDP port 1935 and one for TCP port 80, assuming you’re using the default settings for the server and that we’re using it both to serve the game files and to provide a rendezvous service.

You can do fancier mapping here if desired but I’ll leave it up to you to do the research on how that’s done with your specific router.

One final step you may wish to take with your router is to assign a static, fixed, or permanent IP to the computer running MonaServer so that you won’t have to repeat these steps if the computer’s subnet address changes, which may happen anytime that it’s disconnected from the network for a period of time. This can by done by updating Windows’ networking settings or (often) on the router.

Now that we’ve set up the router to allow and forward internet traffic through to MonaServer we have only two steps remaining.

First we need to find out what our public IP is since the address we’ve seen so far is internal to our own network only. Simply visit http://whatismyip.org/ or any similar service and note the public IP listed there.

Finally, update the CypherPoker *settings.xml* file with the external IP. For example, if our public IP is 174.90.151.132 and we’re using the default RTMFP port (1935), the settings data would look like this:

If we’re using a non-standard port such as 2096, for example, we simply add the custom port to the URI:

As mentioned earlier, because of this configuration data the CypherPoker files can be served from a completely different web server and the software will communicate with the RTMFP rendezvous service running on our machine. However, if we’re using MonaServer to serve both web content and connect RTMFP peers we can now simply load the software from, and have it connect to, the same server. Using our example public IP from above this would be something like: **http://174.90.151.132/index.html**

Using a direct IP address like this isn’t the nicest solution from a player perspective but it works well. We could make this a little more friendly by mapping our public IP to a domain name by using a service like No-IP or, better yet, we could host the CypherPoker files on a remote web server with our own registered domain which will make it appear to players as though the game is running from there. With the AIR versions of the game (desktop/mobile) this would be even less visible as the game would *just connect* and work (as long as MonaServer is running on our machine).

RTMFP is a great protocol because of the features it provides beyond mere peer-to-peer messaging, features like audio/video streaming and (nearly) effortless data sharing similar to BitTorrent. While the protocol is an open standard it’s not widely adapted for use outside of Adobe’s technology so it wouldn’t be an ideal solution for other implementations of CypherPoker like JavaScript, for example.

Still, the protocol’s features make a nifty addition to the ActionScript version and I see no reason why RTMFP wouldn’t be just one among a suite of side-by-side protocols that would be used to provide communications for CypherPoker. It’s still too early to say anything definitively but direct socket communications, WebSockets, XMPP, and basic HTTP transactions are just some of the other ideas that seem viable.

Having done the upfront work I can safely say that Tor, I2P, and other SOCKS5 proxy systems are also in the running but there’s plenty of work yet to be done so RTMFP and MonaServer are good initial options.

patrickb November 30th, 2015

Posted In: Development / Coding, Internet / Web

Tags: Cumulus, CypherPoker, MonaServer, P2P, peer-to-peer, Rendezvous, RTMFP, server

Then you may like watching me code CypherPoker at LiveCoding.tv

https://www.livecoding.tv/monican_agent/

Experience hours of thrilling DEBUGGING! Feel the terror of hideous, grotesque LOGS! Fall in love with dashing RACE CONDITIONS!

Or drop by to chat.

patrickb November 5th, 2015

Posted In: Development / Coding, Internet / Web

Tags: CypherPoker, LiveCoding.tv

A group of security researchers recently announced that they had found a serious flaw in the Diffie-Hellman key exchange (the initial “handshake” portion of a HTTPS/SSL session). Specifically, they discovered a problem with many implementations around the web in which the same prime number (modulus) is being used.

The math used for Diffie-Hellman is very similar to CypherPoker’s. Here’s the specific section from CypherPoker’s accompanying documentation where this is described:

A random CB-length prime integer, P, is generated using Maurer’s Method by the activity leader. This value is shared with all participants for subsequent operations.

I’ve mentioned a number of times that this portion of the protocol can be sped up, often significantly, by pre-computing the P value and subsequently dependent values. Undoubtedly, this was the same reasoning used by developers when they baked pre-computed primes into their cryptosystems. According to the group’s research paper:

Generating primes with special properties can be computationally burdensome, so many implementations use fixed or standardized Diffie-Hellman parameters.

True dat.

Although this doesn’t seem especially dangerous (P is publicly shared, after all), it’s not too difficult to conclude that, at least in theory, knowing this value well in advance of a communication could allow an attacker to prepare resultant values that could significantly decrease the amount of time required to find the crypto keys being used. Once this is accomplished the security of the cryptosystem is basically non-existent.

So what does this mean for CypherPoker?

Not much. 🙂

For starters, as I’d mentioned in an earlier post, the encryption for any given game needs to remain secure only for the duration of the game. After that there are actually benefits to being able to break the encryption for any players that had dropped out during a game. In contrast, most public/private keys used in HTTPS handshakes are intended to remain unchanged, and unbroken, for at least a few years.

Secondly, unlike public/private key cryptosystems, both keys in CypherPoker are kept private until a game is complete. I would stress again that I’m not a cryptographer but to me it stands to reason that removing one of the known variables from an equation makes the equation more difficult to solve.

Finally, and most importantly, CypherPoker was built to use dynamic values for every game. In other words, the shared prime value is newly generated for each new game. Although optimizations to the game can skip this step (as the Rochambeau protocol now does), these are optional and secondary (as the Rochambeau protocol now does) rather than being primary and hard-coded.

How much more secure this makes CypherPoker, rather than something like Diffie-Hellman, crosses over into the theoretical realm, and I’m as much of a theoretical mathematician as I am a cryptographer/cryptanalyst, but unless I’ve made included some tragic errors in my code it seems reasonable for me to conclude that CypherPoker is pretty darned secure.

patrickb October 17th, 2015

Posted In: Internet / Web, Security

Tags: cryptography, CypherPoker, Diffie-Hellman, HTTPS, research, secure key exchange, security, SRA, SSL

I’ve been mentioning it as a feature since the early days, and now that CypherPoker has gotten a little more attention people are starting to ask how it can be made to communicate over the internet.

So I made a video:

I’ve covered the underlying RTMFP connectivity a while ago along with hints of other proposals I’ve been bouncing around, but I should mention that these are just two of the more obvious ways that instances of the game can communicate. The book is definitely not being closed on this topic and suggestions are always welcome.

patrickb October 10th, 2015

Posted In: Development / Coding, Internet / Web

Tags: ActionScript, Adobe AIR, CypherPoker, gaming, P2P, peer-to-peer, poker

A few people have asked me how secure CypherPoker is, and my reply is usually something along the lines of “that’s a tricky answer”.

The problem I have in explaining is two-fold: I’m not a cryptographer, and we’re not exactly comparing apples to apples when it comes to similar cryptosystems.

But I’ll give it the old college try 🙂

I’ve been coding for over a couple of decades now so I’m not exactly an amateur, but I’m not at any level that I could honestly provide a theoretically-sound answer.

Still, the fact that the SRA cryptosystem is a close cousin of RSA should provide some realistic answers provided by people far more knowledgeable than me.

The current state-of-the-art for RSA security is 2048 bits. The equivalent to this is 256 CBL in my implementation of SRA (just divide the number of bits by 8). This is considered infeasibly difficult to crack using known attacks and so is considered secure. As computing power increases so will the ability to crack smaller keys so their length must be increased.

In SRA the key length, or CBL, is purposefully variable to accommodate a broad variety of processing power and desired performance. There is no bottom or top end so there is nothing to stop players from cranking it up really high, but the higher the security the lower the performance.

Because RSA and SRA are closely related they are both potentially susceptible to quantum attacks via something like Shor’s algorithm. In both cases this attack centers around finding the factors of the shared prime modulus value. The largest number factored so far is 56153, which is far below any current security threshold, but the eventuality looms nevertheless.

However, there are a couple of wrinkles with the quantum approach:

First, it still takes time to find the factors of the prime modulus value, albeit far less than by using classical computing. With RSA the public key doesn’t change very often so we have a large-ish window of time in which to find its private counterpart. With CypherPoker (SRA) the keys need to remain secret only for the duration of the game after which they *must* be revealed in order to verify the game. Although the re-keying protocol allows the game to continue whenever a player drops out of the game for any reason, it is still useful to have their missing encryption keys at the completion of the game if we want to be extra thorough in our post-game verification. In effect, breaking the encrypted session would have to be done while the game is still active, which is usually not a very long window of time. Once a game is complete, breaking the encryption is potentially beneficial.

Second, with RSA we know one half of the keys (public) used for crypto operations. Although SRA derives and uses its crypto keys in a similar way to RSA, both keys are private until the end of the game. Again, I’m not an expert in the field but it’s my understanding that this effectively removes one of the known values in Shor’s algorithm, and that sounds like a potential roadblock.

Additionally, with CypherPoker’s re-keying/dropout support the ability to generate new crypto keys at somewhat arbitrary intervals provides extra foils against attackers in games where cards are returned back to the deck. With certain games like Texas Hold’em this wouldn’t necessarily apply*, but it’s certainly a plus for future implementations.

Besides the security provided by the cryptosystem, the CypherPoker software provides a couple of additional security features.

These include storing sensitive data like crypto keys in secure locations when not actively in use, and the asynchronous Rochambeau protocol which prevents collusion when determining the initial dealer for a game.

There are other security features that can be added in future versions, some of which should be quite easy to implement. For example, we can automatically turn any visible private cards face down when the player is not viewing them. This would reduce the possibility of any malware on the player’s machine being able to send screen captures of the game window to attackers. Obviously this isn’t a perfect solution, but every little bit helps.

Finally, the fact that CypherPoker is entirely open source has two implications:

First of all, anyone can update and release the software with security features that I haven’t even thought of, and these features can be made available immediately. I genuinely don’t believe that established online poker sites promote cheating, but the fact that they use primarily proprietary software means that players are at their mercy to fix any software security problems.

Secondly, CypherPoker needn’t be exclusively for Adobe’s runtimes. Because the communication protocols are fairly generic I’ve pointed out that JavaScript would make a good candidate for an initial port of the software, and I see no reason why other languages and runtimes couldn’t be used as well. If a JavaScript version turned out to be riddled with security problems then players could easily switch to a C++ version, Python verison, Objective-C version, Java version, and so on. All of these versions should be able to talk to each other so players would be free to make informed choices about which implementations are suitable for them.

So … how secure is CypherPoker?

It would be irresponsible for me to claim that it’s perfect but from my analysis, for what it’s worth, it’s pretty darned secure. I recognize that there’s always a need for improvement, but when CypherPoker is compared to similar software it’s clear that the product is operating on solid foundations.

* A re-keying operation could be initiated at any point but right now it’s used only when a player drops out.

patrickb October 8th, 2015

Posted In: Development / Coding, Security

Tags: CypherPoker, encryption, P2P, peer-to-peer, quantum computing, RSA, security, shor's algorithm, SRA