On Sun, Jul 4, 2010 at 10:24 AM, Elias Önal <[email protected]>wrote:
> 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! http://stackoverflow.com/questions/2104982/is-there-a-secure-cryptographic-algorithm-where-encryption-and-decryption-can-be/2105369 In the selected answer of that SO question: "On the other hand, the solutions based on RSA or stream cipher can be broken under this assumption." > 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. > Because player1 could cheat then and send tokens that were not in the original list (deck). At the start of the game, both players must submit their list of tokens to each other in such a way that the contents are not revealed until the game rules say to do so. As the game progresses, the tokens are revealed to the specific players as the required by the rules. If you want some more details of what I'm trying to do, see this old sci.crypt post of mine: http://groups.google.com/group/sci.crypt/browse_thread/thread/eb2512e31e6bb3fc/9e1e9a0cae9fab2f I am "George Hewitson" in that thread (an old sci.crypt alias I used to use). Cheers > 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. > -- 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.
