VPN 中的 ChaCha20-Poly1305 是什么

打开几乎任何一款现代 VPN 隧道的技术说明，你都会看到一行写着“ChaCha20-Poly1305”。它常被当成装饰性的字符串，与“AES-256”和另外一堆缩写放在一起。可实际上，你每发出一个数据包，它都在替你工作：既让内容无法被读取，又让接收方知道有没有人改动过内容。理解它，比名字看上去容易得多。

本文在 VPN 的场景下讲解 ChaCha20-Poly1305：名字的两半各做什么，关于 nonce 这个数字的一条规则如何保证整体安全，为什么它常常适合手机和路由器，以及怎样读懂关于加密算法的宣传而不被术语唬住。想先了解密钥与算法如何配合的全貌，请从 VPN 加密是什么 开始。这里我们往下深入一层，专讲这一个算法。

一个名字里的两项工作

“ChaCha20-Poly1305”其实是两个算法一起使用，各自的工作不同。

• ChaCha20 是加密的那一半，用秘密密钥把可读数据变成打乱的数据。
• Poly1305 是认证的那一半，生成一个简短的“指纹”，称为标签，用来证明数据在发出之后没有被改动。

把加密与认证放进同一步，叫做 AEAD，即带关联数据的认证加密。“关联数据”的意思是，某些信息（例如数据包头）可以被标签覆盖，即使它们本身没有加密。这样的设计避免了一个经典错误：只加密数据，却忘了检查数据是否完整。

数据已经被打乱了，为什么还要在意完整性？因为攻击者即使读不懂你的数据包，仍然可以翻转其中的比特、丢弃数据包或重放旧包，而设计不佳的系统可能因此出现真正的问题。使用 AEAD 时，接收方先验证标签，对不通过的数据直接丢弃，不会有任何一个字节到达浏览器或应用。

可以拿封好的快递袋打个比方。加密是不透明的袋子，遮住里面的信；标签是封口处的防拆封条。好的系统不会拆开封条已经破损的袋子。

ChaCha20 如何加密：通俗版

ChaCha20 是一种流密码。它不是把数据分成固定大小的块来打乱，而是生成一长串伪随机字节，称为密钥流（keystream），再用 XOR 把这串字节和数据合在一起。XOR 是一种简单运算，密钥流为 1 的位置就把对应的位翻转。

因为 XOR 能自我还原，能生成同样密钥流的接收方，只要再 XOR 一次，就得到原始数据。

密钥流由四项输入生成：

输入	大小	作用
密钥（key）	256 位	通过密钥交换得到的共享秘密
nonce	96 位	同一密钥下每个数据包必须不同的数字
计数器（counter）	32 位	为数据包内每个 64 字节块计数
常量	固定	用于初始化内部状态的固定字

它们合起来填满一个由十六个 32 位字组成的小型内部状态，共 512 位。ChaCha20 随后对这个状态混合 20 轮，只用到三种简单运算：加法、循环移位和 XOR，这类设计有时称为 ARX。没有查表，也没有依赖秘密数据的分支，这带来一个有用的副作用，下文会提到。

结果是 64 字节的一块密钥流。计数器加一，就得到下一块，数据包需要多长就继续多长。这个设计出自 Daniel J. Bernstein，是对他更早的算法 Salsa20 的改进。

Poly1305 与篡改检测

Poly1305 是一种消息认证码。对每个数据包，它读取数据并生成一个 16 字节的标签。发送方附上标签，接收方重新计算并比较。

一个巧妙的细节是 Poly1305 的一次性密钥从哪里来。在标准构造中，每个数据包用计数器为 0 生成的第一块密钥流并不用于加密，而是取其中一部分作为 Poly1305 的一次性密钥。载荷的加密则从计数器 1 开始。因此每个数据包都有新的认证密钥，无需额外保存或交换任何秘密。

实际效果怎样？想象一个在途中的数据包。

1. 你的手机加密数据包，并附上 16 字节的标签。
2. 路径上某一跳被人控制，在加密载荷中改动了一个比特。
3. 服务器根据收到的内容重新计算标签，结果对不上。
4. 服务器丢弃这个包。改动不会到达任何应用，攻击者也没有得到有用的信息。

伪造的数据包碰巧带上有效标签的概率大约是二分之一的 128 次方，任何猜测者都不可能尝试这么多次。因此 VPN 隧道通常把完整性视为必需项，而不是附加项。

保证安全的 nonce 规则

使用 ChaCha20 时，绝不能重复使用同一组密钥和 nonce。下面用一个小例子说明原因。

假设两个数据包用相同密钥和相同 nonce 加密，所以用了同一条密钥流 K。

• 密文 1 = 数据包 1 XOR K
• 密文 2 = 数据包 2 XOR K

观察者把两段密文做 XOR，K 就被抵消了：密文 1 XOR 密文 2 = 数据包 1 XOR 数据包 2。秘密密钥没有泄露，但两份明文之间的关系暴露了。如果观察者能猜出或本来就知道其中一个包，比如它以可预测的协议头开头，另一个包的内容就暴露了。Poly1305 的一次性密钥也会被重复使用，从而削弱认证。

设计良好的 VPN 软件从结构上避免了这一点。以 WireGuard 为例，它用递增的数据包计数器作为 nonce，所以同一会话密钥下每个包的 nonce 都是新的。计数器接近上限，或者经过较短时间后，会话会重新协商，用新密钥替换旧密钥。你不需要做任何事，但这很好地说明了为什么要对自己拼凑的 VPN 代码保持警惕：它们用非标准的方式使用标准算法。算法有多安全，取决于它周围的规则。

为什么 VPN 在手机和路由器上喜欢它

ChaCha20-Poly1305 在 VPN 中受欢迎，有两个原因。

不依赖特殊硬件也很快。 最常见的替代品是 AES。当处理器带有专用 AES 指令时，它非常快，大多数现代笔记本、台式机和较新的手机都有。在没有这类指令的处理器上，软件实现的 AES 更慢，也更难防御计时攻击。ChaCha20 只用每种处理器都擅长的简单运算，而且很适合在手机和桌面芯片的 SIMD 单元上并行处理。在老手机、低价路由器和许多嵌入式设备上，这可能意味着相同工作下吞吐量明显更好、CPU 占用更低。

恒定时间运行。 使用查表的软件版 AES，可能通过内存访问耗时泄露信息，这类攻击叫缓存计时攻击。ChaCha20 没有查表，也没有依赖秘密值的分支，所以天然能抵御这类泄露，无需额外下功夫。

在带有 AES 硬件的当代手机上，实际差异很小，不要指望仅凭算法就能看到速度变化。拖慢 VPN 的大多是网络距离、拥塞和封装开销，而不是算法。如果你想了解真正的原因，可以阅读 为什么使用 VPN 后网速会变化 和 VPN 会耗电吗。

你会在哪里遇到它

ChaCha20-Poly1305 并不冷门，它出现在 VPN 用户会接触的好几个地方。

• WireGuard。 这个协议用 ChaCha20-Poly1305 加密数据，并搭配其他固定的组件完成密钥交换和哈希。设计在 WireGuard 白皮书中有说明。因为选择是固定的，所以没有算法菜单可以配置错。这也是 WireGuard 被认为便于审计的原因之一。可以在 WireGuard 与 OpenVPN 中与 OpenVPN 更灵活的设计对照。
• TLS 1.3。 保护网页浏览的标准把 ChaCha20-Poly1305 列在密码套件中（RFC 8446），所以许多 HTTPS 连接，包括在 VPN 隧道内运行的那些，可能已经在使用它。
• OpenVPN。 较新的版本可以把它作为数据通道的加密算法，与基于 AES 的选项并列。
• 其他工具。 许多即时通讯应用、SSH 实现和操作系统组件都包含它。

这种广泛采用很重要。浏览器、操作系统和安全工具都在使用的算法，会被非常多的人检验，漏洞就是这样被发现和修复的。

ChaCha20-Poly1305 与 AES-256-GCM 对比

项目	ChaCha20-Poly1305	AES-256-GCM
类型	流密码加 Poly1305 认证码	计数器模式的分组密码加 GCM 认证
密钥长度	256 位	256 位
nonce 长度	96 位	通常 96 位
认证标签	16 字节	通常 16 字节
有 AES 硬件时的速度	快	非常快
无 AES 硬件时的速度	快	较慢
侧信道表现	设计上恒定时间	需要硬件或谨慎的代码
用错时的弱点	重复 nonce	重复 nonce

看最后一行。两种算法在 nonce 重复时都会严重失效，所以在“容错”方面没有哪一个更安全。在设计良好的隧道里两者都可以接受，提供其中任何一种的 VPN，并不会自动比提供另一种的更好或更差。合理的结论是：ChaCha20-Poly1305 是一线选择，而不是次等替代品，实现质量比标签上写的名字更重要。

如何看待关于加密算法的宣传

在 VPN 的介绍中看到某种加密算法时，不要比较名字，用下面这份简短的清单。

1. 是否使用带认证的模式？ 找 ChaCha20-Poly1305 或 AES-GCM 这类 AEAD 算法。只写“AES”，并不能说明是否检查完整性。
2. 是否说明了密钥交换？ 算法需要每个会话都有新的共享密钥。看看这款 VPN 是否定期更换密钥并采用前向保密，相关内容见加密概述文章。
3. 宣传是否适度？ “军用级”之类的说法是营销，不是规格。准确的描述会写出算法名称和密钥长度。
4. 软件是否接受审查？ 再强的算法也可能被有漏洞的代码拖垮。公开的规范和已发布的审查报告很有帮助。
5. 宣称的内容与 VPN 实际能做的相符吗？ 加密保护的是你的设备到 VPN 之间的路径，不会向你登录的网站隐藏你的活动，也无法修复一台已被入侵的设备。

同一页面可能还会提到哈希和密钥交换算法。遇到不熟悉的名字，去查规范，不要猜。可靠的密码学都有公开文档。

实际场景

对比应用的手机用户。 玛雅看到两款应用，一款写着 ChaCha20-Poly1305，另一款写着 AES-256-GCM。她担心自己选到了“较弱”的那个。读完上面的对比后，她明白两者都很强，于是改从其他方面决定：条款是否清楚、应用质量、付款方式。

路由器用户。 志强家里有一台处理器普通、没有 AES 硬件的小路由器。他在上面试用 VPN，发现速度中等时 CPU 就被占满。使用 ChaCha20-Poly1305 的隧道，在这台设备上可能比使用 AES 的隧道占用更低的 CPU，因为 ChaCha20 不依赖 AES 指令。不过对路由器来说，最好的办法仍然是在实际设备上测试。VPN 路由器还是 VPN 应用 更广泛地分析了这种取舍。

关注安全的学生。 小林读到量子计算机可能威胁加密，想知道 ChaCha20 是否有危险。目前研究的通常解读是：更大的关注点在于建立密钥的密钥交换，而不是 256 位的对称算法本身。这个话题在 后量子 VPN 加密 中有说明，NIST 也有公开的相关项目。

局限与常见误解

• “算法更强，浏览就更安全。” 算法只是其中一层。钓鱼网站、弱密码和恶意软件不会因它而改变。
• “ChaCha20 是唯一的现代选择。” 它是两种主流选项之一。AES-GCM 同样值得尊重。
• “数字越大越好。” 对这些算法来说 256 位密钥已经绰绰有余。宣称拥有巨大的密钥长度，并不会让隧道比实现良好的标准隧道更安全。
• “加密会隐藏我在用 VPN。” 你所在网络上的观察者通常能看出你连接的是 VPN 服务器，只是读不到内容。
• “算法决定速度。” 距离、负载和 Wi-Fi 质量通常重要得多。
• “我应该调整算法设置。” 除非客服要求，否则别动。与服务器不匹配只会让隧道无法连接。

想实际检查隧道是否按预期工作，可以看 如何检查 VPN 是否在正常工作。

总结

ChaCha20-Poly1305 是一种带认证的加密算法：ChaCha20 用密钥流打乱数据，Poly1305 附上标签，让接收方能拒绝被改动的数据包。它依赖一条严格的规则，绝不对同一密钥重复使用 nonce，好的 VPN 软件会用计数器和定期更换密钥来强制执行。它在普通软件里也很快，设计上能抵抗计时泄露，出现在 WireGuard、TLS 1.3 和较新的 OpenVPN 中。它是与 AES-GCM 同级的强力选择，无论你的 VPN 用的是哪一个，周边设计和诚实的说明都比名字更重要。

如果想在自己的设备上试用加密隧道，下载页面 提供免费应用的链接，价格页面 说明通行证的运作方式。