Privacy

Privacy Concerns

Authentication / Identity (as of 0.2.3)

In echoplexus, a shared secret is used for authentication.

When Alice wishes to make a channel private, the following scheme might be used:

1. Alice types in /private S into her chat bar. Other more GUI-friendly mechanisms may be exposed.
2. This is sent to the server, and pbkdf2d with a good salt of random bytes. The result is stored on the server.
3. Bob wishes to join the channel. He types /password S (or at the moment, enters the password into the modal telling him that the channel is private).
4. A similar check as step 2 is performed, and if Bob's result matches what Alice originally typed, he's allowed to join the channel.

After the initial authentication, the server generates an expiring token. Any future attempts to join the private channel use this token instead of the password to eliminate the need to store secrets anywhere.

Identity happens in much the same ways as the steps above, but for obvious reasons, the secret is not shared.

What about chat messages? (implemented in 0.2.2)

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 shared secret password, different than the channel /password, is used to encrypt the chats without giving the server 1 ciphertext<->plaintext example mapping.

What about whispers? (implemented in 0.2.2)

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).

What about federation? (scheduled for 0.4.0)

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.

Even further forward

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