CypherPoker security redux
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.
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.