Using Merkle's Puzzles, the key wouldn't need to ever be transmitted across the network. It, or a seed from which the key could be formulated, would be contained within one of the puzzles which would be randomly solved by the client, after which some sort of a sentinel/signature message could be sent back, and mapped by the server to one of the keys contained within the puzzle set.
However, because of the weakness of this approach, a long-running game (in comparison to the amount of time to solve some percentage of the puzzles) would require a key re-negotiation. On a slightly different note, I'd worry about runtime analysis (but I'm not sure what kind of tools, if any, are available for such analysis of SWFs not compiled for debug mode). With tools for runtime analysis, it would make it extremely difficult to provide sufficient security for the problem. Overall, the problem is fairly intractable as has pretty much been pointed out in the thread. --Kaleb --- In flexcoders@yahoogroups.com, Tom Chiverton <[EMAIL PROTECTED]> wrote: > > On Thursday 29 May 2008, kaleb_pederson wrote: > > b) figure out the AES encryption key (possibly generated > > dynamically) > > I motivated attacked could probably intercept the key as it was sent, so you'd > want something like those SecureID tokens where both the server and client > come up with the same dynamic key, based off the current time etc. > > -- > Tom Chiverton
