No, it is not a server-based game. There are only two participants. I am trying to implement a peer-to-peer system that does not need a trusted third party.
At the end of the initialisation protocol, each player is left with a list of tokens (cards) that are encrypted by both players (technically they don't need to keep their own cards encrypted with their own keys but it helps to think of a single list of shared tokens than each player having a list of the same tokens but encrypted by the other player). Anyway, after initialisation, player A can choose to reveal a token to player B by sending them the key that they used to encrypt that token. And vice versa. To do this, I'm looking for a commutative cipher where each token is multiply-encrypted with multiple keys. Each token is encrypted with a different key. From previous research, a stream-based cipher (XOR) will leave the initialisation phase vulnerable to key discovery. That is how I've ended finding Massey-Omura (for which I cannot find an implementation), and now looking for something similar that is implemented in crypto++. On Sun, Jul 4, 2010 at 9:55 AM, Elias Önal <[email protected]>wrote: > I don't get the problem. It's a server based game right? So just use > some hybrid encryption? I don't get why you'd want to play with a > commutative system system, you probably could do it with AES in OFB > (Streamcipher, thus using XOR) mode, but I don't get the advantage. What > are you trying to hide from the participants? Can't you simply stop > sending that data to them? You want both to have the data, but make them > only able to read it if both agree? Just encrypt it twice using AES OFB > and give each one a key. In order to get the plaintext they have to > apply both keys (thus exchange keys), though the order in which they're > applied doesn't matter. That's what you want to archive using a > commutative system? > > Elias > > Cameron Hutchison wrote: > > [I sent this directly to Elias by accident - gmail newbie here. Here > > it is again for the list] > > > > I don't think man-in-the-middle is going to be a problem. My goal > > here is to make sure information is not revealed to the participants > > (of which there are two, but the protocol could probably be extended > > to more easily enough) before both players agree to it. > > > > Anyway, if the man-in-the-middle does become an issue, the game can be > > played over a SSL/TLS link so I dont have to invent a new identity > > scheme for the game (i.e. make it possible to set up comms with > > existing certs - I hate the proliferation of different incompatible > > certs for different systems that I'm not going to add to it). > > > > None of that matters though, unless I find an appropriate cipher for > > the game itself. :-) > > > > Cheers > > > > On Sun, Jul 4, 2010 at 9:32 AM, Elias <[email protected] > > <mailto:[email protected]>> wrote: > > > > Don't forget about man-in-the-middle - You'd have to use signatures > at > > least! So better use asymmetric crypto in the first place ;) > > > > On Jul 1, 6:48 am, Cameron Hutchison <[email protected] > > <mailto:[email protected]>> wrote: > > > Hi crypto++ users, > > > > > > I'm looking for a commutative cipher to use to implement a card > game > > > protocol (any type of card game, not just the 52/54 standard deck > > > games). > > > > > > My research has led me to the Massey-Omura cryptosystem, but I > > cannot > > > find any implementations of it. I have read of references to > > elliptic > > > curve variations on M-O but most of what I read goes over my head. > I > > > don't have the math background to understand the actual > > implementation > > > and theory behind these cryptosystems. So I'm not sure if what I've > > > read is saying that ECC is commutative or not, but my > > experiments with > > > the ECC systems in crypto++ leads me to believe it is not. > > > > > > Are there any commutative ciphers in crypto++ (besides XOR)? > > Symmetric > > > key would be simplest, but I can also work with asymmetric key > > > algorithms. > > > > > > Thanks > > > > -- > > You received this message because you are subscribed to the > > "Crypto++ Users" Google Group. > > To unsubscribe, send an email to > > [email protected] > > <mailto:[email protected]>. > > More information about Crypto++ and this group is available at > > http://www.cryptopp.com. > > > > > > -- > > You received this message because you are subscribed to the "Crypto++ > > Users" Google Group. > > To unsubscribe, send an email to > > [email protected]. > > More information about Crypto++ and this group is available at > > http://www.cryptopp.com. > > -- > You received this message because you are subscribed to the "Crypto++ > Users" Google Group. > To unsubscribe, send an email to > [email protected]. > More information about Crypto++ and this group is available at > http://www.cryptopp.com. > -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
