加密基础：对称加密、非对称加密、哈希算法
做过接口安全的同学都知道，加密这事儿绕不开。我刚开始接触权限隔离时，也以为加密就是把数据搅乱。后来踩了不少坑才明白——选错加密方式，比不加密更危险。今天咱们把对称加密、非对称加密、哈希算法这三兄弟掰开揉碎讲清楚。
对称加密
说白了，就是加密和解密用同一把钥匙。你拿它锁门，拿它开门。优点是快，特别快。我曾在高并发场景下用AES做字段级加密，单次加解密耗时不到1微秒。
常见算法：
- AES（Advanced Encryption Standard）—— 目前最主流，密钥长度128/192/256位
- DES —— 太老了，56位密钥，现在基本不用
- 3DES —— DES的改良版，但速度慢，不推荐新项目
- SM4 —— 国密标准，国内项目常要求
我的经验：核心场景用AES-256-GCM模式。GCM自带认证，能防篡改。我几年前用过CBC模式，结果被填充预言攻击搞惨了……那次之后我就只认GCM了。
对称加密的最大痛点 —— 密钥分发。你想想看，通信双方怎么安全地拿到同一把钥匙？如果网络传输密钥，本身就可能被截获。这就是为什么实际项目中很少单独用它。
非对称加密
非对称加密有两把钥匙：公钥和私钥。公钥可以公开，私钥自己藏着。用公钥加密的数据只有对应的私钥能解开；反过来，用私钥签名，公钥能验证。
常见算法：
- RSA —— 最经典，1024/2048/4096位，目前推荐2048位以上
- ECC（椭圆曲线）—— 同样安全级别下密钥更短，性能更好
- SM2 —— 国密椭圆曲线算法，替代RSA
非对称加密解决了密钥分发问题。比如HTTPS握手过程：服务器把公钥给客户端，客户端用它加密一个临时对称密钥，然后双方改用对称加密通信。这就是典型混合加密。我参与过一个物联网项目，设备资源有限，用RSA 2048位做密钥交换，结果设备CPU直接拉满。后来换成ECC，密钥交换耗时从300ms降到了12ms。
注意：非对称加密非常慢，比对称加密慢几百到上千倍。千万不要用它加密大块数据。只适合加密小数据（如对称密钥、哈希值），或者做数字签名。
哈希算法
哈希不是加密。它是单向函数：你把任意长度数据扔进去，吐出一个固定长度的摘要。你没法从摘要反推出原文。这玩意的核心用途是完整性校验和密码存储。
常见算法：
| 算法 | 输出长度 | 安全性 | 典型用途 |
|---|---|---|---|
| MD5 | 128位 | 已破解，勿用 | 仅用于非安全场景（如文件去重） |
| SHA-1 | 160位 | 已发现碰撞攻击 | 已不推荐 |
| SHA-256 | 256位 | 目前安全 | 数据完整性、数字签名 |
| SHA-3 | 可变 | 新一代标准 | 新系统推荐 |
| SM3 | 256位 | 国密标准 | 国内合规场景 |
哈希算法有个特性：雪崩效应。输入改一个bit，输出完全不同。这保证了即使攻击者知道哈希算法，也无法反向推断原文。
实战建议：存储用户密码时，别直接对密码做SHA-256。必须加盐（每个用户唯一盐值），并且迭代多次（比如bcrypt、PBKDF2、Argon2）。我曾经接手过一个旧项目，密码就存了个MD5……结果被脱库后，彩虹表一查一个准。后来全部重写。
三种加密方式对比
| 维度 | 对称加密 | 非对称加密 | 哈希算法 |
|---|---|---|---|
| 密钥数量 | 1个（共享密钥） | 2个（公钥+私钥） | 无密钥 |
| 是否可逆 | 是 | 是 | 否（单向） |
| 速度 | 快（微秒级） | 慢（毫秒级） | 快（微秒级） |
| 典型场景 | 大批量数据传输加密 | 密钥交换、数字签名、身份认证 | 密码存储、数据完整性校验、消息摘要 |
| 密钥管理复杂度 | 高（需安全分发） | 低（公钥可公开） | 不涉及 |
实战选择建议
嗯，到了最后，面对具体场景该怎么选？我列几条铁律：
- 传输大量数据 → 对称加密（AES-256-GCM），密钥通过非对称或密钥协商协议交换。
- 身份认证 / 数字签名 → 非对称加密（ECC优先），配合哈希做签名。
- 用户密码存储 → 哈希算法，必须加盐，使用慢哈希函数（bcrypt、argon2）。
- 数据完整性校验 → 哈希算法（SHA-256以上），但注意配合数字签名防伪造。
我曾经踩过的坑：一个项目里，业务方要求用SM4加密用户手机号，但密钥写在代码里……这就相当于把门锁钥匙贴在门上。记住，对称加密的密钥必须放在安全的密钥管理服务里，不能硬编码。
今天就聊到这。你想想看，这三样东西单独拿出来都不复杂。但组合起来，就是现代密码体系的骨架。下一轮咱们会把这些基础用在实际的权限隔离接口设计里。明白了这些，后面讲密钥生命周期管理、数字信封、HMAC这些就容易多了。