The question of implementing peer to peer mental poker has already been asked on stackoverflow. And there appears to be an implementation called LibTMCG.

Also on this site a question was asked about problems such as clients disconnecting or refusing to act (show cards, bet/check/fold). LibTMCG seemed to not deal with such problems from a cursory glance.

An implementation of mental poker that is based on html naturally precludes peer to peer and must rely on an untrusted http server.

So given the constraint that the clients must communicate only with the http server how does the implementation of mental poker change? And are problems such as clients disconnecting or refusing to act (show cards, bet/check/fold) easier or more difficult given communication only with the server.

Implementing the game using web technology means that the rouge server may send a manipulated program (javascript) to the user. Therefore the user must be able to do the verification without relying on his game client.
–
Hendrik Brummermann♦Jan 14 '13 at 16:53

1 Answer
1

In general, from a security analysis viewpoint, there isn't much difference between a peer-to-peer protocol and one using an untrusted server — and, insofar as there is any, the peer-to-peer case is strictly harder to secure.

This is because, if we have a secure peer-to-peer protocol, we can always implement it over an untrusted server by simply having the server do nothing but forward messages between peers. In typical attack scenarios, we already assume that the network connections between the peers may be controlled by the attacker, so giving the attacker control of a central relay server doesn't really add anything to their assumed capabilities.

Of course, if the security of the peer-to-peer protocol has only been shown under a weaker attack scenario — such as one where the attacker cannot intercept traffic between honest peers, or where they can only eavesdrop but not modify it — then the security proof may not carry over so directly.

Another potential cause of complications may be if we want to limit what the server will let the clients do. In general, for peer-to-peer protocols, we assume that, in the absence of attacks, the network is neutral and will carry whatever messages the peers will send. However, even an honest game server operator might reasonably balk at, say, letting the server relay arbitrary encrypted messages between clients, in which case protocols depending on establishing secure encrypted channels between peers may not be practical. (They may still be secure, in the vacuous sense that a protocol where nobody ever sends any messages is secure, but that's not much consolation to someone who'd actually like to do something using the protocol.)