session-desktop
session-desktop copied to clipboard
oxen-io
[Discussion] Should the encryption key of a closed group be rotated when a new member is added to the group?
Should the encryption key of a closed group be rotated when a new member is added to the group?
It's generally accepted that whenever an existing member is removed from a closed group, the group's encryption key (and potentially also the authentication key) should be rotated. This strategy prevents expelled members from scraping and decrypting future messages.
I used to believe that it wouldn't matter to allow a future member to read past history; however, not every messaging app designs their closed group this way.
My perspective changed after recognizing the benefits of rotating an encryption key (and potentially also the authentication key) of a closed group whenever a new member is added.
As a moderator of a group consisting of several hundred members focused on casual technology topics, I've observed an interesting pattern: occasionally, a long-term member Alice might discover that someone else called Bob recently invited Alice's manager Carol to join the group. Upon realizing this, Alice would selectively stop commenting on certain topics or alter her language usage. Users deem certain topics inappropriate to share with their managers, even though this is a casual group outside of their company.
From this observation, I've concluded that users would likely prefer their past messages to remain inaccessible to future members of the closed group. This preference is based on the fact that their previous discussions were conducted under the assumption that they felt comfortable sharing the content or opinion with the existing members of the group. They did not foresee that their messages might be read by future members of the group, given that they had no idea who these future members might be. If we violate this assumption, a closed group, psychologically, won't differ significantly from an open group (community). In theory, the admin could invite anyone to join the group in the future, and it would be too late for long-term members to delete their past messages if they had previously sent something they wouldn't want the unpredicted new member to see.
I don't think this is an issue with an obvious answer. I think most likely it will need an option to rotate keys or disclose the existing key (it is certainly technically feasible, though I am not sure if that is currently scheduled for inclusion in the first release of new groups).
Yeah i think we will support giving the option to rotate or not when a user is invited, however this will not be included in the first release
FWIW, in MS Teams, when you choose to invite someone to an existing conversation, it presents the option to include chat history or not so you get to make an explicit decision. I think the preselected option is to not include history, but it might just remember the last thing you selected.
Obviously MS Teams is not an end-to-end encrypted messenger, but as far as the user experience is concerned, I think it'd be good to do similar, and present an explicit choice each time, as both use cases are important. (The third option shown here, to only include history for a limited amount of time, is not important, imo.)
(Screenshot taken from here found by a quick google image search.)
For the first release, I propose that we adopt an unconditional rotation of the encryption key every time a member is added or removed. This approach, especially when accounting for race conditions, simplifies key management, as illustrated below:
Consider a group, G_t0 = {Alice, Bob, Carol}, where:
- Alice is the group creator.
- Bob is the group moderator assigned by Alice.
- Carol is a group member.
Here,
t0signifies 'time moment 0'.
Let’s say the group initially shares an encryption key ek0. Additionally, Alice has pre-generated a series of future encryption keys [ek1, ek2, ek3, ... ], signed by Alice and exclusively shared with Bob.
Almost simultaneously, Alice decides to remove Carol from the group, while Bob chooses to invite David. From Alice's perspective, she anticipates the group will become {Alice, Bob}, so she distributes ek1 to {Alice, Bob} without Carol. Conversely, from Bob's viewpoint, he expects the group to evolve into {Alice, Bob, Carol, David}, and he distributes ek1 to all four members. This will create a compound effect that Carol is not effectively removed from the group despite Alice's effort, because Carol receives an encryption key from Bob.
Once Alice and Bob receive each other's group management updates, they should agree that the final group composition is G_t2 = {Alice, Bob, David}, irrespective of the order of events. In this context, t2 represents 'time moment 2'. Subsequently, both will distribute ek2 to G_t2 = {Alice, Bob, David}, ensuring consensus and convergence to the new group configuration.
Choosing a key rotation mechanism that introduces a new key upon each membership alteration is essential for making the above design feasible. The primary responsibility is to guarantee that the number of key rotations corresponds to the size of the 'symmetric difference set' between the initial and final group states, namely the 'symmetric difference' between G_t0 and G_t2.
The concept of the symmetric difference set is defined as: A △ B = (A – B) ∪ (B – A).
For the scenario above, the symmetric difference between G_t0 and G_t2 is {Carol, David}. This set represents the aggregate member changes post the administrative actions, order insensitive, regardless of adding or removing a member. The size of this set is 2, denoting the requirement to rotate two encryption keys, independent of the sequence of group management actions.
Therefore, both admins Alice and Bob can reach a mutual agreement. Regardless of the sequence of their management tasks, the eventual group {Alice, Bob, David} should discard ek0 and ek1, and adopt ek2. Notably, this conclusion is arrived at independently by both admins without the need for synchronization, ensuring convergence. The config resolution algorithm in libsession-util is sufficient for reaching this consensus between two admins.
Comparatively, designing an algorithm that only mandates key rotation upon member removal, but not for additions, complicates the consensus algorithm significantly.
I like the idea of unconditionally rotating keys each time group membership changes :+1:
We do want to add key rotation as an option when inviting, as sometimes when you invite someone you want them to be able to read the chat history. Say for example you're planning an event and then you decide to invite more friends, then you want those friends to be able to read the earlier messages where the event was planned.
However in the interest of providing the simplest v1 implementation we are essentially going to swap out the backend of closed groups without adding too much new UI. Hence we want to leave this feature to a future closed group release.
@KeeJef It might be beneficial to release any draft design documentation, allowing community contributors to provide feedback and identify potential issues. Fixing a potential issue in design documentation is less expensive than implementing a flawed version and later having to redesign and correct the implementation. Even if the document isn't fully fleshed out or doesn't align with the current implementation, transparency can significantly empower those eager to contribute. Without it, assisting becomes considerably more challenging.
Even if there's no design documentation at all, it would be nice to acknowledge that the design is still evolving and let community contributors know that any design proposals are welcome.
@KeeJef It might be beneficial to release any draft design documentation, allowing community contributors to provide feedback and identify potential issues. Fixing a potential issue in design documentation is less expensive than implementing a flawed version and later having to redesign and correct the implementation. Even if the document isn't fully fleshed out or doesn't align with the current implementation, transparency can significantly empower those eager to contribute. Without it, assisting becomes considerably more challenging.
Even if there's no design documentation at all, it would be nice to acknowledge that the design is still evolving and let community contributors know that any design proposals are welcome.
https://github.com/oxen-io/libsession-util/issues/45#issuecomment-1680486817
@KeeJef It might be beneficial to release any draft design documentation, allowing community contributors to provide feedback and identify potential issues. Fixing a potential issue in design documentation is less expensive than implementing a flawed version and later having to redesign and correct the implementation. Even if the document isn't fully fleshed out or doesn't align with the current implementation, transparency can significantly empower those eager to contribute. Without it, assisting becomes considerably more challenging.
Even if there's no design documentation at all, it would be nice to acknowledge that the design is still evolving and let community contributors know that any design proposals are welcome.
Since the implementation of Chuck1 in the closed group, is there any plan to release the draft design documentation for Chuck1 so that community contributors can help with the review? Alternatively, is there any chance to make some of the internal project management portal public so that community contributors can read those draft designs? @KeeJef