You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Packets should be encrypted using symmetric encryption for privacy with reasonable speed. The password/key for the symmetric encryption is provided using an asymmetric encryption like RSA. This process is called envelope encryption.
How to implement
Each server should generate a unique asymmetric private/public key pair (per save file?).
The server announces only the public key when a client joins.
The client will then generate a unique password that should be used for all packet encryption going forward, and encrypt it using the public key from server. Then the client sends the RSA encrypted symmetric encryption password to the server.
A confirmation packet is sent to verify that the symmetric encryption is understood by both client and server using the client-side generated password.
If a client rejoins, the steps are repeated as-is. The client does not need to remember the public key since it might be changed in the future by server.
Further improvements and side notes
We can use the client generated password as authentication to the server (if it is remembered by server) instead of player name as is currently the case. But it's probably better to separate encryption from authentication and provide a new unique string to the server on join as authentication token.
The text was updated successfully, but these errors were encountered:
On Steam we can get an ID that is unique to each steam account that we can use, while on Epic Games... I believe there is a similar method. BUT Microsoft Store does not have this feature, Discord SDK might however
Describe the issue
Packets should be encrypted using symmetric encryption for privacy with reasonable speed. The password/key for the symmetric encryption is provided using an asymmetric encryption like RSA. This process is called envelope encryption.
How to implement
If a client rejoins, the steps are repeated as-is. The client does not need to remember the public key since it might be changed in the future by server.
Further improvements and side notes
The text was updated successfully, but these errors were encountered: