No idea where you got that information, but I can assure you AES never reveals the key. It doesn't even allow reconstruction of the key when used in ECB mode - though ECB allows attacks against the ciphertext. What you've read was probably about RC4 or something similar. Just use an IV and AES OFB-mode, that works for your purpose and is secure! I don't get why you want the other player to have the encrypted data in advance though. Instead of sending the key to decrypt the data you could simply send the data the moment player1 reveals some data to player2.
Elias Cameron Hutchison wrote: > 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] > <mailto:[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]> > > <mailto:[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]> > > <mailto:[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]> > > <mailto:[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] > <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] > <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.
