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!

]]>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.

]]>Although she wasn’t involved in the direct development of the project, she regularly allowed me to bounce ideas and explanations off of her in order to refine how I present them. The need to get concepts across in a cohesive, friendly, but accessibly concise way will become increasingly important and I’m immensely grateful to her, and others, for providing me with an audience and support.

I’ve tried to faithfully record these ideas as I went along and this, along with a full-time job, had slowed down development considerably.

Then this fall I was let go from said job. I was very thankful for what I consider a generous severance so we weren’t left in freefall, but this wouldn’t last forever. We worked out a budget and agreed that unless we could figure out some other way that we could support ourselves by the end of November that I should be looking for work.

On the last week of November we started a crowdfunding campaign but its plug was pulled in about a day and a half. The campaign site provider sent me a non-existent explanation (they’ve since added it), but they transferred the donations that had already been made so it was hard to bear a grudge. Still, although it seemed possible that a crowdfunding campaign would work, it left us with few options.

We couldn’t find a well-recognized provider that didn’t explicitly state that they wouldn’t hesitate to yank our campaign if it even remotely involved gambling. I decided I would do whatever it took so I added a Bitcoin address for donations to the CypherPoker play/test site, posted an open question about feasible alternatives on Reddit, started reviewing the job market, and began to look for my most recent resume.

With a single Bitcoin donation, a cold and grey December rolled into town and the job hunt had turned up no good results yet. We would be able to stretch out our budget a bit but we were definitely operating on the thin end of the dime. The holidays weren’t looking very pretty.

I truly believed that CypherPoker was bound to catch on *eventually* but treading water with no land in sight can be a little unnerving. Maybe this was not yet the time? I could try getting back into the coffee-serving game; wonder if those Reddit posts got some responses.

It turned out that Reddit had something much better.

In a private message someone requested a meeting to discuss my funding needs. And could we do it in person. It didn’t take me long to respond

I’m happy to report that after a few meetings we’ve been thrown a generous lifeline and the project is moving along at a good pace.

If you’ve been following some of my updates you’ll know that the base CypherPoker game is essentially complete. Optimizations, bug fixes, and improved integrity checking are still on my to-do list but now I’m also looking at cryptocurrency integration. It’s this last part that seems to be garnering the most attention for the project (which I fully understand). Unfortunately it’s also the most cutting-edge so there’s not much material to draw on.

I always assumed that some sort of escrow system would be needed but everything that I considered had the problem of colluding verifiers/escrow-holders. I explored options with reputation ratings that would establish trusted verifiers but collusion problems again popped up. Something else was needed, but what?

It was suggested that I look into something I hadn’t yet considered: smart contracts.

After doing some research I came to the conclusion that smart contracts might just be the solution I’d been looking for. I began to experiment in order to better gauge their effectiveness and although I’m still working out some of the details the preliminary results look very promising. I may have to push existing smart contract technology to its limits but so far everything is looking feasible.

All the pieces are falling into place and I’ll have a much better idea of where everything stands in early 2016. Some of the other options I’d mulled over for CypherPoker, such as using Tor or I2P for anonymity (and some DDOS protection), are still part of the plan and in fact it’s looking like smart contract technology will help to answer some of the questions about how these would work.

I’ll be writing more about these developments once I’m satisfied that I have something beyond the merely experimental but there should be lots of news to share with you in the coming year. Even if perfection is always in the next version, I believe that 2016 will be the year when we see the world’s first fully integrated peer to peer poker game, one that incorporates a cryptographic game with cryptocurrency support, automated and provable verification, and anonymity.

Here’s wishing you and yours a safe and enjoyable holiday, and a new year as filled with excitement as I’m sure ours will be!

]]>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.

]]>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.

]]>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.

]]>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.

]]>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.

]]>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.

]]>Don’t worry if you’ve never heard of it. Unless you’re not part of the humble 23-member CypherPoker subreddit or one of the 6 interested members following the Github repository, I can’t imagine how you’d be aware of the project’s existence let alone guess who done it.

I’m going to leave the project’s history and philosophy for my other blog so here I’ll just cover the more technical details.

Since you probably don’t know what it is, CypherPoker is a peer to peer Texas Hold’em poker game based on the work of cryptographers Adi Shamir, Ron Rivest, and Leonard Adleman (“Mental Poker“). All of the gory details can be found on the GitHub wiki and for the squeamish there’s the lighter “Midnight” series.

To nutshell it, CypherPoker eliminates the need for a server (trusted third party) during game play. Through the dark magics of cryptography, players conduct games entirely between themselves. When not playing with known players (friends, for example), the game provides the foundation for anonymous third-party services like multi-signature cryptocurrency escrow, player introduction and reputation rating, and game verification.

I’ve read a bunch and asked some pretty specific technical questions at local Bitcoin meetups while simultaneously poking the client API; I have a pretty good handle on how to proceed there. Regarding the anonymity part, I’m pretty confident about that too. I’m presently finishing up the Rochambeau protocol which has so far demonstrated that the optimizations planned for the game will make things *significantly* faster, and I’ve collected the building blocks for verification and reputation rating services. Not just whistlin’ Dixie here.

There’s still a lot to do but the game part is *just about* done, at least in terms of functionality. Seeing a greater benefit, I spent more time creating a customizable skinning system than an actual skin so the game don’t look so great. But it needn’t not look so great and hopefully not for long.

Rather than discussing the other merits of the plan like I did through Subreddit comments I thought it would be better to jump directly into a direct, barrel-bottom-scraping example:

Since it’s easier and more familiar than doing calculations with 0.004237 Bitcoin, let’s say that the average buy-in for a 3-player game is $1. We’re really low-balling here.

The winner of our cheapie game would walk away with the equivalent of $3 minus the fee for any services we may have provided. Let’s say that our fee is a paltry 1% or $0.03. Balls are super low here.

Now let’s say that we have an old, slow, dual-core clunker lying around on which we can run the game introduction, verification, and escrow (GIVE) services. Our old beater can completely verify and dispatch a game roughly every 5 to 10 minutes per core. Maybe it’ll be faster if verification fails or the crypto being used is weaker but since our balls are already drooping so low we’ll assume the worst-case: 10 minutes per game per core.

This means that our computer will be able to verify up to about 12 games per hour, or 288 games per day. At $0.03 per game, that will produce a daily takeaway of $8.64. We can multiply by a chronically short 28-day month to arrive at a pessimistic total of $241 per month, or $2,892 per year.

We can use an electricity cost calculator to calculate the monthly cost for our highly inefficient box running non-stop in a secluded corner of our apartment at roughly $14 with taxes. Over the course of the year that’ll add up to $168.

In addition to electricity we’re paying for an expensive internet connection, and not with the cheapest provider either. We missed the cut-off date for the introductory discount and we’re paying the regular $108 per month after taxes. Yikes! And don’t forget the $75 we’re shelling out for installation and activation. In the end our internet connection will cost us $1,371 for the year.

Putting it all together, that’s: $2,892 – $1,371 – $168 = $1,353 per year or $112 per month.

If we want to withhold 40% of $2,892 for the maw of some licensing body or state or whatnot we can squeak by on $15.60 per month. After that, each additional processor core or machine would earn about $130.60 more per month (after all deductions), until we hit our bandwidth limit.

Even with fluctuations in the price of Bitcoin, this very pessimistic model could produce enough for an occasional beer. Or it could contribute to a bill payment or help put a little extra food on the table. Whatever turns you on.

But as I said, that’s the bottom of the barrel.

As soon as we adjust any of the unjustly inflated figures I used in my illustration, the outlook becomes rosier. With a more realistic $5 buy-in and a faster quad-core machine capable of verifying closer to the 5-minute limit (about 1100, 3-player games per day), we can calculate a profit of just over $2,600 per month even if all the other numbers and deductions stay the same – including the accursed 28-day month.

Of course this assumes that the machine operates at 100% capacity so we have to tamp down our optimism somewhat, but even if my late-night math is a bit off it’s numbers like these that make me believe that *someone* out there will find utility in running the GIVE services and in time expand them to include robust and open collusion detection. Chances are pretty good that the equipment that you may be reading this post on, and the connection over which it was delivered, are good enough to give it a whirl.

I’m also fairly certain that existing mainstream client-server operators would be able to fish some nice savings out of this idea but I wouldn’t expect that to happen overnight. The amount that they’ve invested in technology and ongoing operations, not to mention the pains of converting to something significantly different, are unlikely to make CypherPoker an attractive prospect in the short term.

On the player end of things I suspect that when not free, the idea of playing a provably fair game of poker with friends for only the cryptocurrency transaction fee, or with potentially anonymous strangers for a slightly larger one, might be attractive. As I’ve demonstrated, the buy-ins can be very small so no one needs to feel uncomfortable with how much Bitcoin they’re investing. In other words, the broad on-ramp slopes gently and is invitingly lit.

There are many additional opportunities that I can foresee around customizing and adapting the software that extend well beyond peer to peer poker but I don’t want to get ahead of myself; there is, after all, enough for me to be excited about right here.

To verify the following message you can retrieve my public PGP key from the first Reddit post I wrote, the main source code license, or by key ID (677BCC9B) from most certificate repositories like pgp.mit.edu, sks-keyservers.net, keys.**gnupg**.net, or pgp.rediris.net.

—–BEGIN PGP MESSAGE—–

Version: GnuPG v2

owEBegKF/ZANAwAIAQC4lz1ne8ybAaxKYg1wbGFpbnRleHQudHh0VdDtXkl0IHdh

cyBtZS4gSSBkaWQgdGhlIEN5cGhlclBva2VyLiBodHRwOi8vcGF0cmlja2JheS5j

YS+JAhwEAAEIAAYFAlXQ7V4ACgkQALiXPWd7zJufVQ/9FyDpDsaVlouzyaArnwLi

0qKEUySjNWlrb47DGcHsTjf1rBH1oPFyoWZDxjTGaNj/6/HI0ND9hsUyoakM5DLt

IJ0oz0+rJZiuECctS66oa5viJWQ4eTvj4xrqH0b5buEQDquhfOJKlV7dZ7qrHzlL

Y/Ae/RLT4cQ3hDCW9ZVKxlxVfoZJf+vc7m72kLgYCf4F7OnRySSkLh2mp/BTOMOP

6Fz0e147pI/w0Orj8/CBRFgLC0D9JVRKlhxBa+ORX4QJJnRIlPv85pEMg48F7NJ+

MkNmioSbKe9F+oOHuIrwIWd4HwaVumstkTjbnQbYo2wMcKUeV6JzhpsqHWoow1LM

TGGjrmnNunqmk71Ng0Hfos/jn1H5oVnYIaB+uKF3m0uR3mh8q9tXq4/1UeBsopqo

rOyBfnBoxd5vLjS31bFJP8qJdxmaNF/ociwo9qiWU8kQev9XPoo/T+OZhuZaqBhC

Gn+FkzT8L0NlmKHnr3lIK2FP9wGnZ4wKPVrwidngHE1ycKpy+ACMsAPTEj0LXdn3

dNAx7/QwyvuUVWsZSnUgrwMGtgp1AZKQZMPYCh4e5gLbu6cwuiidniJDF8y4J5Ko

Z++W0IYJEGlfhTcDkByDDzjx5gj0sKJBfuE5qXrP41Uk45ijCdC8TJ/0b2sRa/OC

keU8I7nwF0D4AzpdnSboGug=

=kPbu

—–END PGP MESSAGE—–