I have found lots of encryption discussion in the forum. Basic idea is: that will not help because hacker will corrupt the client app. My question is: what if the hacker reverse-engineers the communication protocol and begins messing with the game info that clients receive, causing uses to take mistaken actions. Or even easier: if he simply changes user responce packets, causing the server to receive "attack" instead of "retreat". I cannot use SSL with UDP, can I? I have to encrypt myself. What do you think about the following schema: 1) Authenticate using TCP+SSL when session starts. 2) Give out a key valid for that session only. 3) XOR UDP packets using the key. [edited by - lisitsin on October 21, 2003 6:06:18 AM]

You really should get a book on encryption and network security.
http://williamstallings.com/Crypto3e.html


Encryption is what would protect one client from other clients. If the clients are talking to a server over the internet its not very likely that the packets would be caught though. You mostly have to worry about the clients sending false data.

The first part of your idea is fine but starting with SSL doesn''t keep you from having to worry making your protocol secure. XOR isn''t a safe way to encrypt data. You should use actual encryption like Blowfish or AES. You have to use salt with each message sent to keep messages random even when they have content that is similar. Salt is random data used with the key to generate the actual key used to encrypt the data. The random data is public and sent along with each message in encrypted form. You have to worry about timing. Another attack would be to capture another clients message and then send it later.

There are a lot of issues. You should really get a book


Corey

From your other posts recently I think you mentioned that you are working on a large client/server based game. With that assumption there are really three seperate things to worry about:

1. user privacy. login, password, credit card number etc... This data is usually exchanged only at initialization, and should be encrypted without regards to performance.

2. Players hacking the client. This only happens if you design in such a way that you allow the client to authoritatively update the server. This is a big no-no and you should always have all player actions checked and acknowledged by the server. This is easily avoided based on sound design. No encryption or security measures are needed. Just don''t trust the client.

3. Player-created monitoring, logging tools etc. In order for the game to work, the client obviously has to receive state data from the server. Send each client ONLY the data that is required. For instance, don''t send true hit point values unless the real value is displayed. Send a percentage value representing hit points instead, and show a ''health meter''. Basically, if you don''t send the information, the players can''t hack it. Sending less data also helps you support more players with reduced bandwidth costs. The problem here is that no matter what you do, there are some witty players who can and will crack whatever security you put on the data. You have a choice here: take the performance hit of encryption (not really a cost-effective option for current MMO technology), or find a simpler, faster method of obfuscating your data. Either way only the most determined players will be able to figure it out. By following the guidelines in point 2, you minimize the real advantage of a player having the data anyways.

The idea in your original post isn''t bad, although I''d suggest a little more obfuscation than a simple xor.

I personally dont feel that encryption is really worth all the effort. Encryption is only really useful when you want to keep people other than the intended receipient from reading the messages. The problem with using it in games is the intended receipient IS the person you want to keep it away from, but cant cause well, they need to get the data in order to play.

Even if you do put in encryption, the code to decrypt the packets is in the client so all that has to be done is some packet sniffing, some disassembly and a bit of trial and error and the packets can be sniffed and decrypted by an external program.

Aside from that, the decrypted information is stored in memory on the client anyway, so its accessable from there as well.

Sending stuff like passwords and credit card account information should absolutely be encrypted and probablly with a public/private key pair setup as anybody could just sniff the traffic and reverse the encryption done on the information. After all, all they have to do is go buy the game and again disassemble it and find out how the data is being encrypted in the first place.

As always just my thoughts.

-=[ Megahertz ]=-

Megahertz - I agree for the most part, that''s why you only have to make it hard enough to keep the average joe out of your data. Anyone who wants the data bad enough can get at it, so only discourage the masses and take your chances with the exceptional few capable of getting through your security (except personal data, again, which must be protected at all costs).

My current project doesn''t use any encryption in the game itself. I would use blowfish if I felt the need though. It''s small and fast. BF has the largest "bang for the buck" when considering both security and performance hit.

And our account information is handled via third party secure web services. This also helps me distribute liability in the event that someone has an issue with identity theft etc...