第1章 加密SDK概述
加密SDK，说白了就是一组现成的加密工具包。你不需要自己去实现RSA、AES这些复杂的算法，直接调API就行。
我刚入行时觉得加密SDK就是个黑盒子，往里丢明文，出来就是密文。后来踩了几次坑才明白，不了解箱子里装的是什么，迟早要出问题。加密SDK的核心就是帮开发者完成数据的机密性、完整性和身份认证这三个目标。
一句话记忆：加密SDK = 封装好的加密算法 + 密钥管理 + 安全策略。
1.1 加密SDK能干什么？
一个成熟的加密SDK，至少提供以下能力：
- 数据加密/解密 — 保护传输和存储的敏感数据
- 数字签名/验签 — 确保数据来源可信、没有被篡改
- 哈希计算 — 做数据完整性校验和指纹提取
- 密钥生成与管理 — 帮你安全地创建、存储、轮换密钥
- 安全随机数 — 密码学意义上的随机，不是Math.random()那种
我在项目中见过有人直接用Java自带的UUID做加密密钥，嗯，结果就是上线三天就被爆破。加密SDK的一个重要价值，就是帮开发者绕开这些低级错误。
1.2 三大加密类型
不管哪个加密SDK，归根结底都跑不出这三种类型。我习惯把它们比作三种不同的锁：
1.2.1 对称加密
加密和解密用同一把钥匙。速度快，适合加解密大量数据。常见的算法有AES、DES、SM4。
但有个要命的问题——密钥怎么安全地送给对方？你想想看，如果把密钥和密文一起发过去，那加密还有什么意义？
| 算法 | 密钥长度 | 特点 |
|---|---|---|
| DES | 56位 | 太短了，现在基本不用 |
| AES | 128/192/256位 | 业界标准，速度快，安全 |
| SM4 | 128位 | 国密标准，国内项目常用 |
⚠ 避坑指南：我曾经遇到过用ECB模式加密图片文件，结果加密后的数据还能隐约看到原图的轮廓。原因是ECB模式下相同的明文块会生成相同的密文块。后来全部改成了GCM或CBC模式。千万、千万别直接拿ECB上生产。
1.2.2 非对称加密
有一对钥匙——公钥公开，私钥自己藏好。公钥加密的数据只有私钥能解开，反过来私钥签名的东西公钥可以验证。
速度比对称加密慢得多，但不需提前共享密钥。我一般用它来解决密钥分发问题：先用非对称加密安全地传输对称密钥，后面用对称加密处理大量数据。这叫“混合加密”，HTTPS就是这么干的。
💡 我建议：RSA密钥长度不要低于2048位。1024位的RSA在2010年左右就已经被证明可以在合理成本内破解。别省那点计算资源。
1.2.3 哈希算法
不是真正的加密，因为不可逆。输入任意长度，输出固定长度（比如SHA-256输出256位）。同样的输入永远得到同样的输出，稍微改一个比特，结果就面目全非。
哈希在数据一致性校验里特别有用。我们可以在加密SDK接入后，定期对两边的数据计算哈希值，对比一下就知道有没有不一致。
- MD5 — 128位，曾经很流行，但已不安全，有碰撞攻击
- SHA-1 — 160位，也有碰撞攻击案例，别用了
- SHA-256 / SHA-3 — 当前推荐，安全无争议
- SM3 — 国密哈希标准，国内合规首选
⚠ 切记：哈希不是用来存密码的！存密码要用bcrypt、scrypt或Argon2这类慢哈希算法。我曾经见过有人只对密码做一次SHA-256就存进数据库，结果泄露后所有用户密码三天内就被彩虹表还原了。慢哈希才能扛住暴力破解。
1.3 三者如何协同工作
在实际的加密SDK里，这三种算法往往混着用。举个常见的场景：
- 客户端用非对称加密（比如RSA）把AES密钥加密后传给服务端
- 双方用这个AES密钥做对称加密传输数据
- 每条消息后面附带一个哈希值，接收方重新算一遍，对比是否一致
你看，非对称负责密钥交换，对称负责效率，哈希负责完整性。谁也离不开谁。
下面这张图能帮你把这三个东西的关系理清楚：
做数据一致性校验，核心就是利用这些加密工具给数据打上“指纹”或“防拆标签”。加密SDK让我们不必从零造轮子，但前提是——你得搞清楚每个轮子该怎么用。