I'd like to add the ability for users within a room to send one-another direct messages (i.e. rather than broadcasting to the room).
As a scenario - Alice, Bob and Chuck are in a room. Alice is becoming concerned that Chuck may be malicious and wants to quietly communicate a warning to Bob.
We don't really want them to have to fall back to some other established channel (and if there isn't one, how does Alice get Bob's attention without making Chuck suspicious), so Alice needs the ability to directly communicate with Bob in a way that Chuck cannot see.
This FR is to implement the means of doing so.
Direct communications should be E2E encrypted.
When Chuck runs
pollMsg he shouldn't get a list of the messages between Alice and Bob. However, in case that information leaks (somehow) it is essential that he not be able to decrypt it - so we clearly cannot re-use the room encryption key (I've an idea on this I'll add to the comments shortly).
There'll need to be a change in the server component so that it can save (and use) the addressee of a message in the messages table.
It does mean a little more metadata in memory (i.e. who's communicating with who), but it's probably the only way around it. If we don't record that, we'd need to rely on the fact Chuck can't decrypt the messages, but he'd still be able to see that Alice and Bob seem to be communicating without him.
The default addresses will obviously need to be the room.
pollMsg should return messages as it does now, but exclude any where the addressee is not either the room or the polling user.
The client will need adjusting to accept a new command (or other format) for direct messages. The format of that is to be decided, but it probably makes sense to stick with the IRC format and use
/msg
EDIT:
As the basic DM functionality was implemented for V0.0.2, this issue no longer deals with the per-user encryption (
LOC-25).
Activity
2018-05-15 09:29:38
- At startup the client generates a new PGP keypair.
- When joining the room it submits it's public key, which is recorded somewhere on the server (dedicated table, or a new field I guess)
- When a client polls for the updated roster, the response will include a public key for each of the users
- When a user runs a
- When the client receives a message addressed to them, they use their private key instead of the room key to decrypt.
Currently, there isn't anything in
My concern with this is the size of the keys - they have to live in memory on the server, and with a high user count it might start to become quite unwieldy. So we may have to limit keysize or put some other mitigation in place.
2018-05-18 09:29:39
2018-05-18 09:30:37
View Commit | View Changes
2018-05-19 13:16:37
2018-05-19 13:26:48
2018-05-19 13:26:48
2018-05-20 09:33:41
2018-05-20 09:33:41
2018-05-20 09:33:48
2018-05-20 23:40:38
View Commit | View Changes