Removing someone from an encrypted group should stop them receiving the secrets needed for future protected messages. Changing the member list alone does not achieve that if the remaining senders keep using key material the former member already knows.
The transition is also not instantaneous across an unreliable network. Secure group design must define which membership state a message belongs to and what a sender does before it has processed a removal.
Past messages and future messages are different problems
A former member may retain messages, files and keys received while they were authorized. Removal cannot make that person forget the history or erase their screenshots.
The achievable goal is to exclude them from new cryptographic state after the removal takes effect. Similarly, adding someone raises a separate question: whether they receive access to old history. Products and protocols use terminology such as forward secrecy in different contexts, so a plain description of the intended access rule is often clearer than an ambiguous label.
Why sender-key groups need fresh state
In a sender-key design, each participant can encrypt ordinary group messages with a chain shared with the permitted recipients. This can avoid encrypting the full content separately for every recipient on each send.
After a removal, a former member may still possess the old chain. Remaining senders therefore need replacement state that is not distributed to the excluded member, and clients need an agreed membership context for using it. Rotation must cover the relevant senders and devices; changing one server-side flag is not enough.
The exact protocol matters. MLS, specified in RFC 9420, handles removal through a committed epoch change that supplies new entropy to the remaining members. This is an example of a defined state transition, not a claim that Livara implements MLS.
What Livara documents for LGS1
Livara's security page describes one signed sender chain per sender, with sender keys distributed through pairwise LVR1 sessions. It says fresh sender keys are created and distributed when membership changes.
That supports a claim about the published rekeying design. It does not establish a measured “instant revocation” time or prove that every race, offline-device scenario and retry is handled correctly. Those require implementation analysis and testing.
Server-side membership controls and cryptographic exclusion also have different jobs. The service can deny delivery or access, while encryption should prevent an excluded party with a copy of later ciphertext from opening it without the new secrets.
A useful removal test plan
For an authorized test group, check these scenarios with non-sensitive messages:
| Scenario | Expected question to resolve |
|---|---|
| Member removed while everyone is online | Which message is the first under the new membership state? |
| A remaining sender is offline | Must it refresh membership and keys before sending again? |
| Removed member reconnects later | Can it obtain new sender-key distributions or only old authorized content? |
| Several members change at once | Do all remaining devices converge on the same state? |
| An old message is retried | Is its original epoch preserved rather than mislabeled as new content? |
A UI-only test can confirm visible behavior, but it cannot alone prove cryptographic exclusion. A rigorous assessment must inspect what keys and ciphertext an excluded test device can obtain.
What administrators should remember
Remove unnecessary participants, review remaining membership and avoid sending new sensitive material until the application has processed the change. If a current participant deliberately forwards content, group rekeying cannot prevent that disclosure.
For high-sensitivity use, ask the provider for its removal semantics, device-revocation behavior and test evidence. The important promise is a well-defined boundary for future messages, not an unsupported claim that a removal button destroys every past copy.
