一款消息应用可以显示锁形图标、自称保护隐私，却仍然对重要问题语焉不详。
哪些对话被加密？附件受到保护吗？密钥存在哪里？服务器保留哪些信息？设备丢失后会怎样？加密密钥能否在没有警告的情况下改变？
这些细节有助于识别真正有用的保护措施，以及仍然缺少的证据。任何检查清单都无法单独为产品的安全性提供认证。
本指南提供 12 个实用问题，供你在把私人对话、机密文件或敏感工作交给加密消息应用之前逐一询问。
什么是安全的消息应用？
安全消息应用是一种通信服务，其设计目标是保护对话，防范未经授权的访问、截听、账户遭接管，以及意外的数据暴露。
认真对待隐私的消息应用，至少应采用安全的网络传输、强账户身份验证、审慎的访问控制和清晰的数据处理规范。
对于高度私密的对话，还应提供端到端加密。
端到端加密，即 E2EE，在发送者设备上加密受支持的内容，并在获授权的接收者设备上解密。服务可以传送加密数据，而不需要获得可读的消息正文。
不过，加密只是消息安全的一部分。
完整评估还必须考虑：
- 哪些对话被加密
- 照片和文件是否获得相同保护
- 私钥存在哪里
- 联系人如何核验密钥
- 哪些元数据仍然可见
- 账户恢复和密钥恢复如何运作
- 设备被攻陷后会怎样
- 服务如何说明自身局限
如需更深入的介绍，可阅读《端到端加密详解》。
为什么“已加密”三个字还不够
几乎所有现代消息服务都会通过 HTTPS、TLS 或其他受保护的传输方式加密网络流量。
这类保护很重要，但并不必然意味着对话采用了端到端加密。
传输加密保护数据在设备与服务之间移动的过程。服务仍可能先收到可读内容，再通过另一条受保护的连接将其送达。
采用 E2EE 时，受支持的消息内容会在到达消息服务之前，针对参与者完成加密。
这一区别决定了谁在技术上可能访问消息正文。
因此，应提出精确的问题，而不是满足于笼统的“已加密”标签。
| 声称 | 你应提出的问题 |
|---|---|
| “聊天已加密” | 只是传输过程加密，还是端到端加密？ |
| “数据安全” | 哪些数据，防范什么威胁，保护多长时间？ |
| “我们无法读取你的消息” | 是否涵盖私聊、群组、媒体、通话和备份？ |
| “隐私融入设计” | 哪些元数据和运行信息仍然可用？ |
| “安全恢复” | 谁能恢复加密密钥，需要什么秘密凭据？ |
1. 哪些对话采用端到端加密？
不要假定一项加密声明适用于应用的所有部分。
消息服务可能对以下内容提供不同保护：
- 一对一私聊
- 私人群组
- 公开群组
- 广播频道
- 语音和视频通话
- 动态或临时帖子
- 机器人和自动化账户
- 同步的对话历史
要求服务商指出准确的边界。
有说服力的回答类似于：
私聊正文和媒体在参与者设备上加密。兼容的私人群组使用 LGS1 端到端加密，成员变动时自动轮换发送者密钥。频道采用独立的、服务器可读的架构，不被描述为 E2EE。
缺乏说服力的回答则类似于：
你的通信受到军用级加密保护。
第一种回答提供了可以评估的信息。第二种只使用听起来厉害的措辞，却未界定受保护的内容或威胁模型。
2. 照片、视频和附件也加密吗？
应用可能加密文本，却通过另一套系统处理上传的媒体。
这就带来一个重要问题：照片上传前是否在客户端加密，还是仅靠服务器权限和传输加密保护？
应询问以下内容：
- 照片和视频
- 文档
- 语音消息
- 链接预览
- 缩略图
- 临时上传文件
- 缓存媒体
- 下载授权
媒体保护应单独说明，而不是藏在有关“消息”的宽泛声明里。
还应分别询问访问加密字节和访问解密密钥的条件。有些设计通过限制较少的存储分发加密附件；这并不自动等于明文暴露。关键在于，未经授权者能否获得可读媒体或其密钥，以及存储路径会透露哪些元数据。
3. 加密密钥在哪里生成和保存？
加密的可信程度取决于密钥处理方式。
对于客户端 E2EE，私钥材料应始终由参与者设备控制。公钥可以共享，让联系人建立加密通信，但私钥需要更强的保护。
寻找以下问题的明确答案：
- 私钥是否在设备上生成？
- 是否曾以未加密形式上传？
- 服务商能否推导或替换它？
- 另一台已登录设备能否自动获得它？
- 本地密钥存储是否受到保护？
- 密钥重置后会怎样？
- 重新安装应用是否会生成新的身份密钥？
文档不必公开每一个实现细节，但应说明私钥的归属和生命周期。
4. 联系人能相互核验密钥吗？
只有当加密密钥属于预期参与者时，端到端加密才能保护对话。
许多安全消息系统用指纹、安全码、二维码或其他核验值来表示公钥。
两位联系人可以通过可信渠道比较该值，例如：
- 当面见面
- 经核实的语音通话
- 先前已完成身份验证的账户
- 可信的公司名录
密钥核验能进一步确认正在使用预期的密钥，但本身不能证明一个人的身份。有些产品也提供密钥透明度检查，例如 Signal 的自动核验。应检查其支持的账户和版本条件，而不是要求每款产品都只能使用手动流程。
还应询问指纹改变时会发生什么。
密钥变化可能有正常原因，例如重置、更换设备或恢复操作。但变化应当可见。无提示的替换，会让意外的身份密钥变化更难被发现。
5. 服务保留哪些元数据？
消息内容与消息元数据是不同类别的信息。
服务可能无法读取 E2EE 消息正文，却仍会处理路由、同步和显示对话所需的信息。
根据系统设计，这些信息可能包括：
- 发送者和接收者账户标识符
- 对话成员关系
- 消息时间戳
- 送达和已读回执
- 消息大小
- 表情回应和编辑事件
- 设备会话
- 同步游标
- 公钥材料
- 推送通知令牌
- 防滥用及安全记录
存在运行所需的元数据，并不自动意味着服务不安全。
重要问题是：
- 收集什么？
- 为什么需要？
- 保留多久？
- 谁能访问？
- 用户能否导出或删除？
- 是否用于广告或无关的用户画像？
如果服务商声称“不存储任何元数据”，却未定义它所说的元数据，要保持谨慎。
6. 你的账户如何进行身份验证？
强大的消息加密无法弥补薄弱的账户安全。
接管账户的攻击者可能冒充用户、注册新密钥、访问服务器可读的内容，或干扰恢复流程。
评估服务是否提供以下保护：
- 安全的密码处理
- 速率限制
- 会话撤销
- 清晰的设备或会话管理
- 防止凭据重放
- 安全的密码重置流程
- 在适当情况下使用多因素身份验证
- 重要账户变更通知
还应区分账户身份验证和消息加密。
登录证明某人拥有账户凭据，但并不必然证明该设备持有原始的私有加密密钥。
7. 加密恢复如何运作？
恢复是私人消息服务中最难权衡的问题之一。
用户希望更换设备后仍能访问对话历史，这是可以理解的。但如果服务商能够悄悄恢复每一个私钥，它可能拥有超出用户预期的解密能力。
受保护的恢复设计可以在客户端加密备份，并要求恢复秘密、通行密钥或可信设备批准。首先要确定备份包含什么：账户身份、联系人和消息历史是不同的东西。
应询问：
- 备份是否在上传前加密？
- 仅凭账户密码就能恢复吗？
- 服务商是否知道恢复秘密？
- 客服能否重置这项秘密？
- 秘密丢失后会怎样？
- 恢复后是否保留相同的公钥指纹？
- 能否关闭恢复功能？
可信的回答可能包含令人不安的限制：同时丢失私钥和恢复秘密后，旧的加密内容可能无法恢复。
这种后果可能证明存在真正的安全边界，而不是产品缺陷。
8. 连接中断时会怎样？
安全与可靠性必须协同工作。
移动连接会消失，浏览器会休眠，设备会切换网络。设计良好的消息应用应能应对临时断线，而不重复消息、打乱顺序或削弱加密。
寻找能够做到以下几点的离线与同步机制：
- 在本地暂存待发送操作。
- 为其分配稳定的标识符。
- 重新连接后安全重试。
- 避免重复发送。
- 核对并处理服务器确认。
- 获取离线期间错过的变化。
还应分别询问，消息等待发送时，应用如何保护网络载荷和本地发件队列。E2EE 并不能自动证明本地队列在存储时已加密。
网络重试不应要求把原本端到端加密的消息以明文副本交给投递服务。
9. 上传内容和已存储对象如何授权访问？
媒体安全不只是加密。
服务可能处理头像、消息附件、壁纸、动态、临时上传及生成的缩略图。每一种对象都需要访问策略。
检查应用是否：
- 要求通过身份验证才能获取私人媒体
- 核实请求账户属于相关对话
- 将公开资源与私人消息对象分离
- 清理未关联的上传文件
- 删除已过期的临时对象
- 防止跨账户缓存
- 使用不可预测的标识符，但不把不可预测性当作授权
私人明文文件不能仅因有人猜中其网址就变得可读。对于加密对象，应检查密钥和访问能力如何分发及撤销。OWASP 的授权指南建议一致地执行访问决定，包括针对静态资源；仅有不可预测的标识符，并不构成完整的授权策略。
10. 群聊受到不同的保护吗？
群组加密和成员控制带来的问题与私聊加密不同。
成员变化、多设备、消息历史、管理员角色、邀请、移除成员和密钥轮换，都带来额外的设计要求。
有些服务同时为私聊和群聊提供 E2EE。另一些只对私聊提供 E2EE，而通过 TLS、经过身份验证的存储和服务器端访问控制保护群组。
第二种模式仍可提供有意义的安全保护，但其信任边界不同。
询问服务器能否处理群组内容，以及下列情况是否会改变保护：
- 有成员加入
- 有成员离开
- 管理员移除某人
- 消息被编辑
- 历史同步到新设备
- 机器人或集成加入群组
绝不要认为一种对话类型显示的锁形图标，会自动适用于其他所有类型。
11. 用户拥有哪些隐私控制？
隐私还涉及信息到达服务之后，用户能如何控制它。
寻找实用的账户和对话控制功能，例如：
- 导出账户数据
- 删除账户
- 撤销会话
- 清除本地或同步的历史记录
- 在允许时删除已发送消息
- 管理已读回执
- 控制个人资料可见性
- 屏蔽不需要的联系人
- 管理通知预览
- 停用或删除密钥备份
服务商应说明，删除操作只移除你的副本、每位参与者的副本，还是服务器记录本身。
接收者可能已经下载、复制、转发消息，或拍摄了消息照片。任何删除功能都无法保证从所有终端彻底擦除内容。
12. 安全声称是否具体且可核实？
最有说服力的安全文档会界定边界。
寻找对以下事项的具体说明：
- 算法和密钥长度
- 客户端与服务器端操作
- E2EE 覆盖的对话类型
- 媒体加密
- 存储的信息
- 身份验证
- 恢复
- 密钥变更
- 访问控制
- 已知局限
- 文档最后更新日期
谨慎看待这些含糊措辞：
- 无法破解的加密
- 绝对隐私
- 军用级安全
- 完全匿名
- 零元数据
- 不可能被黑客攻破
- 永不过时的加密
任何复杂的通信系统都不应仅凭一句口号来评估。
独立审计、公开技术文档、可复现构建的客户端、专业评审及范围清楚的安全报告，都能提供额外保障。它们并不具有相同的证据强度，但都比缺乏支持的最高级宣传更有用。
安全消息服务：积极信号与警示信号
| 积极信号 | 警示信号 |
|---|---|
| 服务商明确指出哪些对话采用 E2EE | 所有功能都只被笼统描述为“已加密” |
| 说明私钥归属 | 从不讨论密钥处理 |
| 密钥变化可见 | 密钥可以无提示地变化 |
| 记录恢复限制 | 客服声称能恢复一切，却不解释方法 |
| 列明元数据类别 | 未作定义就声称“零元数据” |
| 单独说明媒体保护 | 只提文本消息 |
| 群组有明确的信任边界 | 暗示私聊声称也覆盖群组 |
| 安全页面包含当前实现细节 | 营销措辞与技术文档矛盾 |
| 清楚说明局限 | 声称绝对或无法破解的保护 |
将检查清单用于 Livara 的公开声称
Livara 安全页面提供的是产品文档，而非独立认证。其当前边界区分如下：
- **私聊：**LVR1 使用混合 P-256 与 ML-KEM-768 密钥协商，并对受支持内容采用带认证的加密。
- **兼容的私人群组：**采用 LGS1 发送者密钥保护；成员关系和角色仍属于独立的服务器权限边界。较旧、不兼容的群组不应自动获得 E2EE 标签。
- **公开频道：**内容可由服务器读取，不是 E2EE。
- **恢复：**身份材料在上传前加密封装；恢复它并不等于恢复聊天历史。
- **元数据与设备：**路由记录和被攻陷的终端，仍在内容加密承诺之外。
把这些视为待核实的声称，对照你安装的版本和威胁模型检查。协议规范、本地测试向量、特定版本的审计，以及对线上服务的观察，是不同形式的证据。不要因为证据缺失，就假定它完美安全或已被证实存在漏洞。
60 秒安全消息检查清单
创建账户前，检查你能否回答每一个问题：
- 哪些对话类型采用端到端加密？
- 图片、视频、文档和语音消息是否包含在内？
- 私钥是否在参与者设备上生成并保留？
- 联系人能否比较密钥指纹或安全码？
- 密钥变化是否可见？
- 隐私政策是否列明所存储的元数据？
- 是否解释了账户身份验证？
- 密钥恢复流程是否与普通登录分开？
- 私人媒体请求是否经过身份验证和授权？
- 离线排队期间加密是否仍然有效？
- 是否为群组和频道定义了准确的安全边界？
- 是否记录了局限，且没有夸大的承诺？
把未回答的项目标为“未知”，不要自动标为“安全”或“不安全”。服务商不必与每一家竞争者使用相同架构。
但它必须提供足够精确的答案，让用户理解自己正在信任什么。
最安全的选择取决于你的威胁模型
不存在对所有人和所有情境都自动最好的通用消息应用。
家庭群、工作场所、记者与消息源、医疗团队及公开社区，可能需要不同组合的以下能力：
- 保密性
- 身份核验
- 匿名性
- 群组管理
- 消息保留
- 法规合规
- 恢复
- 多设备支持
- 开源代码
- 独立审计
- 易用性
先问清自己要保护什么，以及防范谁。
对于普通个人通信，主要风险可能是账户盗用、不安全的网络、设备丢失，或过度的数据收集。
对于风险更高的通信，还可能需要经过核验的身份、自动消失消息政策、加固的设备、严格的操作流程和独立安全评审。
加密无法修复已被攻陷的终端，也无法阻止可信接收者分享消息。
隐私始于准确的预期
值得信任的消息应用不会要求用户相信所有风险都已消失。
它会解释：
- 什么受到保护
- 哪些设备持有密钥
- 服务器处理什么
- 哪些元数据仍然存在
- 恢复如何运作
- E2EE 从哪里开始、到哪里结束
- 哪些保护尚未实现
这种清晰度让用户能作出知情决定。
清晰的文档是评估的必要条件，但不足以确定哪款应用最安全。实现质量、及时更新、独立发现，以及实际使用中的风险也很重要。EFF 的工具选择指南同样建议从自身威胁出发，把开放性视为接受审查的机会，而非保证。
下一步可以做一次无害试用：核验一位联系人，发送一个示例附件，检查关联设备，查看备份范围，并确认双方都能可靠地使用相关设置。不要拿你正试图保护的机密材料来测试。
常见问题
什么让消息应用具备安全性？
安全消息应用结合了受保护的网络传输、强身份验证、审慎的访问控制、安全的密钥管理、负责任的数据处理，以及明确记录的隐私边界。对于私人消息内容，端到端加密提供了重要的额外保护层。
加密消息应用一定保护隐私吗？
不一定。应用可以加密消息内容，同时仍处理账户信息、时间戳、成员关系、回执、设备信息或其他元数据。隐私既取决于加密，也取决于服务更广泛的数据实践。
端到端加密会隐藏我和谁通信吗？
不一定。E2EE 主要保护受支持的消息内容。为了投递和同步对话，服务仍可能需要发送者、接收者、成员关系、时间和路由信息。
消息服务商能恢复 E2EE 消息吗？
这取决于密钥和备份设计。服务商可能存储加密的消息历史，却没有打开它所需的私钥。恢复系统可能只有在用户提供独立的恢复秘密时，才能恢复密钥。
基于浏览器的安全消息服务安全吗？
浏览器可以执行强大的客户端密码运算，但安全性仍取决于应用实现、浏览器完整性、设备安全、密钥存储、服务器交付应用代码的方式，以及用户的扩展和操作系统。
群聊一定采用端到端加密吗？
不是。有些服务为群组提供 E2EE，另一些只将其用于私聊。请查阅服务商文档，确认准确边界。
如果我的加密密钥改变，会发生什么？
密钥变化可能源自新设备、重新安装、密钥重置或恢复流程。安全消息应用应让变化可见，并允许联系人核验新指纹。
E2EE 足以保护高度敏感的通信吗？
E2EE 保护受支持终端之间的内容，但无法保护已感染或已解锁的设备、保证接收者的行为，或自动隐藏元数据。高风险用户还需要强设备安全和操作安全。
