数据包完整性、消息新鲜性和编辑历史是三个不同的特性；不要用其中一个来证明另一个存在。
通信软件可以提供编辑或删除功能；但在使用认证加密的系统中，服务器不应能够悄悄修改密文，却仍交付一条有效消息。通信软件中的消息完整性意味着接收方能够发现数据在加密之后被更改；这与保留完整历史或在法律上证明对话不是一回事。
要点
- 认证加密能够揭示密文篡改，但不一定保存编辑和删除历史。
- 根据 Livara 技术文档，AES-256-GCM 使用认证标签保护私人消息；被篡改的数据包不应被有效解密。
- 授权编辑应是一个新的端到端加密事件，而不是由服务器秘密覆盖旧数据包。
- 安全号码有助于检查对方的密钥，而不是衡量其诚实程度或截图的法律效力。
- 对于敏感争议，还应在对话线程之外保留原始文件、时间、编辑状态和独立证据。
通信软件中的消息完整性究竟是什么？
消息完整性意味着接收方能够检测加密数据中的未经授权的更改。机密性问的是“谁能读取内容？”，完整性问的是“收到的是否仍是发送方加密的那些数据？”。端到端加密及其边界的说明进一步阐述了这一区别。
这是带有示意标签的概念插图，并非 Livara 的真实界面，也不是拒绝篡改消息测试的结果。
根据 Livara 技术文档，直接消息使用 LVR1，兼容的私人群组使用 LGS1 进行端到端加密。根据 Livara 安全页面，不兼容的旧群组会明确保持在 E2EE 之外，新群组则不会在所有成员准备就绪之前以“已加密”标签创建。请检查具体对话的状态。文档指出，LVR1 使用 ECDH P-256 与 ML-KEM-768 派生消息密钥。某一组件符合标准，不等于整个组合或产品获得了独立认可。随后，Livara 使用 AES-256-GCM 保护内容。
根据产品文档，这种保护涵盖私人对话的文本、编辑和附件。不过，Livara 频道不是端到端加密的：服务器刻意保留读取内容的能力，以便执行包括删除滥用内容在内的操作。群组成员资格也由服务器控制。通话安全和录音模式同样需要与文本消息分开评估。
检测加密消息篡改与通信软件的 AES-256-GCM 加密
AES-GCM 除了加密内容，还生成认证标签。如果密文或经过认证的数据被更改，标签验证应失败。NIST SP 800-38D定义了 GCM 模式，并警告在同一密钥下重复使用 nonce 会严重削弱安全性。
根据 Livara 技术规范，私人消息使用 AES-256-GCM。如果服务器更改受保护数据包的某一部分，没有消息密钥就无法生成新的认证标签；因此，接收方不应将该数据包视为完好并接受。对“服务器能修改消息吗？”的简短回答是：服务器可以删除、扣留、阻止或延迟交付数据，但不应能够把被篡改的内容伪装成有效内容。
这种保证并非无限。密码学不能消除设备上的恶意软件、攻击者对已打开屏幕的访问或用户授权编辑的影响。内容完整性也不一定隐藏元数据。通信软件元数据及其泄露信息的指南解释了这一边界。
服务器能修改消息，还是编辑另有含义？
服务器不应能够秘密覆盖之前的加密数据包，但可以交付由发送者创建的编辑事件。消息编辑安全性取决于编辑是否像原始消息一样经过认证并端到端加密，而不是由服务器直接修改已存储的文本。
根据 Livara 文档，直接聊天中的编辑受 LVR1 保护，兼容私人群组中的编辑受 LGS1 保护。评估界面时，应检查应用是否显示“已编辑”状态；但加密本身不会在所有设备上永远保留旧版本。
“为所有人删除”同样是一项丢弃内容的请求，不是所有副本都已销毁的证明。接收方可能已经看过消息、读过通知、保存过文件或截过图。阅后即焚消息减少留存，但不保证清除所有副本。
聊天消息认证能证明什么？
聊天消息认证表明消息由会话密钥生成，且在传输途中未被篡改。它不能证明账户所有者当时亲自持有设备、文本内容真实，或接收者以后能够向第三方作出确定性证明。
Livara 技术文档将安全号码介绍为检测密钥变化的方法。双方可以通过独立渠道比较密钥指纹；使用安全号码验证聊天的指南介绍了实际步骤。这项检查降低了联系人的密钥被攻击者密钥替换的风险，但不能让受感染的设备变安全。
账户身份认证也是另一回事。无论登录机制多么强大，都不能替代消息完整性、联系人密钥检查或设备安全。
内容完整性不同于消息顺序和新鲜性
一个旧数据包可能带有有效的认证标签。防止它再次被接受需要协议设计、计数器、会话标识符及接收方状态维护；AES-GCM 本身不是整段对话的顺序日志。这一区别对于评估重放、延迟消息和多设备同步很重要。
还必须明确哪些数据实际受到认证标签的保护。如果对话标识符或事件类型不在已认证的上下文中，仅仅保护消息体并不能解决全部问题。对该版本的代码检查与测试应阐明这种关联。
当消息文本或状态出乎意料时
记录应用版本、观察时间、涉及的设备以及是否存在编辑标签。通过独立渠道向联系人核实是否进行了授权编辑。不要在没有证据时把同步差异归因于服务器篡改；也不要毫无理由地忽略认证错误或密钥变化。
技术报告应使用非敏感测试消息，不要在公开报告中放入联系人的私人数据。如果要把对话用于法律事务，加密或截图本身并不决定其法律效力；在更改证据之前，应寻求具备资格的专业人士协助。
如何评估通信软件的完整性声明？
不要满足于“已加密”这一表述。应询问：
- 哪些对话和文件是端到端加密的？
- 服务使用哪种 AEAD 算法？
- 编辑和删除如何记录与显示？
- 用户如何识别联系人密钥的变化？
- 服务器控制哪些元数据、内容或成员资格？
- 通话是否具有与消息相同的保证？
- 协议是否经过独立审计？
Livara 发布了用于检验其部分声明的规范与工具，Android 用户可在用于离线检查应用的 Proof Lab中，用 SHA-256 比较 APK 文件的校验和。不过，本文没有提供当前版本经过独立审计的证据。发布规范和测试向量有助于检查，但不能代替独立审计。
对于私人对话，Livara 的核心声明是有限且明确的：AES-256-GCM 应揭示数据包篡改，编辑也应加密。这不等于不可更改的日志、所有副本必然被删除，或自动成立的法律证据。
常见问题
服务器管理员能修改加密消息的文本吗？
在正确使用 AES-256-GCM 的设计中，没有消息密钥的服务器管理员无法修改密文并生成有效的认证标签。但仍可以删除、阻止或延迟交付数据包。这种保证不涵盖受感染的设备或发送方授权的编辑。
“已编辑”标签能证明旧版本是什么吗？
不能。除非应用还保存版本历史，否则该标签只说明所显示的内容在发送后发生了变化。加密可以验证编辑事件的真实性，但不会自动保留之前的文本。
安全号码能保证所有消息的真实性吗？
不能。安全号码有助于验证加密密钥是否属于联系人，并检测其变化。这项检查不能说明发送时是谁持有设备、消息是否属实，或设备是否没有恶意软件。
为所有人删除会从所有地方清除消息吗？
不会。这个功能可能丢弃应用内的副本，却无法收回已保存的文件、通知、截图或此前的记录。为所有人删除减少留存，但不保证从接收方设备或其他系统中彻底清除。
