移除群组成员：密钥更新与 LGS1 安全

从加密群组中移除某人，应使其无法再获得未来受保护消息所需的秘密。如果其余发送者继续使用前成员已知的密钥材料，仅仅改变成员名单并不能做到这一点。

在不可靠的网络中，这种转换也不会在各处瞬间完成。安全的群组设计必须定义一条消息属于哪个成员状态，以及发送者尚未处理移除事件时应如何行动。

历史消息和未来消息是不同的问题

前成员可能保留其获得授权期间收到的消息、文件和密钥。移除成员无法让对方忘记历史，也无法擦除其截图。

可实现的目标是使其无法访问移除生效后的新密码学状态。类似地，添加成员又带来一个独立问题：新成员是否可以访问旧历史。产品和协议在不同语境中使用前向保密等术语，因此，用直白语言描述预期的访问规则，往往比含糊的标签更清楚。

在发送者密钥设计中，每位参与者可以用与获准接收者共享的密钥链加密普通群组消息。这样可以避免每次发送时为每个接收者分别加密完整内容。

移除后，前成员可能仍持有旧密钥链。因此，其余发送者需要不会分发给被排除成员的替代状态，客户端也需要就使用该状态的成员上下文达成一致。轮换必须覆盖相关发送者和设备；改变一个服务器端标记并不够。

具体协议很重要。RFC 9420 规定的 MLS通过已提交的纪元变更处理移除，为剩余成员提供新熵。这是一个明确定义的状态转换示例，并非声称 Livara 实现了 MLS。

Livara 的安全页面描述了每个发送者拥有一条签名发送者链，发送者密钥通过成对的 LVR1 会话分发。页面称，成员变更时会创建并分发新的发送者密钥。

这支持的是关于已公开的密钥更新设计的主张。它并未确立经过测量的“即时撤销”时间，也不能证明每种竞态、离线设备场景和重试都得到正确处理。这些需要实现分析和测试。

服务器端成员控制和密码学排除也承担不同职责。服务可以拒绝投递或访问，而加密应确保被排除方即使获得后续密文的副本，在没有新秘密的情况下也无法解开。

在获得授权的测试群组中，使用非敏感消息检查以下场景：

场景	应解决的问题
所有人在线时移除成员	哪条消息是新成员状态下的第一条消息？
一名剩余发送者离线	其再次发送前是否必须刷新成员信息和密钥？
被移除成员稍后重新连接	其能取得新的发送者密钥分发，还是只能获取之前获准的内容？
多名成员同时变更	所有剩余设备是否收敛到同一状态？
重试发送一条旧消息	是否保留原始纪元，而不是将其误标为新内容？

仅测试界面可以确认可见行为，但单凭它无法证明密码学排除。严谨的评估必须检查被排除的测试设备可以取得哪些密钥和密文。

移除不必要的参与者，审查剩余成员，并在应用处理完变更之前避免发送新的敏感材料。如果当前参与者故意转发内容，群组密钥更新无法阻止这种披露。

对于高度敏感的用途，请向提供方索取移除的确切语义、设备撤销行为和测试证据。重要的承诺是为未来消息设定清晰的边界，而不是无依据地声称移除按钮能销毁过去的每一份副本。