Private (Small) Group Chat

[fryorcraken]

Preamble

Creating a new, separate issue, because:

• I see that Better group chat support (Megolm, decentralized MLS etc) is out of scope for Better support for conversational security layer guarantees for Waku base layer #97
• Data sync: Research better scalability for big group chats (a la public chats) #66 covers big group with scalability risk, which I am guessing means more work.

Problem

Platforms using Waku to build small (<12 members) secure group communication functionality do not have any recommendation or specs to follow, nor they have out-of-the-box library to use.

Requirements

We are aware of platforms needing a way to create a secure channel between several users or nodes.

ETH2 Validators

In the case of Eth2 validators wishing to share signing responsibility for a more resilient setup.

• 3 validators agree to coordinate
• During a DKG (Distributed Key Generation) they generate and split keys.
• Thanks to Shamir's Secret Sharing, only 2 out of 3 validator need to be online to construct a signature of a block
• Now, a validator being offline do not risk to be punish as long as its 2 partners are online.

In this case, the validators need to create a secure channel with several participants to proceed with the DKG.

group chat

In the context of a marketplace:

• buyer and seller can securely discuss terms of agreement
• In case of issue, moderator of the marketplace can join the chat to moderate, possibly need access to the history too.

In this context, the maximum number of group chat member is 3 (maybe 4 if a second moderator is invited?) hence scalability over the number of members does not seem necessarry.

Notes

@oskarth mentioned that 43/WAKU2-DEVICE-PAIRING could be used to setup several 1:1 channels, similarly to the current Status protocol for group chats: 7/GROUP-CHAT.

Criteria

• Define a way to deliver secure e2e encrypted channel over Waku for several participants. Does not need to be scalable
• Provide a reference implementation

[alrevuelta]

Great! Not sure I see a DKG as a m2m, since throghouth the whole process there is some human interaction. As I see it, the ceremony is syncronous, you join, monitor how many people are participating, participate with your share (adding entropy?) and when everyone has participated, its considered done and you exit, storing your share. But correct me if I'm wrong.

Regarding the suggested implementation, are we targeting a specific language?

[fryorcraken]

Great! Not sure I see a DKG as a m2m, since throghouth the whole process there is some human interaction.

Rephrased.

Regarding the suggested implementation, are we targeting a specific language?

Not sure what you mean. Nwaku is the reference implementation so it should implemented there first. Then reproduced.in go-waku and js-waku if it makes sense. Which it would for this particular protocol.

[alrevuelta]

Not sure what you mean. Nwaku is the reference implementation so it should implemented there first. Then reproduced.in go-waku and js-waku if it makes sense. Which it would for this particular protocol.

I was asking because I wasn't sure if the plan was to implement it in nwaku, or other implementation. Just to make the Criteria "Provide a reference implementation"->"Provide a reference implementation in xxx-waku".

My initial thought was js-waku since these use cases look more browser related.

[s1fr0]

The setting is very important for designing a working and then efficient protocol. Some questions we may try to answer for specific contexts are:

• How much is encryption/decryption latency important, i.e. to what extent we can use public key vs symmetric key primitives (e.g. key agreements clearly go under public key, but we need to allow key revocation? how frequently we should update encryption keys? new entries should be able to see old messages or not? etc.)
• Two parties can do DH for agreeing on a symmetric key. For 3 parties there is a protocol by Joux that does key-agreement in 1 messaging round. For n>3 parties I believe you can do agreement in n-1 messaging rounds (ultimately all users will share the same key).
  • Do we allow users to be online (at least for message retrieval/answer) while doing key exchange?
  • If not, will key-bundles be distributed? How? How much users know in advance about other parties? (their public keys, some psk, etc.)
  • We need to be able to encrypt on first sent message (implies usage of key-bundles) or we can allow a messages/key-exchange online phase?
• The symmetric encryption key has to be the same for all parties or we can allow (n 2) (=binomial) co-existent encrypted channels using different keys (1 for every pair of users)?
• Can we assume a trusted party? In that case ~2n messages would be enough for distributing a secret (it is just encrypted under a key derived from doing DH with all other n-1 parties). Note that in Shamir's SS you need a trusted dealer that correctly shares the secret (maybe other schemes could be less stricter in terms of security assumptions).

At the moment I believe that the easiest way to proceed is to mimic Status app by requiring each user to instantiate n-1 secure channels with other parties, but by using Noise handshakes/pairings (or derived schemes).

Main reason is because this was already planned in waku-org/nwaku#1066 and some work has been done already towards that direction, although de-prioritized at the moment (the issue/rfcs deal with multi-device communication rather than multi-user chats. However the requirement to keep synced all user's devices in multi-device communication can be seen as delivering a message to all parties in a group chat, hence that work can be easily adapted to address this issue).
Unfortunately the solution based on separate Noise handshakes doesn't scale very well when many parties are involved (besides the (n 2) key-agreements necessary to instantiate all the secure channels, each outbound message has to be encrypted separately within each of the open n-1 channels).

In any case, we might try to target (in parallel to the multi-device communication development) specific contexts/scenarios with a tailored design: in such case, I believe that structuring answers to the above questions + identifying necessary security guarantees we want to provide will help in making the right protocol design choices.

[fryorcraken]

I was asking because I wasn't sure if the plan was to implement it in nwaku, or other implementation. Just to make the Criteria "Provide a reference implementation"->"Provide a reference implementation in xxx-waku".

nwaku is the reference client for Waku so I expect the reference implementation to be in nwaku by default. But that's an expectation I have outside of this issue.

But it does not really matter. A reference implementation need to happen and then Waku Product can take over and reproduce the implementation in the other codebases and then harden it once we get feedback from dogfooding/users.

[fryorcraken]

The setting is very important for designing a working and then efficient protocol.

Let's review this issue and answer the questions once we have more specific requirements from a platform that is interested.

Especially if waku-org/nwaku#1066 does not fit the needs.