1. ChaCha20与Poly1305概述
聊到现代密码学里的对称加密，很多人第一反应还是AES。这很正常，AES统治了加密世界二十多年。但今天我想跟你聊聊另一对组合——ChaCha20和Poly1305。说实话，我第一次接触它们是在做移动端协议优化的时候，当时被它们的性能表现惊到了。
ChaCha20是流密码，负责加密数据。Poly1305是消息认证码（MAC），负责保证数据没被篡改。两者配合，就构成了一个完整的认证加密方案。用我自己的话说，这就像一把锁加一个封条——锁保证别人看不了，封条保证别人动不了。
1.1 从Salsa20到ChaCha20：一个关于改进的故事
ChaCha20不是凭空冒出来的。它的前身叫Salsa20，由密码学家Daniel J. Bernstein在2005年设计。Salsa20参加了eSTREAM竞赛，最终胜出，成为面向软件实现的流密码标准。
我记得第一次读Salsa20的论文时，被它的设计思路吸引了——没有复杂的查表操作，没有硬件专属指令，纯粹靠加法、异或和移位操作。这在当时很前卫，因为AES需要专门的硬件指令才能跑得快，而Salsa20在普通CPU上就能飞起来。
2008年，Bernstein对Salsa20做了改进，推出了ChaCha。改动其实不大，主要是调整了每轮运算中加法和异或的顺序。但就是这个小改动，让ChaCha的扩散性更好，安全性分析也更充分。嗯，这里要注意：ChaCha20中的"20"指的是20轮迭代，不是版本号。
核心区别速览：
| 特性 | Salsa20 | ChaCha20 |
|---|---|---|
| 设计者 | Daniel J. Bernstein | Daniel J. Bernstein |
| 推出年份 | 2005 | 2008 |
| 轮数 | 20轮 | 20轮 |
| 每轮操作 | 行运算→列运算 | 列运算→对角运算 |
| 扩散速度 | 较慢 | 更快 |
| 软件性能 | 优秀 | 更优秀 |
1.2 为什么是ChaCha20 + Poly1305？
你可能会问：AES-GCM不是挺好的吗？为什么还要搞一套新的？
我在项目中遇到过这样一个场景：一个嵌入式设备，CPU不带AES-NI指令集，内存只有几百KB。跑AES-GCM？慢得让人崩溃。换成ChaCha20-Poly1305后，速度提升了将近4倍。说白了，ChaCha20-Poly1305是为没有硬件加速的环境量身定做的。
Poly1305这个MAC算法也很有意思。它基于素数域运算，用128位整数乘法实现。我刚开始实现时觉得它很绕，但跑通之后发现——这玩意儿太优雅了。它不需要查表，不需要复杂的初始化，几行代码就能搞定。
我的个人建议：如果你的项目跑在ARM Cortex-M系列、RISC-V或者老旧x86处理器上，优先考虑ChaCha20-Poly1305。它不需要硬件加速，纯软件实现就能达到很高的吞吐量。
1.3 应用场景：这些协议都在用
ChaCha20-Poly1305不是实验室里的玩具。它已经被多个主流协议采纳，我列几个你肯定知道的：
- TLS 1.3：RFC 8446明确将ChaCha20-Poly1305列为强制实现的密码套件之一。Google Chrome和Firefox都优先使用它。
- SSH：OpenSSH从6.5版本开始支持，现在已经是默认选项之一。
- WireGuard：这个新兴的VPN协议完全基于ChaCha20-Poly1305构建，没有其他备选方案。
- IPsec：RFC 7634定义了如何在IPsec中使用ChaCha20-Poly1305。
为什么会这样？因为这些协议的设计者都看中了一点：安全性高 + 实现简单 + 抗侧信道攻击。AES-GCM在实现不当时容易泄露密钥，而ChaCha20-Poly1305的常数时间实现要容易得多。
避坑提醒：我曾经见过一个项目，把ChaCha20和Poly1305分开实现，然后自己拼凑认证加密。这是大忌！ChaCha20-Poly1305必须作为一个整体使用，分开实现很容易引入nonce重用、密文篡改等漏洞。永远使用标准的AEAD接口。
1.4 知识体系总览
下面这张图是我梳理的本章知识结构。你可以把它当作整个课程的地图：
1.5 为什么你应该学这个？
我见过太多开发者，项目里用了OpenSSL的默认配置，结果性能瓶颈出在加密上。换用ChaCha20-Poly1305后，问题迎刃而解。你想想看，一个不需要硬件加速、实现起来不容易出漏洞、还被各大协议标准采纳的算法，有什么理由不掌握它？
接下来的课程里，我会带你从数学原理开始，一步步用Python实现完整的ChaCha20和Poly1305。不是调库，是从零写起。这样你才能真正理解每一行代码在干什么。
准备好了吗？我们开始吧。