LOC-21: Direct Messaging support



Issue Information

Issue Type: New Feature
 
Priority: Major
Status: Closed

Reported By:
Ben Tasker
Assigned To:
Ben Tasker
Project: LocalChat (LOC)
Resolution: Done (2018-05-20 09:33:41)
Target version: V0.0.2,
Components: Client , Server , Encryption ,

Created: 2018-05-15 09:25:20
Time Spent Working


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 Links

Toggle State Changes

Activity


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.
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.
Repo: LocalChat
Host:Rimmer

commit 299c799474233841e03f4c62dd42520942d5bbae
Author: B Tasker <github@<Domain Hidden>>
Date: Fri May 18 09:26:50 2018 +0100

Commit Message: Partial implementation for LOC-21

Users within the same room can now send each other direct messages

/msg [username] [msg]

However, the message is currently encrypted with the room key. Other users won't (and shouldn't) receive DMs not addressed to them back from pollMsg, and old DMs will be cleared at the same interval as room-wide messages.

Messages really should be encrypted with a key that's specific to the addressed user, but that can't be implemented until Roster support has been added.

client/LocalChatClient.py | 62 +++++++++++++++++++++++++++++++++++++++++++++
server/LocalChat.py | 56 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 116 insertions(+), 2 deletions(-)


View Commit | View Changes
As the basic functionality has been put in place under commits for V0.0.2, I'll move this into v0.0.2 and raise a new FR for doing the per-user encryption under v0.0.3 (as it's blocked by Roster support which won't be in .2) - LOC-25
btasker added 'V0.0.2' to Fix Version
btasker removed 'V0.0.3' from Fix Version
btasker changed status from 'Open' to 'Resolved'
btasker added 'Done' to resolution
btasker changed status from 'Resolved' to 'Closed'
Repo: LocalChat
Host:Rimmer

commit 08398d597d157daa355b7effccdaa17819355328
Author: B Tasker <github@<Domain Hidden>>
Date: Sun May 20 23:37:46 2018 +0100

Commit Message: Added test for LOC-21 Direct Messaging support

It should continue to work in v0.0.3 when E2E for DMs is changed as pollForMessage should transparently handle the decryption

tests/run_tests.py | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 52 insertions(+), 1 deletions(-)


View Commit | View Changes