第2章 加密基础：对称加密与非对称加密、加密模式、填充方式
加密是个老话题了，但每次做API改造都能遇到新坑。这一章我们只聊跟REST显式加密直接相关的几种加密技术。说白了，就是你要懂怎么选算法、怎么配模式、怎么补数据，才能在API里把加密用对。
2.1 对称加密
对称加密，加密和解密用的是同一个密钥。就像你家的防盗门，用同一把钥匙锁上、打开。
常见的对称算法有：
- AES（高级加密标准）—— 目前主流，密钥长度128/192/256位
- DES —— 56位密钥，太短了，别用了
- 3DES —— DES的加强版，但效率低，也在逐步淘汰
- SM4 —— 国标，国内合规场景必选
我早期做支付接口时图省事用过DES，后来安全审计直接亮了红灯。嗯，从那以后我再也没碰过DES。AES-256是我现在的默认选项。
2.2 非对称加密
非对称加密有一对密钥：公钥和私钥。公钥可以公开，私钥自己藏好。用公钥加密的数据，只有对应的私钥能解开。
常见算法：
- RSA —— 应用最广，密钥长度2048位起步
- ECC（椭圆曲线） —— 同等安全强度下密钥更短，性能更好
- SM2 —— 国标，基于ECC
我个人习惯在移动端优先选用ECC。为什么？移动端计算资源有限，ECC的密钥更短，握手更快。服务器端用RSA多一些，兼容性更好。
非对称加密解决了密钥分发问题，但速度比对称加密慢两到三个数量级。所以实际项目中，没人直接用RSA去加密几十KB的请求体。
2.3 加密模式
加密模式决定了怎么对数据进行分块加密。选错了模式，就算算法再强，也容易出安全漏洞。
我曾在项目中遇到过ECB模式的问题。当时图省事，直接用了ECB，结果密文里能看出明文的轮廓——同样的明文块产生同样的密文块。安全审计直接给了个高危。嗯，后来老老实实改成了GCM。
| 模式 | 是否需要IV | 支持并行 | 带认证 | 安全性 | 推荐场景 |
|---|---|---|---|---|---|
| ECB | 否 | 是 | 否 | 低 | 不推荐，避免使用 |
| CBC | 是 | 否 | 否 | 中 | 文件加密（配合HMAC） |
| GCM | 是 | 是 | 是 | 高 | REST API加密（首选） |
| CTR | 是 | 是 | 否 | 高 | 流式加密（配合HMAC） |
2.4 填充方式
块加密算法要求明文长度是块大小的整数倍。AES的块大小是16字节。不是16的倍数怎么办？填充。
常见的填充方式：
- PKCS7 —— 缺n个字节就填n。最常用，也是我推荐的方式。
- NoPadding —— 不做填充。要求明文长度刚好是块大小的整数倍。
- ISO10126 —— 最后一个字节填填充长度，其余填随机数。这个标准已经退役了。
- ZeroPadding —— 填0x00。注意：如果原始数据末尾就有0x00，解密后无法区分。
我曾经踩过PKCS7的坑。两个系统联调，一个用PKCS7填充，另一个用ZeroPadding。解密出来尾部一堆乱码，排查了半天才发现是填充方式不匹配。你想想看，这种问题在日志里根本看不出，只能逐字节对比。
说到这，你会发现对称加密、非对称加密、加密模式、填充方式这四个东西是绑在一起的。选AES-GCM + PKCS7（或直接用GCM内置机制），是我目前在REST API加密项目里的标配。后面章节我会具体讲怎么在API请求里落地这套组合。