7/n The MLS (Messaging Layer Security) group's central feature is its efficiency in updating both group members and the shared root key, reducing the number of necessary communications from N individual chats down to log2(N). Consider the MLS group as an evolution of the upgraded sender key group, with a similar mechanism for deriving encryption keys from a root key at the top of a hierarchy. Imagine a scenario where a group member, A, believes their key has been compromised and needs an update. This would trigger an update of the root key. But the challenge is how A informs the rest of the group about this change. In an upgraded sender key group, A would have to individually communicate with every other member, resulting in N-1 private messages. The MLS group, however, is structured around a key tree. The leaves of this tree represent the group members—A through H—with the root key at the very top. A distinctive feature of this structure is that each child node has access to its parent node’s private key. For instance, A can update E, F, G, and H by sending a single message encrypted with the public key of node 1. Since these members are the children of node 1 and possess its private key, they can decrypt the message. Similarly, A can inform C and D by encrypting a message with the public key of node 2, to which they, being children of node 2, have the private key and can thus decrypt. A directly communicates the update to B with one personal message. In total, A needs to send log2(8) = 3 messages to update the entire group. If the group size were as large as 1024 members, A would only need to send log2(1024) = 10 messages. This efficient mechanism of updating members and the root key grants the MLS group the backward secrecy feature, an enhancement over capabilities found in the upgraded sender key group. We are studying the MLS protocol and will implement the MLS group feature in Keychat later.

I think its also important to note the human aspect of it all. The saying: "You can only keep a secret between two people, and even the one is safer." Is true even here. So the larger the group the easier it is to sneak in as a third party eavesdropper. Even with best security encryption the screenshot leakage will increase per person in the group as well.

Right. Encryption protocols can only ensure security from a technical perspective; they fundamentally cannot address the issue of malicious actors within the group.

I disagree with this chart. I think 1, 2, and 6 are all on the same level when properly implemented.

However, we need to consider that in large group chats, such as those with 1000 participants, updating the key tree results in 10 updates per message. Therefore, achieving the same frequency of updates as in one-on-one or small group chats is quite challenging.

After a critical size the chance of a malicious actor in the group becomes the weakpoint rather than the cryptography. This MLS is very cool however and will be very nice to see implemented. It will be the strong point.

Threads on here leave a little to be desired. This is awesome content. You should have instructional lessons on your website with this information, then just post each page as a note. It’s easier to navigate, imo.

shout out to @Keychat for their top notch content. (even though the scores can be debated)

#optionplus

tbh I agree with the plot. Not because of cryptography but the security level of any larger group will be lower than a small group ... because numbers.

Nosotros.app (desktop) is your friend for threads.

That's true, but pretty hard to factor human behaviour in to any kind of model. For example a large group on an incredibly boring topic will be less prone to social engineering than a small group on a scandalous topic.