5
\$\begingroup\$

My plan has been to use RSA to exchange AES session-keys with a client, which is then used for all the usual in-game stuff. Clients never connect with each other, all communication is client to server only.

The question is: Would I be wasting my time by encrypting the communication? How are big AAA multiplayer games doing it? If I do do encryption, is the basic scheme I mentioned a good start?

\$\endgroup\$
  • 1
    \$\begingroup\$ Out of curiosity, are you developing a "big AAA multiplayer game"? \$\endgroup\$ – Kromster says support Monica Jan 26 '16 at 9:43
  • 3
    \$\begingroup\$ No, but I have a technical interest in creating a well-made product in all regards even if it's merely a lowly indie game. \$\endgroup\$ – Anonymous Entity Jan 26 '16 at 10:10
  • 1
    \$\begingroup\$ Encrypting and decrypting every packet you send out adds a lot of overhead to your netcode. What is your biggest concern? That a user reverse engineers the packets and writes his own server or client? \$\endgroup\$ – jgallant Jan 26 '16 at 11:28
  • 3
    \$\begingroup\$ I'd probably encrypt the login-data (user & password) but I don't think it adds any security to encrypt everything. \$\endgroup\$ – tkausl Jan 26 '16 at 11:29
  • 3
    \$\begingroup\$ @user11177 You wouldn't typically encrypt game traffic. Instead, to prevent hacking, you would write your server to be authoritative, and verify what the packet is requesting before allowing it. So for example, if the player is requesting to move to a location on the map that is out of reach from his current location, the server would disallow it. You need to be clever with how you handle your incoming packets. \$\endgroup\$ – jgallant Jan 26 '16 at 11:44
1
\$\begingroup\$

This is a community-wiki answer. When you can think of other advantages and disadvantages, feel free to edit.

Advantages:

  • Makes it a bit harder (but not impossible!) to reverse-engineer your protocol with a packet analyzer
  • Protects your users privacy. This is especially relevant when you have passwords transfered over the same channel.
  • Protects your game from any cheats based on network sniffing. This is really only applicable for LAN gameplay, though. Sniffing on the Internet is hard, unless the attacker is an internet service provider.
  • Protects your game from cheats based on client impersonation through packet injection (really only applicable to UDP)
  • Makes it harder for firewalls to block your game.

Disadvantages:

  • Makes it also harder for you to debug with a packet analyzer
  • Encryption and decryption costs some CPU cycles which makes the overall hardware requirements higher (but the cost is not as high as you would expect - modern CPUs often have optimized instruction-sets for common cryptographic algorithms)
  • Costs time to implement (which you can and definitely should reduce by using a library)
  • You need to manage the public and private keys for your servers. This isn't that difficult when you host all your servers yourself because you can then distribute their public keys with your game executable. But when you want your community to host servers, they will need a certificate authority to get their keys signed, or you lose protection from MitM attacks.
\$\endgroup\$
  • 2
    \$\begingroup\$ Simple general rule that I like: (1) send time sensitive data (example player movement) over unencrypted connection (though on a case by case basis some verification could be needed) (2) send non player specific data (updates, models, maps, ...) over unencrypted connection (again verification could be needed) (3) send all other data (chat, personal info, player info, ...) over encrypted connection BUT don't use your own implementation, the easiest way would probably be to use json or xml over https. And a verification method should be stronly considered. \$\endgroup\$ – Selenog Jan 26 '16 at 14:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.