第二讲：加密基础回顾——对称、非对称、哈希算法归纳总结
说实话，带过几十个加密落地项目后，我最怕遇到一种情况：团队里有人把三种算法混为一谈。
“反正都是加密，随便选一个不就行了？”
嗯，每次听到这句话，我血压就上来了。所以今天这一讲，咱们把对称加密、非对称加密、哈希算法彻底掰扯清楚。你想想看，连地基都没打牢，后面的密钥管理、证书体系、性能调优全得塌。
1. 对称加密：最简单，也最容易出事
说白了，对称加密就是一把钥匙开一把锁。加密和解密用的是同一个密钥。你就想象一下，家里大门只有一把钥匙，出门得揣兜里，万一丢了，小偷就进屋了。
我个人习惯，先从算法分类聊起：
- 流加密：按字节流加密。代表是 RC4，但现在已经不推荐用了。我记得早些年有个客户还在用 RC4 做 VPN 加密，我直接建议他们立刻升级。为啥？RC4 的偏置已经被破解了，属于“一捅就破”的纸老虎。
- 块加密：把数据切块，每块单独加密。主流是 AES。
块加密里，还得选个加密模式。我简单列了张表，是我项目里最常用的几种：
| 模式 | 工作原理 | 常见用途 | 我踩过的坑 |
|---|---|---|---|
| ECB | 每块独立加密 | 基本别用 | 同样的明文块，出来同样的密文。攻击者一看就知道加密前长啥样。我曾经见过一个退款系统用 ECB 加密订单号，这跟没加密没区别。 |
| CBC | 前一块密文作为下一块输入 | 文件加密、数据库加密 | 需要初始向量 IV，且 IV 不能重复。有次上线前才发现开发把 IV 写死在代码里了……嗯，后面的事你自己想。 |
| GCM | 加上认证标签，能防篡改 | 网络传输、API 加密 | 强烈推荐。既能加密又能校验，省去单独做 MAC 的麻烦。 |
2. 非对称加密：慢，但解决了最麻烦的问题
对称加密的硬伤是什么？密钥分发。你和你同事各拿一把一模一样的锁，但怎么把这把锁安全地递过去？
非对称加密解决了这个问题。它有两把钥匙：一把公钥，一把私钥。公钥随便发给别人，私钥自己藏好。数据用公钥加密，只有私钥能解开。你想想看，这就好比你在公共邮箱里放了个锁，别人不用给你钥匙，直接把信锁进去就行。
项目里最常用的算法就这几种：
- RSA：老前辈了，2048 位起步，4096 位更保险。但真的慢。我做过一个性能测试，RSA-2048 算一次签名，够 AES-256 加密 10 万次。所以千万别拿 RSA 去加密大文件，它只适合加密对称密钥或签名。
- ECC：椭圆曲线，256 位密钥强度相当于 RSA-3072。效率高得多。现在 FIPS 186-5 都推荐 ECC 了。
- SM2：国产算法，结构上类似 ECC。政府项目绕不开。
我记得有一次，客户非要用 RSA 做全量数据加密，结果接口延迟飙到 3 秒。我跟他们说：“RSA 不是拿来推土机的，是拿来切钻石的。”最后改成“RSA 加密会话密钥 + AES 加密数据”的混合方案，延迟降到 30 毫秒。
3. 哈希算法：不是加密，但比你想象的更重要
先澄清一个概念：哈希不是加密。加密是可逆的，哈希不可逆。
哈希算法做的事是：把任意长度的数据，变成固定长度的指纹（摘要）。哪怕你改一个比特，整个指纹就变了。
它的核心用途有三个：
- 数据完整性校验：文件下载后比对哈希值，看有没有被篡改。
- 密码存储：不存明文密码，存哈希值。用户登录时只要比对哈希就行。
- 唯一标识：用哈希值做数据的主键或去重。微信支付的商户号我就见过用 SHA-256 生成的。
但目前主流算法的尴尬是：MD5、SHA-1 已经不安全了。MD5 的碰撞攻击早就公开，SHA-1 也在 2017 年被 Google 和 CWI 成功实现碰撞。你想想看，同样的哈希值对应两个不同的文件，这还怎么保证完整性？
| 算法 | 摘要长度 | 安全状态 | 项目建议 |
|---|---|---|---|
| MD5 | 128 位 | 已破解 | 仅用于非安全场景（如文件去重） |
| SHA-1 | 160 位 | 已破解 | 不要在 2024 年之后再用 |
| SHA-256 | 256 位 | 安全 | 通用推荐 |
| SHA-3 | 可变 | 安全 | 如果 SHA-2 算法有专利顾虑，可以选用 |
| SM3 | 256 位 | 安全 | 国内合规首选 |
// 一个项目中用于密码存储的伪代码示例
// 使用了 bcrypt 算法，内建随机盐值和成本因子
var password = "UserInputPass123";
var salt = bcrypt.gensalt(12); // 12 轮迭代，成本适中
var hash = bcrypt.hash(password, salt);
// 验证阶段
boolean isValid = bcrypt.verify(password, storedHash);
注意上面这个例子，盐值自动生成、自动附着在哈希结果里，你就不用自己管理盐了。这是项目里快速落地的常见做法。
4. 三者的关系：谁也不能替代谁
我经常在项目启动会上画一张图，把三者的关系讲清楚。你看下面的结构：
看到没有？对称、非对称、哈希，三者在项目里是配合关系，不是替代关系。
- 对称加密负责“快”——加密实际数据。
- 非对称加密负责“可靠”——解决密钥分发、数字签名。
- 哈希负责“校验”——保证数据没被篡改，密码安全存储。
举个例子你就明白了：当你要安全传一个文件时，先用 SHA-256 算出文件的哈希值，再用自己的私钥对哈希值签名（非对称），然后用接收方的公钥加密对称密钥，再用对称密钥加密文件本身。最后把所有东西打包发过去。对方拿到后，反向操作，逐一验证。这是 TLS 握手的简化版本。