加密基础：对称加密、非对称加密、哈希、数字签名
说到API网关的加密集成，咱们得先把底子打牢。加密这玩意儿，说白了就是让数据在传输和存储时，只有该看的人能看懂。我自己最早接触加密是做支付接口，那时候被各种术语绕得晕头转向，后来发现核心就那么几种武器——对称加密、非对称加密、哈希、数字签名。
对称加密：一把钥匙开一把锁
对称加密最简单，加密和解密用同一把密钥。就像你家大门钥匙——自己锁门，自己开门。算法里最常见的就数 AES（Advanced Encryption Standard） 了。
关键指标：AES-256 是目前业界公认的黄金标准。密钥长度256位，暴力破解需要远超宇宙年龄的时间。
但我得提醒你一句——对称加密的弱点也很明显。密钥怎么安全地传给对方？我当年做某个内部系统时，直接把密钥写死在配置文件里，结果被安全审计骂得狗血淋头。对称加密速度快，适合加密大量数据，但密钥分发是永远的痛。
实战建议：在API网关中，对称加密常用于加密请求体或响应体，密钥通常通过非对称加密的方式来交换。千万别硬编码！
非对称加密：公钥私钥各司其职
非对称加密来了，它解决了密钥分发的难题。一对钥匙：公钥随便发，私钥自己藏。你用我的公钥加密数据，只有我的私钥能解开。反过来，我用私钥签名，你用公钥验证签名。
常见的算法有 RSA 和 ECC（椭圆曲线加密）。RSA 很成熟，但密钥越长性能越差；ECC 用更短的密钥达到同等安全强度——256位的ECC相当于3072位的RSA。
| 特性 | RSA-2048 | ECC-256（P-256） |
|---|---|---|
| 密钥长度 | 2048 bits | 256 bits |
| 安全强度 | 约112 bits | 约128 bits |
| 加密/签名速度 | 较慢（尤其解密） | 快 |
| API网关适用场景 | 兼容性要求高的环境 | 移动端/性能敏感场景 |
避坑指南：我曾经在网关里混用RSA密钥对做签名验证时，没注意公钥格式是PEM还是DER，结果线上签名验证失败，排查了一下午。记住——密钥格式、填充模式（如OAEP vs PKCS#1 v1.5）必须严格对齐。
哈希：单向的指纹
哈希不是加密，它不可逆。你把任意长度的数据扔进去，吐出一个固定长度的摘要。就像给文件打指纹——哪怕只改一个比特，指纹全变。
- MD5：128位，已经被撞库攻破，别再用。
- SHA-1：160位，谷歌已经做过碰撞演示，淘汰。
- SHA-256 / SHA-3：512位，目前安全可靠，API网关里的签名哈希基本用它们。
我在项目中经常用哈希做两件事：验证数据完整性（下载文件校验哈希）、和密码存储（加盐哈希）。但哈希本身不提供身份认证——任何人拿到数据都能计算哈希，所以需要跟数字签名搭配。
数字签名：谁说这是你写的？
数字签名 = 哈希 + 非对称加密。步骤很简单：
- 发送方对消息做哈希，得到摘要
- 用私钥加密这个摘要，得到签名
- 接收方用公钥解密签名，得到摘要A
- 对收到的消息重新计算哈希，得到摘要B
- 比较A和B，一致则验签通过
这玩意儿在API网关里无处不在。比如JWT的签名部分，就是按这个流程来的。我调试过一个案例：客户端传的JWT明明在自己机器上验证通过，到网关就报签名无效。最后发现是字符编码问题——JSON序列化时字段顺序不一致，导致签名前的载荷字节流不同。开源库通常做了规范，但你手拼签名时一定要小心规范化。
整张知识地图
这些基础概念不是孤立的。我画了一张图帮你建立整体认知，你看看它们的定位和关系：
在实践中如何选择
在API网关里，你不会孤立使用其中一种。实际场景往往是混合的：
一个典型场景：客户端用HTTPs（TLS握手时用非对称加密交换对称密钥），然后使用对称加密（AES-GCM）加密API请求体，最后对整个请求用客户端私钥签名，网关用公钥验签。四件套全用上了。
我个人习惯在网关层统一使用ECDSA-P256做签名算法，因为它比RSA快，而且密钥短。但注意兼容性——有些老旧客户端不支持ECC，你可能会需要降级到RSA。嗯，这里有个经验：提前在网关配置里做算法协商列表，不要硬编码。
写在最后
加密不是魔法，是组合使用的基础设施。你把对称加密、非对称加密、哈希、数字签名这四样理解透了，后面讲TLS、JWT、API签名等就顺理成章。记住一条底线：不要自己造算法，用标准库和成熟算法。我在刚入行时差点手写了一个“加密算法”，现在想起来后背发凉——你能想到的漏洞，前人已经倒在坑里了。