4. 加密技术选型：对称加密、非对称加密、哈希与HMAC
聊到隐私增强网关，加密技术就是它的地基。你想想看，所有进出的流量最终都要依赖加密算法来保护。这一章，我就把常用的几类加密技术掰开揉碎了讲，包括它们怎么用、用在哪儿、有什么坑。
4.1 对称加密：速度与安全的平衡点
对称加密，说白了就是两边用同一个钥匙开锁。你加密用这把钥匙，我解密也用同一把。速度非常快，特别适合处理大批量数据。
我在项目中遇到过一个场景——内部日志管道需要实时加密传输。那时候流量每秒上百MB，如果拿非对称加密去搞，CPU直接跑满。最后只能上对称加密，选的是AES-256-GCM。
| 算法 | 密钥长度 | 工作模式 | 典型场景 |
|---|---|---|---|
| AES | 128 / 256 bit | GCM, CBC, CTR | 传输加密、静态数据加密 |
| ChaCha20 | 256 bit | Poly1305 | 移动端、弱硬件环境 |
| SM4 | 128 bit | CBC, GCM | 国密合规场景 |
这里有个避坑指南：不要用ECB模式。ECB把明文切成一块一块单独加密，同样的明文块会产出同样的密文块——这等于把数据模式暴露给攻击者。我曾经在一个旧系统里见过ECB加密的用户头像，密文图像轮廓还能看出来，这就完全没有隐私可言了。
4.2 非对称加密：密钥分发的救星
对称加密虽然快，但密钥怎么安全地传给对方呢？这就是非对称加密上场的时候了。
非对称加密用一对钥匙：公钥公开，私钥自己藏着。你用我的公钥加密，只有我的私钥能解开。
我个人习惯把非对称加密看作“握手工具”——它不适合直接加密大文件，因为性能开销太大（通常比对称加密慢2-3个数量级）。合理的做法是：先用非对称加密交换一个临时的对称密钥，然后用这个对称密钥加密实际数据。这就是TLS握手的过程，也是混合加密的核心思路。
混合加密流程：
- 客户端生成临时对称密钥（比如AES 256位密钥）
- 用服务器的RSA公钥加密这个对称密钥
- 服务器用私钥解密，拿到对称密钥
- 双方用这个对称密钥进行后续的批量加密通信
记得有一个项目，我们内部搭建了PKI体系。运维图省事，把RSA密钥对生成后直接存在Git仓库里。结果代码泄露后，所有历史通信数据都能被解密。嗯，这里要注意：私钥物理安全是底线，不能偷懒。
4.3 哈希与HMAC：完整性验证的利器
哈希函数不是加密。它把任意长度的数据压缩成固定长度的摘要，而且理论上不可逆。你没法从摘要反推出原始数据。
哈希的典型用途有两个：校验文件完整性、存储密码。我遇到过有人拿MD5存用户密码——这等于把密码写在墙上。MD5碰撞攻击早已成熟，彩虹表一查就知道原始密码是什么。
| 算法 | 输出长度 | 安全性 | 建议场景 |
|---|---|---|---|
| SHA-256 | 256 bit | 高 | 证书签名、完整性校验 |
| SHA-3 | 可配置 | 高 | 新型系统、抗量子攻击（远期） |
| MD5 / SHA-1 | 128 / 160 bit | 已攻破 | 不推荐使用 |
那HMAC又是什么呢？它是哈希的升级版——在哈希的过程中混入了一个密钥。没有这个密钥，你就算知道哈希算法也算不出正确的MAC值。这在网关场景里特别有用：两个服务之间交换消息，加个HMAC就能判断这条消息是不是真的来自对方，中途有没有被篡改过。
避坑提示：曾经有一个团队把哈希和HMAC混为一谈。他们想验证API请求的合法性，直接用SHA-256哈希请求体，然后把哈希值放在Header里。结果攻击者只要知道参数结构就能伪造哈希，因为哈希不需要密钥。正确的做法是用HMAC-SHA256，密钥只放在客户端和服务端两边。
4.4 核心知识体系图
下面这张图把四种加密技术和它们的主要用途串起来了。你可以当作选型时的参考地图。
4.5 实践选型清单
最后给你一个我自己在项目里反复验证过的选型清单。遇到具体场景时，直接对照这几点就好。
- 传输大量数据 → 对称加密（优先AES-256-GCM，带身份验证标签）
- 密钥交换/身份认证 → 非对称加密（ECC比RSA效率高，推荐X25519）
- 校验文件或消息是否被改过 → 哈希（SHA-256够用，不需要更长）
- 防消息伪造 → HMAC-SHA256（双方共享密钥，攻击者无法伪造）
- 存储密码 → 用bcrypt或Argon2，不要直接哈希
- 国密合规 → SM2+SM3+SM4组合，算法选型不变，换标准而已
我个人习惯在网关项目里先用对称加密把所有请求体加密，外层包一个HMAC做完整性校验，再通过非对称加密交换临时密钥。这样三层防护下来，基本覆盖了机密性、完整性和身份验证三个维度。测试环境可以放开一点，生产环境这套组合拳尽量不要砍。