E2EE Design Plan

(#1200) Feature Open: Planned privacy

Thread

Comment by @Sir-Walrus
RexSystem 1 vote originally by @Sir-Walrus on GitHub 1 reply
When a user reports a message, the client has to send the message it has decrypted to the instance admins. The problem with this is that it opens the door for a malicious client or user to report fake messages to the instance admin. To prevent that, we can enforce that the official client needs to cryptographically sign every message they send before encrypting it
That sounds quite complicated, and also likely vulnerable to context switching attacks (for example moving "so beautiful 💥💥" from a convo about new years fireworks to a convo about 9/11). (Such attacks can be prevented, but only by adding even more complexity.) Instead, I propose a slightly different solution: When a user reports a message, the client sends the message key to the instance admin. (But I do agree with client signing the ciphertext, and server verifying that signature.)
Comment by Speykious
Speykious 1 vote originally by @Speykious on GitHub OP
the client sends the message key to the instance admin.
From my understanding, that runs the risk of exposing other messages in the channel, due to next keys being generated based on the previous ones. Though it's been a while since I looked at this stuff, so I don't exactly remember how good the post-compromise security is, so I'll have to check. That being said, message signing itself might be a complicated piece of math, but choosing what we cryptographically sign isn't. Choosing which metadata gets signed along the message is just a matter of changing the content that gets signed, nothing more. Additionally, message signing is already a crucial part of Polyproto, which is going to be used for Fluxer's federation.