第二章：加密基础知识回顾

做多语言加密 SDK，说白了就是要在不同平台、不同语言之间，把数据保护得严丝合缝。不管你是做移动端、后端还是 IoT，加密这块基础打不牢，后面全白搭。我个人习惯每年都会把对称加密、非对称加密、哈希和 HMAC 这四个老朋友拎出来重新过一遍，每次都能挖到新坑。

2.1 对称加密 — 又快又猛，但钥匙怎么给？

对称加密，就是加密和解密用同一把密钥。像一把钥匙开一把锁，简单粗暴。常用的算法有 AES、DES、3DES、SM4。你们猜现在哪个最主流？AES，没有悬念。DES 太老了，3DES 又慢又笨，SM4 是国标，国内场景必须支持。

我在项目中遇到过，一个团队用 AES-128-ECB 模式加密用户手机号。结果后端解密出来的数据，前面 16 字节对，后面全乱码。一查，ECB 模式把数据切成 16 字节的块，最后一块不足 16 字节直接抛异常了。他们居然没处理填充——PKCS7 Padding 是标配，别忘掉。

对称加密的核心步骤：

• 选算法：AES-256 或 SM4 优先。
• 选模式：GCM（推荐）、CBC、CTR。千万别用 ECB，除非你想被骂。
• 选填充：PKCS7 或 NoPadding（配合流模式）。
• 初始化向量（IV）：每次加密随机生成，长度与块大小一致。
• 密钥管理：别硬编码在代码里。用密钥管理服务或者硬件安全模块。

嗯，这里要强调一点：对称加密的痛点从来不是算法本身，而是密钥分发。你想想，加解密双方怎么拿到同一个密钥？互联网传输不安全，那就得靠非对称加密来帮忙——这就引出了下面的话题。

2.2 非对称加密 — 公钥私钥，一个负责锁一个负责开

非对称加密，也叫公钥密码体制。公钥可以随便发，私钥自己藏着。加密用公钥，解密用私钥；签名的逻辑反过来。

主流算法：RSA、ECC（椭圆曲线）、SM2。RSA 密钥长度至少 2048 位，ECC 用 256 位就能达到同等安全强度。我在做金融接口签名时，用过 ECDSA（基于 ECC 的签名算法），签名长度短，性能好，很适合移动端。但是有一次，我发现服务端验签老失败，排查半天——原来是签名编码格式没对齐。服务端用 DER 编码，客户端用 RAW 编码，两边驴唇不对马嘴。

2.3 哈希函数 — 不是加密，胜似加密

哈希，也叫散列，它把任意长度的输入转成固定长度的指纹，过程不可逆。SHA-256、SHA-3、SM3 都是常见算法。

别看它不加密，用处却大得很：密码存储、数据完整性校验、文件对比、数字签名的前置步骤。我记得接手过一个遗留系统，密码直接用 MD5 存。交到我手里的时候，我已经替那批用户捏了把冷汗——MD5 早就能秒破了。二话不说，全部迁移到 bcrypt 或者 Argon2，并且加盐。

哈希的几个重要特征：

• 确定性：同一输入，永远同一输出。
• 雪崩效应：改一个比特，输出完全变样。
• 抗碰撞：找到两个不同输入产生同一哈希值，现实中不可能。
• 不可逆：没法从哈希反推原始输入，除非用彩虹表暴力猜。

为什么不能用哈希直接当消息认证？举个例子：我发一条消息和它的 SHA-256 值。中间人可以把消息改了，同时重新计算哈希值，你收到后校验不出真假。所以我们需要 HMAC——带上密钥的哈希。

2.4 HMAC — 给哈希绑上密钥

HMAC 是 Hash-based Message Authentication Code 的缩写。它把密钥混入哈希计算，解决了单纯哈希无法防篡改的问题。过程简单说：先用密钥和内部填充做第一次哈希，再和外部填充做第二次哈希，双哈希保证安全性。

我在设计 SDK 的接口签名时，就用了 HMAC-SHA256。客户端拿 APP Secret 计算签名，服务端用同样的密钥验证。这比纯哈希安全多了——至少攻击者没有密钥，伪造不了合法请求。

// 一个简单的 HMAC-SHA256 示例（Python）
import hmac
import hashlib

message = b"Hello, 多语言加密 SDK"
key = b"shared-secret-123"
signature = hmac.new(key, message, hashlib.sha256).hexdigest()
print(signature)

实际场景里，密钥长度最好不小于哈希输出长度（比如 SHA-256 输出 32 字节，密钥至少 32 字节）。太短的密钥会导致安全性下降，HMAC 标准里有密钥截断和填充规则，但不建议省这个功夫。

2.5 四者关系一句话总结

写代码的时候，经常需要把这几样组合起来用：非对称加密传递对称密钥，对称加密加密数据，哈希校验文件完整性，HMAC 保障接口通信不被篡改。下面这张图可以帮你把逻辑理清楚：

你看，对称加密负责加解密数据，效率高；非对称加密负责密钥交换或数字签名，安全但慢；哈希提供数据指纹；HMAC 则为消息提供不可抵赖的认证。在 SDK 设计里，我一般会把对称加密配合 HMAC 一起用：用 AES-GCM 同时加密和认证，一步到位。但如果需要兼容老旧系统，就得拆成两轮：AES-CBC 加密 + HMAC 校验，顺序要小心——先加密再 HMAC，不要反着来。