Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chat Signing #966

Open
chovelyoukai opened this issue Jun 26, 2024 · 2 comments
Open

Chat Signing #966

chovelyoukai opened this issue Jun 26, 2024 · 2 comments
Labels
Type: Feature Something completely new

Comments

@chovelyoukai
Copy link
Member

Suppose two users, Alice and Bob are in a lobby together. Alice wants to report to the moderators an offensive message sent by Bob so she sends the message to the moderators. But how can the moderators know that the message really was sent by Bob, and isn't a forgery meant to get him unjustly punished? To solve this problem, public-key cryptography can be used to sign messages, proving that they are authentic and untampered with. Here's how it would work in this situation ("the server" refers to the backend):

  1. Bob authenticates with the server and recieves his private key.
  2. Bob connects to a lobby with Alice, and Alice recieves his public key from the server.
  3. Bob sends an offensive message with his signature attached.
  4. Alice uses Bobs public key to verify the message is authentic, and the message is only displayed if it passes.
  5. Alice reports Bob's message by sending the message text and the signature to the server.
  6. The server verifies that that message was sent by Bob by using the known public key.
  7. Bob's message is verified to be authentic, so moderator action is taken against him.

A couple of things to note:

  1. The server controls both the public key and private key. The private key should ONLY be given to the user who is able to authenticate via Steam. The public key can be given to everyone.
  2. If Bob doesn't sign his message, then when Alice receives it she will not be able to verify it, so it won't be displayed at all.
  3. If Alice attempts to tamper with the message and report a modified message with the original signature, it will not verify because the contents of the signature are based on the message itself.

Further reading:

@chovelyoukai chovelyoukai added the Type: Feature Something completely new label Jun 26, 2024
@Gocnak
Copy link
Member

Gocnak commented Jun 26, 2024

And some of my notes:

  • The signature will likely be just a cryptographically secure hash (SHA-512 or similar) of the original message and message date signed (encrypted) with the player's private key.
  • We should automatically generate a key pair on each login, so therefore we must store every generated key pair for a user in case a report is made against an older message or they're resetting it while in a lobby saying bad things. This can also help prevent faking reports if someone somehow gets a key pair (infected machine?). We could expire the old ones after a while (couple days), if there isn't any outstanding reports for the user.
  • This key pair is ONLY visible upon authenticating as a game client via that specific endpoint. The user should not be able to easily see their private key in any circumstance for their safety. Therefore the browser should never see any details about the key pair other than when it was generated. The game client will get the actual values.

@tsa96
Copy link
Member

tsa96 commented Jul 21, 2024

@chovelyoukai Spoke about this with Nick and Slidy last night. To clarify, are the messages themselves encrypted?

The reason I ask is because I think having lobby chat work if the backend is down is essential - even if rarely happens, I don't think we should make chat dependent on a separate system it previously had no relationship with, just for the report system. If Alice can't connect to the backend, she should still be able to read Bob's message. It's not a big deal if the report system doesn't work whilst the backend is down, we should still allow players to send chat messages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature Something completely new
Projects
None yet
Development

No branches or pull requests

3 participants