-
Notifications
You must be signed in to change notification settings - Fork 0
Privacy
In echoplexus 0.2.1, private channels rely on the knowledge of a shared secret amongst the visitors to the channel. This secret is then transmitted, run through pbkdf2, and the resulting derived key is compared with value stored in redis. So, we have the unfortunate case where the shared key is sent over the wire (although never stored permanently). The channels are only private insofar as the authentication required this shared secret. This leaves the server log incredibly vulnerable, and this must be improved.
Going forward, for the simplest implementation of private channels, symmetric key crypto should be used. Users should confer through some side-channel to share this secret, hereafter referred to as S.
When Alice wishes to make a channel private, the following scheme might be used:
-
Alicetypes in/private Sinto her chat bar. Other more GUI-friendly mechanisms may be exposed. - The client takes a good source of random bytes (call it
P), encrypts it usingS, resulting in ciphertextC.Alicethen sendsCandPto the server, and the server stores it indefinitely. The channel is marked private, and no secret was shared with the server. - When
Bobattempts to join the channel, the server notifies him that the channel is private. It provides him with a challenge: can you decryptCand give meP? IfBobknowsS, then he can do that.Bobisn't ever broadcast to until he's proven he knows the secret.
This accomplishes a fairly difficult challenge for basic authentication.
256-bit AES will be used, along with a shared secret. If the user toggles on encryption, then ideally everything they do from there out should be encrypted. While it's fine and good to have a good authentication scheme, it's better if the server never knows any sensitive data (or at least, parts of it). Thus, another password, different than the authentication /password, is used to encrypt the chats without giving the server 1 ciphertext<->plaintext example mapping.
Whispers are performed partially by the client -- before sending, the client designates to whom the whisper is intended to be received by (in ciphertext) as well as the whisper body (in ciphertext). The server in question can then attempt to send the whisper to the user who's cipernick matches the target, so nothing needs to change immediately in terms of routing.
However, this cannot be considered a secure whisper, because a server admin who is also in possession of S would be able to decode messages meant for other users if he were nefarious and logged the messages as they appeared. In this case, it may be nice to negotiate another set of keys amongst the two whispering for an encrypted channel that was robust against nick collisions and interlopers (PGP/GPG as described in Federation Problems & Solutions).
If other servers were to track the private status of channels, the worst they could do is alter either C or P, which would tip off the joiner that something is up. But, we cannot guarantee other servers will reliably store C and P. So perhaps, the private status of a particular channel will cause it to become impossible to partake in federation and become a detached island. It seems like an acceptable compromise to need to specify the host echoplexus along with the channel name, when attempting to join a private channel.
Multi-party DH and key re-negotiation on /join and /part for highly secure and throwaway channels - probably not at all feasible to support any kind of chatlog pulling for such a scheme due to the high volume of keys / problems syncing the keys across browsers
<sarnold> qq99: you could just DH between (server, client), and have server re-encrypt all messages to all the other keys... : this might get us some level of easy OTR without needing to use the possibly more complicated/frail multi-party DH, as long as we trust the server