Oddbean new post about | logout
 6/n

Keychat is on the verge of launching an updated model known as the upgraded sender key group, expected to be released this week and will be termed "medium group" in the new version.

Unlike the sender key group, where each member communicates their initial key, k0, to all other members, the upgraded sender key group has members sharing a common group key, k, akin to the mechanism used in the shared key group. Each member derives their personal k0 using a Diffie-Hellman calculation with their ID and the shared group key. They then encrypt their first message with k1 = kdf(k0), and subsequent messages with sequentially derived keys, like k2 = kdf(k1).

Other members decrypt incoming messages by sequentially deriving keys from the sender's k0. After use, these encryption keys are discarded. Thus, the upgraded sender key group maintains forward secrecy, meeting the third requirement, but does not offer backward secrecy, failing to meet the fourth requirement.

Efficiently updating the group key, k, would enable the group to meet the fourth requirement concerning backward secrecy.

If a member who has disclosed confidential chat information needs to be removed, a new group formation is necessary. The group admin must then individually share the new encryption key, k, with each member, where N represents the number of members.

This upgraded approach reduces the need for member updates from N*N individual chats in the sender key group to just N chats in the upgraded sender key group, significantly enhancing efficiency and maintaining forward secrecy.

Alternatively, this model could be described as an upgraded shared key group because, compared to the original shared key group, it offers forward secrecy and simplifies member updates to only N individual chats.

Yet, the requirement for N individual chats to update members remains a significant challenge for larger groups. 
 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. https://image.nostr.build/da70b8c9dea1a8954e6bca4e9d8f60b74df87555e1944810e73c61c620b28494.jpg  
 Whats the TLDR on this and how do users benefit from it? 
 The MLS protocol provides an efficient end-to-end encryption solution for large-scale group chats. 
 Ah I see now ty