对称加密与非对称加密：算法原理、密钥交换、混合加密体系
这一章我们聊聊加密的核心——对称加密和非对称加密。说实话，这两个概念你早晚都得彻底搞明白，因为整个TLS握手、双向认证的底层全是它们。我当年刚接触密码学时，觉得对称加密简单得不行，直到第一个项目里密钥分发搞砸了才意识到……嗯，这事没那么简单。
对称加密：快，但有个死穴
对称加密，说白了就是加密和解密用同一把钥匙。你拿这把锁锁上箱子，对方拿同一把钥匙打开。速度快得离谱，适合加密大量数据。
主流算法：
- AES（Advanced Encryption Standard）：当前最通用的对称加密算法。密钥长度128/192/256位。我在生产环境里几乎只用AES-256-GCM，既能加密又能校验完整性。
- ChaCha20：Google在移动端推崇的流密码，软件实现性能比AES还快。我记得有一次做IoT设备优化，AES的硬件加速用不了，换ChaCha20后吞吐量直接翻倍。
致命问题：密钥分发。你怎么安全地把这把钥匙交给对方？如果通过网络传，那传输过程本身就是明文的，等于白锁。这就是非对称加密要解决的。
非对称加密：公钥私钥双保险
非对称加密用一对密钥：公钥公开，私钥自己藏好。公钥加密的数据只有对应私钥能解，反过来私钥签名、公钥验签也能做。速度比对称加密慢两三个数量级，所以我们一般只用它来做密钥交换或数字签名。
三大核心算法：
RSA
最经典的公钥算法，基于大整数因数分解的数学难题。密钥长度至少2048位，很多法规现在还要求3072位。不过RSA有个坑——它不能直接加密长数据。我刚开始用的时候，拿RSA加密整个文件，结果直接报错。后来才明白，RSA一次能加密的数据块长度取决于密钥长度，超过就得分段或只用来加密对称密钥。
Diffie-Hellman（DH）
这个算法特别有意思：双方在完全不安全的信道上，通过交换一些中间值，最终算出同一个秘密数字。任何第三方就算截获了所有通信内容，也算不出这个秘密。我最早看DH协议时觉得像变魔术，直到亲手跑了一遍示例代码才理解原理。
但传统DH不具备身份认证能力，容易遭受中间人攻击。所以我建议你只用DH配合数字签名使用，或者直接上ECDH。
ECDH（椭圆曲线 Diffie-Hellman）
用椭圆曲线代数结构替代素数域上的指数运算，同样安全强度下密钥更短（256位ECDH ≈ 3072位RSA），性能更好。现在TLS 1.3默认就使用ECDHE（临时密钥的ECDH）。
混合加密体系：取长补短
真实世界没人只用非对称加密来加密大块数据，太慢了。我们采用混合加密：
- 客户端生成一个随机的对称密钥（比如256位的AES密钥）。
- 用服务器的公钥（RSA或ECDH）加密这个对称密钥，然后发给服务器。
- 服务器用私钥解密，拿到对称密钥。
- 之后双方用这个对称密钥进行快速的对称加密通信。
这就是TLS握手中标准的密钥交换流程。我画了一张图帮你理清思路：
对称 vs 非对称：一张表看清
| 特性 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 双方共用一个密钥 | 公钥+私钥对 |
| 速度 | 极快（硬件加速可达几十Gbps） | 慢（RSA 4096位签名约每秒几百次） |
| 典型算法 | AES, ChaCha20 | RSA, DH, ECDH, ECDSA |
| 主要问题 | 密钥分发困难 | 性能差，不能加密大块数据 |
| TLS中用途 | 加密传输的应用数据 | 密钥交换、身份认证 |
总结上面这些：对称加密是“快而隐匿”，非对称加密是“慢而公开”。混合加密把两者焊接在一起，组成TLS的骨架。你记不记得我开头说密钥分发搞砸的那个项目？当时我就是只顾着用对称加密，却没解决怎么安全传递密钥的问题。后来换成混合加密，用服务器公钥加密对称密钥再传过去，问题就彻底解决了。
嗯，概念部分就这些。下一部分我们会具体看看TLS握手消息里每一步是如何使用这些算法的，不过先把这个基础打牢。记住混合加密的流程——它是整个安全的根基。