Okay yes I am aware that this question probably has been answered a million times over, an I’ll more then likely be trolled but I’ll ask anyway(the persistent never stop)

I am working on a small game with network protocol, I am still new to networking, my question is do I need to encrypt each an every packet? For example I am aware of these things so far

passwords are hashed via SHA-256 salted an stored in the database

any sensitive information (real player info) is similarly treated.

but now to the part I’m considering should I encrypt player position, chat, basic game mechanics transmissions? The average hacker can just reverse all the protocols in my client anyway the server won’t accept any fake/phony packets. I don’t want to make it to easy, but I also feel it’s a over kill as well. A friend of mine said I need to transmit all the data with a AES256 encryption. I think that’s a bit of a over kill, any information would be helpful, articles etc.

Thank you in advanced have a wonderful day!

@undefined game mechanics are mostly in place packet handling is done as well.

a light breeze said:

Yes, you do. All data you send, no exceptions, but especially chat. Because people can and do have private conversations over in-game chat. People can and do mention their real life identities in in-game chat, with the expectation that only recipient (and possibly the administrators and moderators) have access to that information. Without encryption, you're broadcasting that information to every creep with a packet listener who sits between the server and the player. Don't do that.

Never thought about it that way to be honest. thanks for your insight ?

For persistent connections, it makes a lot of sense to use TLS. If you use secure web sockets, or grpc, they tunnel over HTTP 2 which in turn tunnel over TLS so it's already encrypted.

For the real-time game data updates, you have the choice of sending it over TLS (which has all the TCP head-of-line blocking problems,) using DTLS (which has significant per-packet and protocol overhead,) or living with “encryption lite.” For example, if you have a secure login channel, you can generate a random encryption key for the session and return to the client; each UDP packet could then start with 16 bytes of random nonce (which needs to be new/random for each packet) and then the payload data encrypted with the given key and the included nonce. This gives “lite” protection, but doesn't add all the assurances of DTLS (session key re-keying, algorithm flexibility, authentication per packet, replay protection, forward secrecy, and so forth.)

For a game, this may be sufficient, entirely dependent on what your attack model is. If you're small, and care about content privacy, and don't have much experience, you probably should just go with TLS (or one of the higher level protocols) for all “chat” and “login” type things, and DTLS for all the UDP / state update stuff, even though you will suffer from some performance problems with DTLS.

@undefined Thanks for the information, the biggest hurtle I’ve found so far is finding a example of TLS being used with c++ an TCP. Seems finding documentation is nonexistent or I am just looking in the wrong places.

hplus0603 said:
TLS (which has all the TCP head-of-line blocking problems,) using DTLS (which has significant per-packet and protocol overhead)

Has this equation changed at all with the introduction of HTTP/3 (i.e. QUIC)? Seems like their multiple streams allow one to work around head-of-line blocking, and TLS 1.3 should on the face of it have lower overhead than the older DTLS variants.