3. 常见加密算法：对称、非对称、哈希
好，咱们来聊聊加密世界里最基础也最核心的三类算法。说白了，搞渗透测试也好，做安全开发也好，这几样东西基本是天天要打交道的。我先捋个大的框架图，然后咱们一个一个掰开讲。
3.1 对称加密：一把钥匙开一把锁
对称加密，加密和解密用的是同一把钥匙。就像你家里的房门钥匙——开门关门都靠它。速度快，适合处理大量数据，但密钥怎么安全交给对方是个麻烦事。
我做过一个移动端的渗透测试项目，对方用了 AES-CBC 模式加密本地数据库。密钥硬编码在 native 层里。嗯，说实话，我当时用 Frida 一把梭就 Hook 到了，直接把密钥打印出来。这里要吸取的教训是：对称加密的安全性完全取决于密钥保管。
常见对称算法对比
| 算法 | 密钥长度 | 分组大小 | 速度 | 安全性 |
|---|---|---|---|---|
| AES | 128/192/256 bits | 128 bits | 极快 | 高（公认安全） |
| DES | 56 bits | 64 bits | 快 | 低（已被破解） |
| 3DES | 112/168 bits | 64 bits | 较慢 | 中等（已不推荐） |
| SM4 | 128 bits | 128 bits | 快 | 国标，安全性好 |
渗透测试要点：
- 检查密钥是否硬编码在客户端代码或配置文件中
- 查看是否使用了 ECB 模式（明文块独立，容易被重放攻击）
- 验证 IV 是否固定或可预测（CBC 模式下 IV 必须随机）
- 尝试暴力破解弱密钥（比如 DES 的 56 位密钥几小时就能解）
个人习惯：我一般拿到对称加密的请求包，先看看响应有没有类似 {"data":"U2FsdGVkX1..."} 的结构。再抓几个请求对比 IV 和密文的规律。很多人用 AES-ECB 模式还不自知，结果就是每个 block 都能独立解密，你想想看这多危险。
3.2 非对称加密：公钥私钥，各司其职
非对称加密有两把钥匙：公钥公开，私钥保密。用公钥加密的数据，只有私钥能解开；用私钥签名的数据，任何人都可以用公钥验签。解决了对称加密里的密钥分发难题，但速度慢多了——慢到大概只有对称加密的 1/1000。
我在检查一个金融 App 的接口时，发现它用 RSA 加密整个请求体。刚开始觉得挺安全，结果仔细一看——公钥是硬编码在代码里的，而且用的是 1024 位的 RSA。现在 1024 位 RSA 在云上租几台显卡，一周内就能分解。我建议所有新项目至少上 RSA-2048 或者换 ECC。
非对称算法对比
| 算法 | 安全密钥长度 | 速度 | 主要用途 | 注意事项 |
|---|---|---|---|---|
| RSA | 2048+ bits | 较慢 | 加密、签名 | 密钥长，计算消耗大 |
| ECC | 256+ bits | 较快 | 加密、签名 | 同等安全下密钥更短 |
| SM2 | 256 bits | 快 | 加密、签名（国密） | 国内合规场景首选 |
| DSA | 2048+ bits | 慢 | 仅签名 | 不能加密，已属老旧 |
我曾经踩过的坑：
有次在调一个支付回调接口，对方说用 RSA 签名验证。我写代码逻辑发现怎么验都过不了——折腾半天才发现，对方把签名算法写成了 MD5withRSA，而我用的是 SHA256withRSA。所以务必在接口文档里明确签名算法名称，不然两边对不上，排查起来真能要你命。
渗透测试关键点：
- 检查公钥是否可被替换或篡改（中间人攻击）
- 验证签名是否对原始数据进行完整校验（防止签名剥离攻击）
- 测试是否能通过重放签名包绕过身份验证
- 检查是否使用了足够长的密钥（RSA 至少 2048，ECC 至少 256）
3.3 哈希算法：单向的“指纹”
哈希算法不是加密——它没有密钥，不可逆。输入任意长度数据，输出固定长度的摘要（比如 256 位）。同一输入得到同一输出，输入稍微改一点点，输出就天翻地覆。它的核心用途是完整性校验和密码存储。
渗透测试的时候我最喜欢看密码存储用的是什么哈希。如果看到 md5(plaintext) 就存进去的，基本可以直接确认高危漏洞——彩虹表一秒钟就撞出来了。正经做法是加盐（salt）并迭代多次，比如 bcrypt 或 argon2。
常见哈希算法
| 算法 | 输出长度 | 安全性 | 推荐场景 |
|---|---|---|---|
| MD5 | 128 bits | 极低（碰撞攻击已成功） | 不可用于安全场景（仅校验非对抗性数据） |
| SHA-1 | 160 bits | 低（已知碰撞） | 已废弃 |
| SHA-256 | 256 bits | 高 | 签名、完整性、密码（搭配 PBKDF2） |
| SHA-3 | 可定制 | 高 | 新一代标准，逐步推广 |
| SM3 | 256 bits | 高 | 国密算法，国内合规场景 |
一个小技巧：在测试接口时如果看到 sign=...×tamp=...，那大概率是拿所有参数按字典序排序后拼上签名密钥，然后做一次哈希。你可以尝试把 timestamp 改成负数或者极大值，看后端有没有做校验——很多前端防篡改，后端根本没验，这就是漏洞。
3.4 三种算法的组合：实战中的护城河
单一算法往往扛不住真实攻击。想想看——你能用对称加密直接传数据，但密钥怎么安全送达？可以用非对称加密先交换对称密钥。那传输过程中数据被篡改了怎么办？再加一层哈希做完整性校验。这就是 HTTPS 的核心原理：非对称交换对称密钥（TLS 握手），对称加密传输数据，MAC（哈希）保证报文完整。
我在某次红蓝对抗中，模拟攻击者截获了一台物联网设备的升级包，发现设备只验证了固件哈希，没验证签名。我直接改掉固件内容，重新计算 SHA-256 哈希放进去，结果设备就「愉快」地升级了我的后门固件。这件事让我深刻理解：哈希只防无意的传输错误，防不了恶意的篡改——一定要配合数字签名。
推荐组合方案：
- 密钥协商：使用 ECDH + 临时密钥（PFS，前向安全性）
- 数据传输：AES-256-GCM（带认证加密，同时提供机密性与完整性）
- 签名：ECDSA 或 Ed25519
- 密码存储：bcrypt / argon2 或 PBKDF2 + 随机盐
嗯，这一章的内容就到这里。三种算法好比安全工具箱里的三把扳手——什么时候用哪一把，怎么搭配，心里得有数。下次你碰到加密接口，拿这些知识去套，肯定不会一头雾水。