########################################################################################## LOC-21: Direct Messaging support ########################################################################################## Issue Type: New Feature ----------------------------------------------------------------------------------------- Issue Information ==================== Priority: Major Status: Closed Resolution: Done (2018-05-20 09:33:41) Project: LocalChat (LOC) Reported By: btasker Assigned To: btasker Components: - Client - Server - Encryption Targeted for fix in version: - V0.0.2 Time Estimate: 0 minutes Time Logged: 0 minutes ----------------------------------------------------------------------------------------- Issue Description ================== 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). ----------------------------------------------------------------------------------------- Issue Relations ================ - relates to LOC-25: Encrypt direct messages with a per-user key ----------------------------------------------------------------------------------------- Activity ========== ----------------------------------------------------------------------------------------- 2018-05-15 09:29:38 btasker ----------------------------------------------------------------------------------------- One line of thinking for the E2E encryption (though this is currently blocked by Roster support - LOC-19) would be this: - 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 /msg command, the message is encrypted using the recipients public key and sent on it's way. - 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 pollMsg responses which would indicate whether it's a direct address or not, so a flag would need adding to that too (though that's probably inavoidable). 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 btasker ----------------------------------------------------------------------------------------- I decided I wanted this functionality sooner, so I've implemented basic support. Currently the E2E just uses the room key though, so that will need improving upon once LOC-19 has been completed. ----------------------------------------------------------------------------------------- 2018-05-18 09:30:37 git ----------------------------------------------------------------------------------------- -- BEGIN QUOTE -- Repo: LocalChat Host:Rimmer commit 299c799474233841e03f4c62dd42520942d5bbae Author: B Tasker