V2 - Add Private Group chat type

[bryantkelley]

In v2 there should be three types of chats: public channels, private groups, and direct messages.

• Public Channels: The existing hash channels. Message senders can be spoofed but every message is encrypted and decrypted using the channel key pair. The existing Public channel should be replaced by the #public channel. This is beneficial to keep as anyone can send and see any message sent.
• Private Groups: This is the new channel type. Messages are encrypted using the sender's private key and the channel public key and decrypted using the channel private key and the sender's public key. This type of message would have the additional character count of DMs and be resistant to display name spoofing because every message has a verified sender identified by their public key used to decrypt the message.
• Direct Messages: Existing contact and room server messages. These are encrypted using the sender's private key and the receiver's public key and decrypted using the sender's public key and receiver's private key.

[wlockwood]

How is a private group distinct from private channels?

[bryantkelley]

The existing "private" channels are susceptible to spoofing as the sender is just part of the message without any verification. The new private groups do not have this spoofing problem because every message is encrypted with the sender's private key and thus verifiably from who it says it's from. The current Public channel is a "private" channel with a widely known key and you can just pretend to be anyone else with no way to stop them while this is not possible in the new private groups.

[wlockwood]

Signing messages would accomplish the same thing (establish authenticity) without requiring that you already have somebody in your contact list to decrypt their messages. Why not do that instead?

[bryantkelley]

Signing messages would increase the packet size, would it not? Simply encrypting it accomplishes the same goal without using more space

[wlockwood]

It doesn't use more space, but you're making potentially a large tradeoff in that you could be in a channel with someone and not be able to talk to them, just sending and receiving encrypted payloads back and forth that neither of you can read.

[everett1992]

I'd like to see revocability, a way to ban someone that's stronger than blocking their user name. Today if a private channel key is shared with someone the group doesn't want to participate the only option is for the remaining group members to rotate keys to a new channel.

I think room servers could solve this, if rooms supported ACLs instead of one shared admin/guest password. The room sever could also solve impersonation, if they check the display name against the signature / decrypt key. I've heard complaints about room servers tho.

[bryantkelley]

Room servers use the first 4 bytes of the sender's pub key as the sender name and then the app sorts through your contacts for a matching key. This can still be impersonated currently but with ACL-only mode it would be somewhat improved. I would also like to see key rotation but that's beyond the scope of this suggestion.

[446564]

This is an excellent idea and should be fairly straight forward.

[cparen]

Private Groups: This is the new channel type. Messages are encrypted using the sender's private key and the channel public key and decrypted using the channel private key and the sender's public key.

Which asym scheme are you proposing for this encryption? If ECDH based (e.g. x25519 is how DMs are encrypted right now), every party of the chat is able to spoof any other member of the chat, since they can all compute the same symetric key. It's possible I missed something, but it seems this would add complexity (having to track adverts of the users in the chat in order to read it) without any improved protection against impersonation.