密码敏捷性是指在保持明确安全约定的前提下，将协议从一种密码套件迁移到另一种的能力。在即时通信中，这不只是增加一个新算法名称。旧客户端、离线接收者、已存储的消息和关联设备，在过渡期间都必须以可预测的方式运行。
IETF 的 RFC 7696 将算法敏捷性描述为一个涉及标识符、实现和运维变化的迁移问题。版本号有助于识别正在使用的方案，但本身并不能让迁移变得安全。
容易混淆的三种版本
即时通信软件可以同时有应用版本、线上传输协议版本和密码套件标识符。它们回答的是不同问题：
| 标识符 | 它向评估者说明什么 | 它不能证明什么 |
|---|---|---|
| 应用发布版本 | 安装的是哪个软件构建版本 | 每段会话都使用最新协议 |
| 协议版本 | 适用哪种消息格式和状态规则 | 实现正确遵循了这些规则 |
| 算法或套件标识符 | 选择了哪些密码组件 | 协商无法被降级 |
发布说明应明确这些版本之间的关系。如果只有新建会话使用新方案，或者较旧的关联客户端会导致回退，那么“已推出新加密”这一说法就含糊不清。
安全迁移必须说明什么
先考虑一个具体场景：Alice 今天更新应用，而 Bob 的旧手机仍处于离线状态。Alice 发送一条消息，随后又添加第二台设备。每台设备应该接受、存储和显示什么？
可供评审的设计至少要回答以下问题：
- 双方如何获知对方支持的版本？
- 所选版本是否作为会话的一部分进行认证？
- 双方没有共同可接受的版本时会发生什么？
- 恶意中继能否剥除某项能力信息，诱导使用更弱的模式？
- 旧消息是否仍可读取，哪些旧密钥仍然必需？
- 恢复备份是否会重新启用过时的协议状态？
- 已弃用的算法何时会被禁用，而不仅仅是不建议使用？
可见的失败往往比悄然切换到用户未打算使用的模式更安全。但具体的失败和恢复行为应有文档说明，避免人们转向不受保护的渠道来绕过问题。
实用的升级测试矩阵
安全升级不能只靠两个全新安装的客户端成功聊天来验证。请使用非敏感数据测试以下情况：
| 测试 | 要记录的证据 |
|---|---|
| 新客户端与旧客户端通信 | 所选协议或明确的不兼容结果 |
| 接收者在升级期间离线 | 重新连接后的投递和解密行为 |
| 旧关联设备重新上线 | 它能否读取、发送或迫使系统采用意外的模式 |
| 群组加入不兼容的成员 | 明确的群组策略和用户可见的状态 |
| 弃用后恢复备份 | 不受支持的状态是被拒绝还是被迁移 |
| 版本元数据遭篡改 | 出现认证失败，而非未被察觉的降级 |
这些是评估标准，并非声称某个具名产品已经通过这些测试。应保留构建标识符和观察到的结果，以便将后续回归问题与文档变化区分开。
如何理解 Livara 的协议名称
Livara 在其安全文档中，将直接聊天协议称为 LVR1，将私密群组协议称为 LGS1。这些名称用于区分职责；不应将其解读为经过独立标准化或审计的证据。该页面还讨论了客户端或群组无法满足加密模式前提条件时的行为。
下一步有用的证据应包括带版本的规范、测试向量、兼容性规则，以及与特定发布版本对应的评审结果。Proof Lab 明确说明了其演示范围较小。在浏览器中运行密码原语，不等于测试了应用中的每一条迁移路径。
加密升级期间用户应该做什么
及时更新仍受支持的客户端，阅读关于设备兼容性的安全公告，并留意身份或加密状态指示的变化。不要以为换了一个应用图标，就意味着所有旧群组和备份都获得了新的保护。如果产品无法说明哪些数据的保护发生了变化，在分享敏感材料之前应先询问清楚。
良好的密码敏捷性让变化可检查。 它说明改变了什么、通信双方如何达成一致、可能出现什么问题，以及旧机制何时不再被接受。
