5/n
The "sender key group" is the protocol currently employed by the Signal app. Previously, Signal utilized the "pairwise group" model. We argue that Signal should have retained the pairwise group alongside introducing the sender key group, offering users a choice between the two.
In a sender key group, new members communicate their initial encryption key, k0, to the existing members. They use this key to encrypt their first message with k1 = kdf(k0), with subsequent messages encrypted using a succession of keys derived from the previous one, k2 = kdf(k1), and so on, where kdf is a one-way key derivation function. Other members decrypt messages by sequentially deriving keys from k0. These encryption keys are deleted after use, ensuring forward secrecy (meeting requirement 3), but failing to ensure backward secrecy (failing requirement 4).
Removing a member who has compromised the group's secrecy effectively requires forming a new group. This necessitates each remaining member conducting N*N one-on-one chats to share their new k0, where N is the total number of members in the new group.
This is the primary challenge of the sender key group: inefficiently updating membership. Both the "upgraded sender key group" and the "MLS group" seek to address this by enabling efficient membership updates. Achieving efficient updates of k0 would fulfill requirement 4, providing backward secrecy.
Keychat bypassed the sender key group in favor of developing the upgraded sender key group model.
keychat / Keychat
npub1h0…srwx8
2024-08-26 13:32:58
in reply to nevent1q…k7yj
Author Public Key
npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8Published at
2024-08-26 13:32:58Event JSON
{
"id": "72e0d9c85c419b9603dba3dcbb3a15a00114192312c7a1c545e445d95df10f58",
"pubkey": "bbf923aa9246065f88c40c7d9bf61cccc0ff3fcff065a8cb2ff4cfbb62088f1e",
"created_at": 1724671978,
"kind": 1,
"tags": [
[
"e",
"0735749552e1f30e0d6babdbcd122b266279320b2068758a072ecfb44a48eb83",
"",
"root"
],
[
"e",
"0ac42a547c50b95c9c2827b09675ec8e67e35d173067be0afe77371d09ec9f08",
"",
"reply"
]
],
"content": "5/n\n\nThe \"sender key group\" is the protocol currently employed by the Signal app. Previously, Signal utilized the \"pairwise group\" model. We argue that Signal should have retained the pairwise group alongside introducing the sender key group, offering users a choice between the two.\n\nIn a sender key group, new members communicate their initial encryption key, k0, to the existing members. They use this key to encrypt their first message with k1 = kdf(k0), with subsequent messages encrypted using a succession of keys derived from the previous one, k2 = kdf(k1), and so on, where kdf is a one-way key derivation function. Other members decrypt messages by sequentially deriving keys from k0. These encryption keys are deleted after use, ensuring forward secrecy (meeting requirement 3), but failing to ensure backward secrecy (failing requirement 4).\n\nRemoving a member who has compromised the group's secrecy effectively requires forming a new group. This necessitates each remaining member conducting N*N one-on-one chats to share their new k0, where N is the total number of members in the new group.\n\nThis is the primary challenge of the sender key group: inefficiently updating membership. Both the \"upgraded sender key group\" and the \"MLS group\" seek to address this by enabling efficient membership updates. Achieving efficient updates of k0 would fulfill requirement 4, providing backward secrecy.\n\nKeychat bypassed the sender key group in favor of developing the upgraded sender key group model.",
"sig": "6b3da6812d1e1fe341007ae33e421ef71f2a1d5154779ba4a36cc301e818abb8e2f928149c049f6b6dafa271db57c3e783a7871f92a870900b482add8e3aacae"
}