keychat on Nostr: nostr:note1guzracdd3rfyussrfxjt63h3seela9a0jyzx5hd7gjmzhxsx7efs57mq8y
quoting note1guz…mq8y7/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.