LOC-21 was originally going to introduce Direct Messages with the messages being E2E with a per user key.
However, I decided I wanted the basic DM functionality for version 0.0.2 and the E2E functionality is blocked by Roster support (
LOC-19) which is scheduled for 0.0.3.
So
LOC-21 implemented DM's using the room encryption key. This FR is to implement the per-user keys.
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.
LOC-21 DMs provide that base functionality.
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 and instead need to encrypt with the addressee's public key
There'll need to be a change in the server component so that it can save the public key of users in the database.
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.
Activity