Me and my team is developing a multiplayer videogame with a Client/Server-Topology. This secures the match from clients who have the intention to cheat because of server authority but still allows the server to modify outgoing and incoming packets as well as sensible user data of the players.

We chose to use AES as the encryption method, but had the problem of informing all peers about the used key to secure the network-packets with this encryption method.

I read into the Diffie-Hellman-Merkle key exchange algorithm which worked perfectly between two peers (Alice and Bob how they are called in the examples). The problem is that our game allows matches with a variable number of players, ranging from 2 to 16.

The condition seems to be that every client needs to generate the same number b (exponent of g) to share its equation result with the server, so that both have the same result which is s.

I have no clue how to generate a secret key on every peer, if the time at which clients connect and the number of connections over the match are variable.

  • Are you sure you need to share the same symetric key with all players? Does not look a good design. May I suggest you explain better what are you wanting to protect from (your threath model), maybe we can suggest better approaches. Ex: Do you want to protect data while transfered between server and clients? Or do you also have client-to-client connections?
    – CristianTM
    Jun 22, 2016 at 11:50
  • The Client/Server-topology does not intend connections between the clients, only to the server. So I want to encrypt data thats sent between the server and clients. And how would I encrypt using AES if not every peer has the same symetric key? Are there alternatives, if yes, which? Jun 22, 2016 at 12:14

2 Answers 2


You should not deploy your own encryption scheme for this, neither share symetric keys with multiple parties.

To protect data on transit between each client and the server, you should use TLS to protect those connections. TLS will take care of symetric key agreement and encryption decryption to each client the right way, avoiding many many things you are not considering on the protection of the data on transit. But it will not be a shared key between all clients, but a key for each client, and also a key that changes on new sessions/connections. Basically it will do a DH style AES key agreement with each user (may choose other algorithms too), but will take care on avoiding many attacks that are possible in such schemes that you just wont even catch if you just use plain DH to agree on a symetric key, even if you run one DH agreement with each user.

If you also want to protect data at rest, that is, when stored, there is no gain on sharing a key. Each one should generate its own secret key.

  • Thanks for this answer. Is TLS fitted for fast realtime communication though? The performance of the encryption is important because some packets with sensitive data are sent at least twice a second. Jun 22, 2016 at 12:49
  • You should make sure you keep a persistent connection. There is an overhead on key agreement, on the connection phase when compared to your scheme, but that is a trade off for the security you want/neeed. On the connection itself, it should not be a problem, so just keep the connection open. Looks like your scheme would be better since you just need to do the key agreement one time. But it is not safe to MITM attacks, to begin with. If you start protecting against most probable attacks you will end with TLS anyway.
    – CristianTM
    Jun 22, 2016 at 13:23
  • Alright, those details really helped me. I will probably roll with a custom AES/RSA implementation and if our team really demands complete security we will switch to TLS. MITM attacks are possible, but I doubt that a small video game is worth the effort to start one as the information exchanged is important, but not for more than ingame tactics and the player character. Jun 22, 2016 at 13:48
  • Sorry to insist, but I think I might not have been clear. If you just use a RSA/AES custom implementation, you are probably not adding any security to the system. While it is encrypted, any attacker that could sniff it could problably also get access to the key. You should probably define the threath model (attacker capabilities that you want to defend from), because if not you are just adding encryption, not any security at all.
    – CristianTM
    Jun 22, 2016 at 13:53
  • 1
    Sure okay, I will look at TLS and probably implement it. Still, I really want to learn something about connecting cryptology and networking which is why I like to do some things by myself. I will definitely not use them in the final build, you are completely right that this is dangerous and probably ineffective against cheaters. Jun 22, 2016 at 14:00

This thing should be simple.

First you need a crypto library like openssl.

If there is a registration phase,

  • you could have the clients generate a pair of private/public keys, (DH or RSA, using openssl)
  • then announce the public part on the server, also called client certificate.

And that's it. On every new client-server connection, a symmetric key (AES) will be generated and exchanged, using the certificates.

You don't really need to change these keys often.
But if you do, playing a game seems like a big opportunity for high entropy, which will help randomness calculation times, used in key generation.

  • Thanks for the answer! Also you are talking about changing keys, do you mean the AES key used to encrypt network communication? Jun 22, 2016 at 12:37
  • 1
    Why would clients need to generate a pair of private/public key pair? It would be useful only if some kind of TLS layer client authentication was required, which is not part of OP question, and in all case you do not explain how the client's public key could be "announced" securely to the server. The OP seems to just need standard TLS, the same used by HTTPS web servers for instance, which guaranties server authentication at the TLS layer and ensures confidentiality and integrity of the communication between the client and the server. Jun 22, 2016 at 12:40
  • So TLS is doing the job? What is with OpenSSL? Im kind of new to cryptography, especially in IT. Jun 22, 2016 at 12:45
  • ^^^ A new AES key is generated in every new connection. ^^ Having every client certified, allows secure client-to-client communication, if needed. ^ Generating an RSA certificate is independent of the protocol in use, although TLS1.2 is considered the most robust option.
    – fouss
    Jun 22, 2016 at 12:46
  • 1) You dont need client certificates. You could use it to replace other client authentication mechanisms you probably already have, but don´t need to. It would add other complications to the scheme that probably don´t worth it. 2) OpenSSL is one implementation of TLS. You may want to use it IF you are programming on C or its derived languages. But was given just as an example.
    – CristianTM
    Jun 22, 2016 at 13:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .