Hey,

To your original question, not very. Unless you're concerned about people trying to figure out ways around your server checks. But if you verify everything on the server [including stuff like shouts only going to characters in the player's vicinity] then it isn't so much of a problem.

That said, it's always fun to just use a random XOR hash. Get yourself synchronised pseudorandom number generators and just XOR every packet before sending, and XOR every packet again at reception [with a newly generated pseudorandom number]. So long as your random number generator can't be hacked [ie a fast CSPRNG like a mersenne twister], you've got pretty secure [and lightweight] protection sitting around there.

But still, encryption should be something that you add toward the end, getting everything working first is a much better use of time. It should also be a pretty trivial thing to add in the encryption later. That is if you find it nessecary to encrypt in the end.

But I'm no expert, particularly at network programming. MOG programming doubly so.

Oh, but at the very least, pipe everything into and out of the one system for the network connections. That way, you can actually add encryption relatively easily.

--CJM

Quote:

Original post by Anonymous Poster But you could at least make it harder.

I'm not a big believer in "raising the bar". Especially for something like a game. This isn't somebodies bank account we're talking about here.

I'm assuming that you're mostly talking about trying to prevent bots and cheating rather than third-party snooping.

There are so many ways to attack the client that encryption of the wire protocol doesn't really gain you anything. You can drive the client using simulated input. You can even drive the keyboard mechanically. You can snoop the process memory. You can no-op the security checks. You can insert wedges in the code to call out to your own code. You can replace the system dlls with ones of your own. You can reverse-engineer the encryption protocol (hand-rolled ones by amatuers are notoriously easy to break) etc, etc, etc. And all of these are trivial to do while preventing them is hard.

And my experience is that the more obstacles you put in the harder it is for your developers to do thier day-to-day work. The only real difference between a developer trying to crack a tough bug and a hacker trying to attack your client is thier ultimate intent.

There is also a strong tendency in managment, especially non-technical management, to assume that "raising the bar" will "fix" security problems when all it really does is mitigate them for a (probably short) period of time.

Actually, AES wouldn't be too bad for a typical MMO -- the most you can realistically send to each client is around 20 kB/s (or even 4 kB/s if you target modems). Encrypting and decrypting that on a client is not a problem (though it might be on the server, if you have 1000s of connections to a single machine). There are also very strong, effective, simple cryptos like XTea (my current favorite) that reduce the CPU load notably.

However, as others have so eloquently said: even if it has a very small cost, that's pretty much effort thrown into a dark pit of inevitable futility. Might as well not pay it at all when it comes to encryption -- just make sure you get authentication right!