Feature Request: Encryption/Decryption Support for Network Traffic

[snnaakee]

First off, thank you for all the hard work on the Riptide. It’s a great tool for low-latency, reliable networking.
I recently found Riptide and I'm amazed how robust it is and the features it has.

However, one feature that seems to be missing is encryption/decryption support for network traffic.

Proposition :

I would like to propose adding native support for encryption/decryption in Riptide. Ideally, this would allow for the encryption of outgoing data packets and the decryption of incoming ones.

Requirements :

• Support for modern encryption standards.
• Support for both symmetric and asymmetric encryption.
• Option for configurable keys (to allow for unique encryption for different connections or sessions).
• Easy-to-integrate encryption handling at both the client and server levels.
• Minimal performance overhead to ensure that Riptide remains a high-performance networking solution.

Benefits :

• Security : Encrypting network traffic protects sensitive information from potential eavesdropping and tampering.
• Cheat protection : Ensures data integrity and confidentiality, especially in multiplayer or P2P environments.
• Compliance : For projects requiring compliance with security standards, encryption is a must-have feature.

Alternative :

At the moment, developers must implement encryption/decryption manually at the application level. However, having this feature built into the Riptide library would reduce the complexity and improve ease of use for developers.

Adding this to Riptide will make it almost a completely comprehensive tool.

[tom-weiland]

I'm glad you like the project :)

I would like to propose adding native support for encryption/decryption in Riptide. Ideally, this would allow for the encryption of outgoing data packets and the decryption of incoming ones.

I am honestly not convinced that this is worth it 😅

Regular game traffic does not (and should not) contain sensitive information, and so spending CPU time encrypting & decrypting it is simply wasteful.

I'm no longer actively working on this project, but even if I was I'd be very hesitant to add encryption support to Riptide for a few reasons:

1. I'm not overly familiar with cryptography or "modern encryption standards" and I can't say I'm particularly keen for me or the library I built to bear the responsibility of properly protecting people's sensitive data. A single mistake made out of simple ignorance could have pretty severe consequences.
2. Most (if not all) traffic you send via Riptide should be non-sensitive game data, as I would argue that sensitive things like account credentials for logging in likely shouldn't even be handled by your game server.
3. I don't see why encryption would need to happen at the message level. Even if you did want to send a password via Riptide, couldn't you simply encrypt it yourself and then write the encrypted bytes to the message (and vice versa on the other end)? Perhaps my lack of encryption knowledge is already showing by asking that question 😅
   • You might then say that having some helper functions or something to encrypt things would still be good to have as part of Riptide, but Riptide is a low level messaging/game networking library, not an encryption library, and I'm not eager to change that for reason 1. Also I would think there are plenty of other/existing libraries out there that can help you encrypt your data.

Regarding the benefits you mentioned:

Security : Encrypting network traffic protects sensitive information from potential eavesdropping and tampering.

I think this is the main one that has merit, but again, your game servers arguably should not be handling sensitive information in the first place.

Cheat protection : Ensures data integrity and confidentiality, especially in multiplayer or P2P environments.

I fail to see how encryption would help protect against cheating. Cheating in games is normally done by modifying the client application (which encrypting network traffic will not protect against), not by intercepting and tampering with packets. Also if you've chosen to build a peer-to-peer or client hosted game, then you've hopefully just accepted that there will be cheating and you're okay with that because the only reliable way to prevent most cheats is to have an authoritative server calculate everything important.

Compliance : For projects requiring compliance with security standards, encryption is a must-have feature.

I'm not really sure what sort of projects you're referring to here, but Riptide is primarily built for real-time game networking.

Unfortunately even if you convince me that this is a good idea and worth adding to the library, as I mentioned I am no longer working on Riptide so I'm not sure who would implement and test an addition as important-to-get-right and (likely) large as this.

[Mryantodd]

I fail to see how encryption would help protect against cheating. Cheating in games is normally done by modifying the client application (which encrypting network traffic will not protect against), not by intercepting and tampering with packets. Also if you've chosen to build a peer-to-peer or client hosted game, then you've hopefully just accepted that there will be cheating and you're okay with that because the only reliable way to prevent most cheats is to have an authoritative server calculate everything important.

Devils advocate here on this one. Packet snooping can give anyone running the client a clear deffinition of all the packets it sends to the server if not encrypted. If you know what packets the server will accept and process then cheating could still be an issue. Its also a popular avenue for botting. I pressed w for 60 frames. I clicked this. I pressed a for 100 frames, I did that. If the server fact checks things like range then you partially can cover things. Bots can still just send input packets in the right order to automate tasks once they have enough info. So most games do still encrypt their packets for transmit even if its authoritive because detecting the packet is from an actual client is harder. See runescape history on youtube.

[tom-weiland]

If you know what packets the server will accept and process then cheating could still be an issue.

The client code already contains complete information about what packets the server will accept. Encrypting the data being sent doesn't really hide the data format when the sender has to know the format in the first place...

Its also a popular avenue for botting.

I fail to see how encrypting/securing the data being sent is particularly beneficial when all of it can be seen (and modified) in unencrypted form on the client before the encryption takes place.

Encryption is useful when you have two peers who trust each other and they want to communicate something without a third party being able to see what they're sending (like login credentials). It is far less useful when you don't trust the other peer (regular game traffic) because anything they send you is visible to them before it's encrypted, since they're the one encrypting it.

---

Even if you're right and encrypting regular game traffic is broadly beneficial, points 1 and 3 from my original reply still need to be addressed.

[snnaakee]

I understand your perspective on encryption.
I agree that in many cases, game network traffic isn’t sensitive. However, there are scenarios where certain information, like authentication data, is crucial. When you authenticate a client on an authentication server, there’s no way to encrypt the token (or any other sensitive data) that the client sends to your Riptide server later on. In clear, currently anyone can replay packets if no additional safeguards have been added by developers.

Cheating is obviously a huge concern, I won't elaborate on it further. In a perfect world, you shouldn't need to encrypt game network traffic.

Perhaps there could be a compromise, like providing a simple interface for encryption that leverages existing libraries. This way, developers who need encryption can access it without changing the core purpose of Riptide.

I don’t mind that you’re no longer working on this project. Riptide is already a powerful and reliable framework.
We could keep the feature request open for anyone to see and contribute with a pull request.

[tom-weiland]

Perhaps there could be a compromise, like providing a simple interface for encryption that leverages existing libraries.

Yeah, a step in that direction could be to add events like Sending and Handling which are invoked right before a message's bytes are sent/before the received bytes are copied into a message instance, each making the byte array accessible so you can encrypt/modify it as you like.

However if I'm not mistaken, encrypting a byte array is not guaranteed to (and in fact is likely not to) output an array of the same length which could somewhat complicate things. Perhaps a delegate method that can be optionally assigned would be better so that the new byte count can be passed back to Riptide 🤔

It'd probably also require some extra checks to ensure the sent amount of bytes remains within the safe MTU even after the array is encrypted/modified.