TL;DR（省流总结）
端到端加密不只是文字聊天的专利。2026年的今天，语音通话（VoIP）、视频会议（WebRTC/CPaaS）、文件传输三大场景都有成熟但各不相同的 E2EE 方案。语音走 DTLS-SRTP + MIKEY 密钥交换，视频走 Insertable Streams API 逐帧加密，文件走 AES-256-GCM 流式加密 + 点对点直传。三条线的共同痛点不是加密算法不够强，而是元数据泄露、中转服务器可预测性强和密钥协商延迟。
引言：当你的”加密聊天”只能聊文字
很多用户有一个美丽的误会：下载了一个”端到端加密聊天应用”，就以为自己在上面打电话、发视频、传文件都是全加密的。实际上——大部分声称 E2EE 的产品只对文字消息做端到端加密，语音和文件要么不加密、要么是服务器加密（Server-side Encryption，服务端能看到明文）。
真正在全场景实现 E2EE 的产品，截止2026年5月，一只手数得过来。本文就从技术底层逐一道破：语音通话怎么加（以及为什么不加）、视频会议怎么流式加密、文件共享怎么做到服务器零知识——每个问题都附带跨平台实测数据。
如果你还没看过底层原理，建议先看这篇 端到端加密聊天的完整技术拆解，再回来看语音和视频会顺畅很多。
一、语音通话 E2EE：为什么听起来简单、做起来要命？
文字消息的 E2EE 是「异步」的：你发一条消息，可以花几百毫秒加密，发出去，对方在线或离线都能解密。但语音通话是实时流——延迟超过200毫秒人类就能感知到，HRTF（头部相关传输函数）的声场定位在50毫秒以上就开始混乱。加密必须在实时性约束下完成。
WebRTC + DTLS-SRTP：市面上90%的方案
2014年浏览器厂商推行 WebRTC 标准时，做了一个关键决策：所有 WebRTC 媒体流必须经过 DTLS-SRTP（Datagram Transport Layer Security for Secure Real-time Transport Protocol）加密。换句话说，浏览器的语音视频通话默认就是加密的。
但这里有个容易被偷换的概念：DTLS-SRTP 加密的是「传输层」，不是「端到端」。RTC 媒体服务器（Turn Server / SFU）在转发时可以解密再加密——这意味着只要服务器管理者愿意，就能监听通话内容。2023年 Zoom 因声称自己是”端到端加密”却实际使用了服务器端解密方案而遭到 FTC 调查和8500万美元和解，就是这个问题的经典案例。
MIKEY + SRTP：真正的 E2EE 语音方案
要做到真正的 E2EE 语音通话，需要在 DTLS-SRTP 之上再加一层：用 MIKEY（Multimedia Internet KEYing）或双棘轮协议在通话双方之间交换 SRTP 主密钥，让密钥只存在于通话终端的 SRTP 栈中，不经过服务器。
Signal 协议中的 X3DH 和双棘轮可以实现这个目标——在建立通话时，用文字消息通道交换 SRTP 密钥，然后双方各自初始化本地 SRTP 加密引擎。从协议层面看，这个设计和文字消息的 E2EE 共享同一套密钥基础设施，是统一的。
但代价是：通话建立延迟。从”拨出”到”接通”：
- 无 E2EE：约 200-300ms（ICE 穿透 + DTLS 握手）
- 带 SRTP 密钥协商：约 500-800ms（额外一次 X3DH 交互 + 密钥注入）
这300-500毫秒的差距对于一对一通话几乎不可感知，但在多人语音通话（E2EE Group Call）场景下会严重放大——6人会议每个人都要和5个人做密钥协商，建立延迟突破5秒。
二、视频通话 E2EE：帧率、码率、加密的三难
视频比语音更难做 E2EE 的原因有三个：数据量大（单帧可能超过100KB）、实时编码（H.264/H.265 编码后的帧结构复杂）、以及 SFU 需要按需转发不同码率的流（Simulcast）。
Google 在2020年提出并在2023年标准化的WebRTC Insertable Streams API是当前视频 E2EE 的主流方案。原理是：在视频编码器输出帧之后、发送到网络之前，开发者可以插入自定义的加密变换函数（Transform），对每一帧的 payload 做 AES-GCM 加密。接收端在解码之前，再用同样的密钥解密。整个过程对 WebRTC 的编码器、SFU 转发层、解码器完全透明。
我在五款主流安卓加密通讯App的对比测评中实测过视频通话的帧加密对性能的影响：
| 方案 | 720p@30fps 延迟增加 | CPU占用增加 | 带宽增加 |
|---|---|---|---|
| 无 E2EE（仅 DTLS-SRTP） | 基线 | 基线 | 基线 |
| Insertable Streams + AES-GCM | +8-15ms/帧 | +8-12%（中端芯片） | +5%（GCM 标签开销） |
| Older Frame Encryption（每帧全量加密） | +30-50ms/帧 | +20-30% | +15-25% |
结论很明确：用 Insertable Streams API 做视频 E2EE，在中端以上手机上性能损耗基本可接受。但低端设备（比如 Android Go 设备）上，8-12% 的 CPU 增加可能导致画面卡顿或掉帧，需要结合设备能力动态关闭逐帧加密，降级到 GOP 级别的关键帧加密。
三、文件共享 E2EE：看似简单、实则最考验架构
文字消息 E2EE 有一把会话密钥就够了。文件不一样——一个 200MB 的视频文件传过去，不能把 200MB 全部加载到内存再用一把会话密钥加密。正确的做法是：
- 发送端生成一个随机的文件密钥（File Key）
- 用 AES-256-GCM 对文件流式加密（每次读 64KB 块 → 加密 → 写临时文件）
- 将加密后的文件通过点对点直传通道（P2P DataChannel）或加密存储节点传输给接收方
- 文件密钥通过文字信令通道（已有 E2EE 保护）发给接收方
- 接收方拿到加密文件和文件密钥 → 流式解密 → 还原原始文件
这个设计的精妙之处在于：服务器可以转发加密文件，但它持有的是一堆 AES-GCM 密文块——既不知道文件类型、也不知道文件内容、更不知道文件密钥。
但这种方案有一个容易踩的坑：元数据泄露。即使文件内容被加密了，文件大小、文件名、传输时间戳、发送方和接收方的身份——这些”谁、何时、发给谁、发多大”的元数据——在标准实现中通常不会被隐藏。对于安全敏感的场景，需要额外引入流量填充（将文件填充到固定大小的倍数）和元数据混淆（随机化传输时间和批次分割）。
四条跨场景的通用建议
不管是语音、视频还是文件，E2EE 在多媒体场景下有四个共性问题：
1. 密钥协商的同步成本：话音视频都是实时流，密钥必须在通话建立前完成协商。不能用异步模式。
2. 编解码器的加密边界：加密必须在编解码之后、传输之前。不要在编码前加密（编码器会压缩掉随机密文），也不要在传输后加密（服务器能拿到编码后的原始帧）。
3. 元数据审计的能力上限：E2EE 保护内容不保护元数据。如果合规要求你保留通话记录（时间、时长、参与者），这是可以做到的；但如果要”审计通话内容”，这在 E2EE 架构下不可能——参考2026年五国法律合规指南中的合规风险分析。
4. 跨平台的一致性问题：做移动端 + Web 端 + 桌面端三端全覆盖的视频 E2EE 方案，最容易翻车的是 Web 端的 Insertable Streams API 兼容性——Safari 直到2024年才完整支持，Firefox 在 E2EE 场景下仍有帧格式对齐问题。
FAQ
Q: 我的App用的是WebRTC，语音和视频是不是自动加密了？
A: 是的——自动加密了传输层。但这不代表端到端加密。你的 TURN/SFU 服务器依然可以看到明文媒体流（因为 DTLS 在服务器处终结并重新加密）。要做真正的 E2EE，需要在应用层加 MIKEY 密钥交换或 Insertable Streams。
Q: E2EE 视频通话的画面质量会变差吗？
A: 不会。加密发生在编码器输出之后，不影响编码质量。唯一的性能影响是 CPU 增加 8-12%（中端设备），可能导致低端机掉帧，但不影响画质本身。
Q: 文件分享的 E2EE 为什么比文字消息慢那么多？
A: 文字消息通常只有几百字节，一次 AES 操作就能完成。文件分享涉及 64KB 块级别的流式加解密 + 大文件磁盘 IO + 分块传输校验，每一层都有延迟叠加。一个 200MB 文件的 E2EE 端到端延迟通常在 30-60 秒（取决于网络带宽），其中加密/解密本身只占不到 2 秒，其余都是传输时间。
Q: Signal/Telegram/WhatsApp 的语音视频到底是不是真 E2EE？
A: Signal 是，且是三款中最早实现全场景 E2EE 的。WhatsApp 在 2016 年引入了基于 Signal 协议的 E2EE 语音视频。Telegram 的一对一语音视频通话是可选的 E2EE（需要在通话界面确认密钥指纹），群组通话不支持 E2EE。
参考来源
- W3C WebRTC Encoded Transform 规范，定义了 Insertable Streams API 的标准接口，是实现视频逐帧加密的浏览器端基础。
- IETF RFC 4568 – SDP Security Descriptions for Media Streams，定义了 SRTP 密钥协商的 SDP 描述方式。
- Signal Blog – End-to-End Encrypted Voice and Video，Signal 官方解释其语音视频 E2EE 的协议流程。
