Secure Drop
Anonymous · Encrypted · No login required
Your message is sealed and anonymous. We cannot identify you. No account or login is needed.
Your message
Max 3 files, 10 MB each
Secure Channel
Anonymous · Bidirectional · Encrypted
Start an anonymous conversation. You'll receive a thread code to check for replies later.
Your message
Max 3 files, 10 MB each
Thread Code
Enter your thread code above to check for replies.
已发布 · 2026 年 8 月 9 日审核

端到端加密保护什么以及不保护什么

端到端加密可以使消息内容远离网络、服务提供商和受损的交付服务器。它不会自动确保端点、收件人、元数据或备份的安全。

发布于 2026 年 8 月 9 日9分钟阅读
审核状态: 经 Stephane Vaillancourt 批准发布

简短的回答

正确实施的端到端加密意味着消息内容在发送者的设备上进行加密,并且只能由预期的接收端点解密。交付服务应处理密文,而不是明文或对话密钥。但 E2EE 保护端点之间的路径 - 它并不使任一端点、接收者、每条元数据或每个备份都值得信赖。

“端到端”的实际含义是什么

端点是保存读取对话所需密钥的设备或应用程序实例。加密发生在消息离开发送者端点之前;解密在到达授权接收端点后发生。

这个界限很重要。 TLS 等传输加密可保护设备和服务器之间的连接。端到端加密添加了单独的消息级边界,旨在防止中介接收明文密钥。 IETF 的消息传递层安全标准将目标描述为使消息可供通信端点访问,而不是传递消息的服务器。

产品标签本身并不能作为证据。身份认证、密钥管理、组成员变更、旧密钥删除、实施质量和备份行为都会影响真正的安全结果。

发送装置明文存在于此处
加密
送货服务仅密文
解密
接收设备明文存在于此处
受保护的路径位于端点之间。明文仍然存在于人们撰写和阅读的地方。

E2EE 旨在保护什么

确切的保证取决于协议和实现,但现代经过身份验证的 E2EE 旨在解决这些风险:

网络拦截

观察 Wi-Fi、ISP 或中间网络的人应该看到加密的流量,而不是可读的消息内容。

好奇的服务提供商

不持有会话密钥的传送服务不应能够打开普通消息密文。

交付服务器妥协

即使基础设施路由或临时排队密文受到损害,消息级加密也可以保持内容机密性。

未检测到的消息更改

经过验证的加密可以允许接收者拒绝被更改或伪造的密文,但需要正确的密钥验证和实施。

一些过去的消息曝光

具有前向保密性的协议会删除或提前旧的密钥材料,因此后来的密钥泄露不会自动泄露所有早期的消息。这是附加协议属性,而不是 E2EE 的同义词。

E2EE 不自动保护的内容

当对消息内容的保护被视为对整个通信系统的保护时,大多数安全误解就开始了。

受损或未锁定的端点

恶意软件、未锁定的被盗设备、通知预览、屏幕截图、键盘和辅助服务可能会在加密之前或解密之后遇到明文。

接收消息的人

授权收件人可以复制、拍照、引用或转发他们可以合法阅读的内容。消失的控件减少了保留的历史记录;它们无法让敌对的接收者忘记。

所有元数据

交付可以公开时间、流量、IP 地址、目的地、设备令牌或组操作。协议和架构可以最小化或屏蔽部分元数据,但仅内容加密并不能消除它。

未加密的备份和导出

如果将明文历史记录或可恢复密钥复制到另一个系统中,则该副本有其自己的安全边界。 “聊天是E2EE”并不能证明每个备份都是。

谁真正在另一端

对错误或替换密钥的加密可能会与错误的一方创建完全加密的对话。密钥验证和可信身份绑定仍然很重要。

可用性和强制

服务仍然可以延迟、阻止、速率限制或删除加密流量。 E2EE 也无法阻止人们被迫解锁端点或泄露他们所知道的内容。

威胁模型:E2EE 有帮助吗?

一个有用的安全问题会指出对手的名字,而不是询问应用程序是否只是“加密”。

设想E2EE 是否保护内容?还有什么重要的
网络观察者拦截流量通常是的强大的协议、安全实施、流量分析限制
交付服务器被破坏通常是的密钥必须保留在授权端点上;元数据可能仍然可见
手机在解锁状态下被盗设备锁定、本地存储保护、通知策略、短期保留
收件人故意记录消息信任、政策、水印、有限披露、法律控制
攻击者替换身份密钥不是靠它自己密钥验证、透明度、身份验证、更改警告
服务拒绝传递消息可用性设计、监控、备用沟通计划

City of Hats 如何处理这个边界

City of Hats 将 E2EE 视为更广泛的威胁模型中的一层。以下陈述描述了我们发布的架构和产品行为;它们并不是声称软件可以消除端点风险或接收者行为。

消息级加密

City of Hats 使用混合 X25519 和 ML-KEM-768 密钥建立与 Double Ratchet 和 AES-256-GCM 记录 Hat-to-Hat 消息、文件和呼叫的客户端 E2EE。对话解密密钥应保留在授权设备上。

技术透明度 →

少注册身份

无需电话号码或电子邮件即可创建 Hat。 Phrase IDs、多个 Hats 和一次性 Hats 减少了将每个通信上下文与一个运营商或邮箱身份绑定的需要。他们不会将受感染的设备或网络连接设为匿名。

Disposable Hats →

中继加密呼叫

City of Hats 记录中继的语音和视频,因此其他参与者不会收到直接的点对点 IP 地址。中继处理加密媒体,而网络级元数据仍然需要现实的威胁模型。

加密通话 →

没有对话恢复路径

消费者信使的设计没有提供者持有的消息恢复保管库。丢失唯一授权的设备可能意味着丢失消息历史记录。这提高了对服务器端恢复需求的抵抗力,但这是一种故意的可用性权衡。

隐私和数据处理 →

交付后的控制

View Once、Recall、GeoLock、Certified Send、Channel Seal等安全模式可以限制正常访问或保留。这些控制措施减少了暴露;他们无法使用第二个摄像头或已经受到威胁的端点来击败授权接收者。

安全模式 →

可烧毁的通信环境

Hats 和通道可以被销毁或允许过期,因此长期身份和无限的对话历史记录不是强制性的。破坏会减少以后剩余的资源;它无法撤回已在受保护系统之外捕获的信息。

Channel Seal →

如何评估加密信使

不要停留在“端到端加密”这个短语上。询问提供商或其文档:

  1. 默认情况下哪些通信类型是 E2EE:消息、群组、文件、呼叫和业务交互?
  2. 密钥在哪里生成、存储、轮换、备份和删除?
  3. 如何验证身份密钥以及密钥更改时会发生什么?
  4. 该服务可以观察或保留哪些内容和元数据?
  5. 受损、丢失或新连接的设备上会发生什么?
  6. 收件人可以导出、转发、捕获或永久保留内容吗?
  7. 是否有协议规范、源代码、审计或可复制的技术证据?
  8. 哪些安全属性独立于 E2EE,例如前向保密、泄露后安全、元数据抵抗和可用性?

底线

端到端加密至关重要,因为它可以将交付服务和网络从受消息内容信任的各方中删除。它不是整个隐私系统。强大的安全通信还取决于端点、身份、元数据、保留、恢复、接收者行为和诚实的权衡记录。

主要来源和进一步阅读

本文使用的标准和第一方技术材料。访问日期:2026 年 8 月 9 日。

  1. IETF RFC 9420. The Messaging Layer Security (MLS) Protocol
  2. IETF RFC 9750. The Messaging Layer Security (MLS) Architecture
  3. NIST SP 800-124 Rev. 2. Guidelines for Managing the Security of Mobile Devices
  4. Signal. Sealed Sender: metadata and message delivery
  5. Signal. Disappearing messages and the hostile-recipient boundary

City of Hats 产品声明链接到我们自己发布的文档,在独立验证之前应作为第一方声明进行评估。

← 返回知识中心