Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Sending and receiving UDP packets to character status need be encrypted?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 lgapontes   Members   -  Reputation: 114

Like
0Likes
Like

Posted 23 July 2014 - 02:00 PM

Hi, 
In a MMPOG, I need to send and receive actions of the players (moving map, attack, open door, etc). Today I am sending this data in UDP datagrams encrypted with AES 128-bit and checksum CRC32. The problem is that on average I spend about 150ms to send and receive a single UDP packet. It is a performance very close to what I get traveling with TCP (200ms). I suppose I'm having a very large overhead because of the encryption/decryption AES. 
 
Do you know if the games MMPOG sends UDP packets to status of players encrypted?
 
Thanks...


Sponsor:

#2 ExcessNeo   GDNet+   -  Reputation: 532

Like
1Likes
Like

Posted 23 July 2014 - 02:55 PM

You should consider a different strategy as encryption as you discovered is not the most efficient.

 

Send data unencrypted but the server needs to decide if the action the client sent fits within the rules of the game world. For example a player sending movement data, over a given time can a character cover the distance between p1 and p2, if the move is legal the server now tells other clients the character is at p2, if not the server keeps the player at p1. The aim is to not trust the client, you will also have to account for packets arriving out of order or lost.



#3 rip-off   Moderators   -  Reputation: 8532

Like
2Likes
Like

Posted 23 July 2014 - 03:15 PM


 I suppose I'm having a very large overhead because of the encryption/decryption AES. 

You should measure first, before deciding what the issue is.



#4 ApochPiQ   Moderators   -  Reputation: 16079

Like
2Likes
Like

Posted 23 July 2014 - 04:16 PM

rip-off is correct. You should profile your code. Guessing is worse than useless, it can be actively damaging - whether it's your guesses or ours.

#5 lgapontes   Members   -  Reputation: 114

Like
0Likes
Like

Posted 23 July 2014 - 06:49 PM

Thanks guys ... I'll do some more tests that measure performance of the methods of encryption and decryption and also involve in a poor performance, try to do what ExcessNeo suggested (UDP without encryption). 
 
I think similarly: now with encryption I just avoid someone else do commands going by the player, but still susceptible if a malicious player modify the client and send wrong commands to the server.
 
If I put the validation rule commands on the server, protect me against the two situations, even without encryption. 
 
Another thing I have left is to put a validation hash to the executable of the game from time to time - to avoid the client to change its executable. 
 
Thank you very much! may be force be with you ...


#6 lgapontes   Members   -  Reputation: 114

Like
0Likes
Like

Posted 23 July 2014 - 07:04 PM

To register: did the tests and the cost of encryption is very small ... 
 
...
 
Encrypt time: 0 ms 
Send package: 7efbfbb623d21a65ff3d6a4ee6d19bcea8965d59f9c41bf34d010be3c917232f4753d722c6010b86071b93b13da331674ecf1ac9142c664f3041d88c
Decrypt time: 0 ms 
Time calculed: 20140723215945558 to 20140723215945712 = 154 ms 
SEND AND RECIEVE TIME: 154 ms 
correctMessages: 81 - wrongMessages 18 
 
Encrypt time: 0 ms 
Send package: b3b0bbc937b5a9d68063effd3adb15fb268b1cf338baf8d5a599cb25b6721cdbe04ccffb3e9c483b4cc651e44eab8a32219b78da9f187e46a83de735
Decrypt time: 0 ms 
SEND AND RECIEVE TIME: 201 ms 
correctMessages: 81 - wrongMessages 19 
...
 
I will do more tests, but I'll probably keep them encrypted. 
Thank you!


#7 Charon   Members   -  Reputation: 509

Like
0Likes
Like

Posted 24 July 2014 - 03:14 AM

Since you are encrypting the packets in the client you have to include the encryption-keys in the client too.

With this you are giving a malicious and knowledgeable player everything he needs to capture, unencrypt, modify and re-encrypt the packets before they leave his computer. He just has to extract your keys from your program! (which is not that hard to do)

He doesn't even have to modify your *.exe! So while checking the checksum of the *.exe might hinder a malicious player, it won't stop him from tinkering with your program. (he could modify the program on-the-fly in-memory after the program loaded)

 

So do what the others say and discard your encryption and don't trust you clients.

(this has the added benefit that you "could" intercept the packets yourself to aid you in debugging some problems)


chaos, panic and disorder - my work here is finished


#8 samoth   Crossbones+   -  Reputation: 4937

Like
0Likes
Like

Posted 24 July 2014 - 04:05 AM

Even without measuring it is clear that AES cannot possibly be the reason for that delay. Typical AES software implementations run at speeds upwards of 150 MB/s, optimized implementations using special CPU instructions run about 4 times as fast. Thus, unless you have the most pathetic AES implementation in the universe, 150ms delay is equivalent to encrypting megabytes of data. Encrypting 120 bytes will take, as you have measured, more or less zero time (means under a microsecond, not hundreds of milliseconds).

 

Did you make sure that no application level firewall is running on either of the machines (which maybe does realtime scanning on traffic)? This is on a LAN, I suppose? Routers in between causing delay?

 

Also, can you describe how you measure that sending and receiving takes 150 or 200 milliseconds, and what it means exactly? Measuring what time it takes to send is (naively) easy, although in reality you can only measure the time it takes to push the data to the network stack. You do also display a number for receiving, though.

 

Receiving can only be measured on the other computer, but it is not meaningful to measure that. The receive will block forever as long as no packets come in, and unless the two computers are in perfect sync (which is impossible) there is no way of knowing when to start counting. Even doing this over loopback on the same computer could be troublesome due to scheduling.

 

You should measure complete round trips (and divide by two for one-way). That way, it's the same clock everywhere, and there are no synchronization issues.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS