I'm implementing a custom binary protocol for a new multiplayer game I'm working on. Its a turn-based strategy game so timing doesn't really matter. I've currently got the basic data sync portion of the system complete, and I was wondering how user login/logout and encryption is typically done for MMORPG games or similar.

  • Can you recommend a scheme for secure/secret password transmission during login? ( Diffie-Hellman key exchange?)
  • How do I implement strong encryption for data packets? (AES 128-bit? .. or whatever scheme this post refers to as "encryption stronger than you are likely to crack")
  • Are there datagram format schemes that help to harden the game server to replay attacks, invalid data packets and the like?

2 Answers 2



  • SRP - Secure Remote Password - This is based on Diffie-Hellman. The idea is that you can do a mutual password check without actually ever transferring the password or any information that can be used to derive it. Even though it's secure over the wire you should still hash and salt your passwords as your server must never store them in plain text.
  • The advantage of SRP is that once it completes it also gives you a mutually negotiated encryption key that an attacker would not have been able to deduce given the data you have transferred. This means that you are free to use a symmetric encryption algorithm (like AES) once the user is authenticated.
  • Assuming you are using UDP with your own reliable/ordered (connection-orientated) implementation on top of it: encrypt the entire UDP playload - including your 'packet sequence number'. If your system is designed correctly it will automatically reject replayed messages and an intruder won't be able to change the packet sequence number because it's encrypted (thus a replay is possible - but it would be automatically ignored).


Should your authentication be secure? Absolutely. Make no compromises in terms of security when a password is in question. Thus you should be definitely be considering the first bullet in my answer.

Should your data be secure? Only if it is an in-game purchase/micro-transaction - and then why not just use something tried and true like HTTPS. Encrypting your game traffic is not likely a viable solution for the following reasons:

  • It is complete paranoia.
  • It is going to add CPU time overhead on your server, unless you can purchase (expensive) hardware encryption modules.
  • It doesn't matter how much security you provide for your data over the wire - someone could hijack the client process and intercept messages the moment before they are encrypted and sent. This is not only a possibility but infinitely more possible as it as substantially easier to inject code compared to intercepting packets. If you are doing this for cheat prevention you are completely and utterly wasting your time.
    • In terms of password security there is unfortunately nothing you can reasonably do about a hijacked system, the client has become hostile. Blizzards WoW dongles are designed to deal with this - but I am not sure how secure that is (especially if you leave it plugged in).

Please, if you are encrypting for cheat prevention abandon it. You are going to come up short - I gave you have the information in the event that you are not. Remember that you can selectively encrypt packets by the first byte in the packet being and indicator of whether the rest is encrypted: although, once again, I would stick to HTTPS if you need to do things like credit card transactions: they are extremely infrequent and HTTPS is designed by experts - unlike something you or me designed.

All of that said, Blizzard do actually encrypt their WoW traffic. The main reason this broke is because someone, who is likely a complete amateur, decided that they would try their hand at a home-grown encryption algorithm; this panned out really well. Even if you do use industry standard algorithms there is a good chance that someone will reverse-engineer your code and simulate it - once the client enters their password there is no telling that an unsupported system is connected.

  • 2
    \$\begingroup\$ +1 for saying that encrypting data packets for cheat prevention is useless. OP: do verify everything you receive from the client, run sanity checks, double-check if the action the client requested is possible, check weapon ranges, movement speed etc. but don't waste time securing your client as it will get hacked if your game is worth it. Some MMO companies encrypt and obfuscate their clients/protocols but it's not to prevent cheating but to make it more difficult for e.g. bot creators to get good results, and even this is done by dedicated teams of experts. \$\endgroup\$
    – Gilead
    Commented Mar 14, 2012 at 22:04
  • 1
    \$\begingroup\$ A minor quibble about your third answer: just encrypting the packets may not be enough to prevent tampering, since many encryption schemes are at least somewhat malleable. To protect message integrity, you need either a MAC or an authenticated encryption mode. \$\endgroup\$ Commented Mar 14, 2012 at 23:00
  • \$\begingroup\$ +1 Thank you for a very complete answer. Looking into implementing SRP right now. What are you recommendations regarding the hash function used for passwords? MD5? How would the OTR protocol (Off the Record) be for such a use-case? would it work well for auth/crypto instead of SRP? In case I use SRP, would I need to use one of the following "authenticated encryption" modes? (OCB 2.0, Key Wrap, CCM, EAX, Encrypt-then-MAC and GCM) \$\endgroup\$ Commented Mar 15, 2012 at 6:53
  • 1
    \$\begingroup\$ @Jenko use the SHA family of algorithms (likely SHA1) - you should avoid MD5 these days. OTR is really not something you should be looking at - it is not designed to be secure/obscure (in fact its designed so that someone can more easily forge packets) it's also designed for instant messaging and not machine communication. None of those modes are needed, just use SRP: once you have a mutually negotiated symmetric key simply being able to encrypt something is guarantee enough that you are talking to the correct third party. Also, again, re-read my last two paragraphs. \$\endgroup\$ Commented Mar 15, 2012 at 8:23
  • 1
    \$\begingroup\$ Actually, I have an even better suggestion: use an existing DTLS over UDP implementation and don't try to roll your own. It'll save you time, and there are a lot of small but critical details that are easy to get wrong if you try to design your own datagram encryption layer. \$\endgroup\$ Commented Mar 15, 2012 at 12:20

I think my last comment to Jonathan's otherwise excellent answer is worth expanding into an answer of its own:

If you don't have a lot of crypto experience, you shouldn't try to design your own encryption layer if you can avoid it. If you do have a lot of crypto experience, you should know better than to design your own encryption layer if you can avoid it.

Instead, try to find an existing, standardized and well tested crypto library that does what you need. In your case, I'd recommend GnuTLS, which, according to Wikipedia, provides both TLS-SRP authentication (RFC 5054) and secure UDP communication with DTLS (RFC 6347). The former takes care of logging in, while the latter protects the secure channel thus formed from both eavesdropping and active attacks, and can even protect you from replay attacks.

  • \$\begingroup\$ I'm using TCP. This is a very different kind of game for a specific client. Similar to gambling/betting, all information that can be used to hijack the process increases the chances of unnecessary losses by the house. We need to keep the data extremely secure, because information is money in this case. \$\endgroup\$ Commented Mar 15, 2012 at 13:26
  • \$\begingroup\$ OK, if you're using TCP, then it's even easier: you can use normal TLS 1.2 instead of DTLS, which gives you more options to choose from. I'd still recommend the GnuTLS library, though. \$\endgroup\$ Commented Mar 15, 2012 at 13:32
  • \$\begingroup\$ I'll do a bit of research and see if I can refer to the TLS source code in both client and server sides, and base my protocol around what it does. Would this be strong enough? Essentially its just packet encryption with some cipher/mode, correct? \$\endgroup\$ Commented Mar 15, 2012 at 13:39
  • \$\begingroup\$ No, there's quite a bit more to the TLS protocol than that. Which is why you want to use a standard library that implements it, instead of rolling your own. \$\endgroup\$ Commented Mar 15, 2012 at 13:55

You must log in to answer this question.

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