加密附件：密钥与云端文件如何分离

端到端加密附件可以存储在服务器上，而无需让服务器获得明文文件。一种常见设计是在发送者的设备上用新的内容密钥加密文件，上传密文，再通过经过身份验证的加密消息将密钥发送给预期接收者。

这种分离很有用，但“零知识存储”并不是完整的技术规范。仍需了解密钥、文件引用、文件名、访问控制和已下载副本如何处理。

附件的生命周期

1. 准备文件。 发送者选择照片、视频或文档。移除元数据或转码是单独的步骤；仅靠加密不会剥离 EXIF 或文档属性。
2. 创建加密材料。 安全的实现会按照所选方案生成所需的密钥和 nonce 材料。
3. 上传前加密。 存储服务收到的是加密字节，而不是原始内容。
4. 传递经过认证的引用。 加密聊天消息携带接收者所需的信息，例如文件定位信息、解密密钥和相关完整性元数据。
5. 获取并验证。 接收客户端取得数据块，并在将结果视为有效内容之前验证认证信息。
6. 管理本地副本。 显示、导出、编辑或保存到图库，都可能在原来的加密存储边界之外创建副本。

密钥可以封装在加密信封中，经由同一提供商的基础设施传输。将其称为“带外”可能误导：它与数据块存储在逻辑上分离，但不一定通过独立通信通道传递。

认证加密增加了什么

认证加密方案保护机密性，并检测其认证范围内未经授权的更改。NIST 的 GCM 规范定义了这样一种构造及其要求。正确处理密钥与 nonce，并检查认证结果至关重要；知名算法的名称并不能使每一种实现都安全。

应用还需要将文件绑定到正确的消息和对话。有效的加密数据块本身不能证明它属于这一特定聊天。文件标识符、预期大小、分块顺序和附件元数据都需要适当的认证设计。

存储服务仍可能知道什么

信息	仅靠内容加密能隐藏吗？
原始文件字节	其设计目的就是对没有密钥的各方隐藏这些内容
大致的加密后大小	通常不能
上传和下载时间	通常不能
哪个账户请求文件	取决于路由和访问控制设计
文件名和说明文字	只有协议也保护它们时才可以
接收者保存的副本	不能；接收者已经可以访问明文

即使数据块已加密，访问控制仍很重要。它可以限制不必要的下载、滥用和标识符暴露。加密不能替代授权、保留政策或可用性。

大文件需要的不只是一句口号

大文件设计可以采用流式传输，或将数据拆分为经过认证的分块。这可以减少内存占用，但必须定义分块编号、最终长度、重试和截断处理。不要编造性能数字，也不要声称将文件放入消息必然导致“棘轮状态膨胀”；这些结果取决于具体实现。

有用的测试包括有效文件、更改一个字节、截断下载、调换分块顺序，以及未经授权的获取尝试。只能在获授权的测试环境中，使用非敏感文件进行这些测试。记录客户端是否在打开无效数据前就拒绝它。

Livara 的文档说明

Livara 的安全页面描述了上传前加密、在受保护会话内传递每个文件的随机密钥，以及在启用 E2EE 的对话中保护文件名和说明文字，其中包括兼容的私密群组。旧的不兼容群组明确不在这一覆盖范围内。文档将受保护对话与公开广播频道区分开来。这些是文档中的产品声明，不是本文进行的一次新的实现审计。

威胁模型也承认，接收者或遭入侵的设备可能暴露可读内容。因此，加密存储无法承诺：删除聊天消息时，图片会从每台设备上消失。

分享敏感文件前应问的问题

检查对话类型是否支持 E2EE、所有预期接收者是否可信，以及文件本身是否含有身份识别元数据。单独检查图库自动保存和云端照片备份。对于文档，应考虑是否需要在发送前移除评论、修订历史或嵌入属性。

最后，要理解删除与恢复。移除服务器数据块可以阻止未来下载，但不能收回接收者已有的副本。丢失所需密钥，可能使仍然存在的加密文件无法读取。良好的附件设计会清楚说明这两种结果。