第四节：哈希函数与完整性
各位同学，今天我们来聊聊哈希函数。说实话，这是整个安全通信里我最喜欢的一块。为什么？因为它看起来简单，但坑特别多。我在项目里见过太多人把哈希当加密用，结果出了大问题。
4.1 哈希函数的核心特性
哈希函数，说白了就是一个「数据指纹」生成器。你给它任意长度的数据，它给你一个固定长度的摘要。就像人的指纹一样，理论上每个数据都应该有独一无二的摘要。
这里有两个核心特性，我建议大家刻在脑子里：
- 单向性：从哈希值反推原始数据，几乎不可能。嗯，我说的是「几乎」，理论上存在暴力破解的可能，但计算量大到不现实。
- 抗碰撞性：找到两个不同数据，但哈希值相同，这很难。这里又分两种：弱抗碰撞（给定一个数据，找另一个碰撞）和强抗碰撞（随便找两个碰撞）。
重要概念区分：哈希不是加密！加密是可逆的，哈希不可逆。我见过有同事把用户密码用哈希存了，然后跟我说「加密存储」——这其实是哈希存储，两者性质完全不同。
为什么会这样设计？你想想看，如果哈希可逆，那存密码还有什么意义？攻击者拿到数据库直接还原所有密码，那不就全完了。
4.2 常见哈希算法
这些年我用过的哈希算法不少，挑三个最有代表性的说说。
4.2.1 MD5——曾经的王者，现在的警示
MD5 输出 128 位，曾经是主流。但早在 2004 年，中国学者王小云就找到了有效的碰撞方法。我在 2018 年做过一个实验：用普通笔记本，几分钟就能生成两个不同文件但 MD5 相同的样本。
避坑指南：我曾经接手过一个遗留系统，里面还在用 MD5 做文件完整性校验。结果发现攻击者可以替换文件同时保持 MD5 不变。赶紧全部换成了 SHA-256。如果你现在还在用 MD5，我建议你立刻开始迁移计划。
4.2.2 SHA-256——当前工业标准
SHA-256 输出 256 位，属于 SHA-2 家族。目前没有公开的有效攻击方法。比特币挖矿用的就是 SHA-256，你可以想象它的计算强度。
我个人习惯，所有新项目默认用 SHA-256。除非有特殊性能要求，否则不要轻易换。
4.2.3 SM3——国标之选
SM3 是中国国家密码管理局发布的哈希算法，输出 256 位。它的设计思路和 SHA-256 类似，但具体实现有差异。在政府项目、金融系统里，SM3 是强制要求。
| 算法 | 输出长度 | 安全性 | 推荐场景 |
|---|---|---|---|
| MD5 | 128 位 | 已破解，不推荐 | 仅用于非安全场景（如校验下载完整性，但需配合其他措施） |
| SHA-256 | 256 位 | 安全 | 通用场景，国际标准 |
| SM3 | 256 位 | 安全 | 国密合规场景 |
4.3 消息认证码（HMAC）
光有哈希还不够。你想想看，如果只是把文件哈希值发过去，中间人完全可以同时替换文件和哈希值。这时候就需要 HMAC 了。
HMAC 的核心思想是：哈希计算时混入一个只有通信双方知道的密钥。公式大致是：
HMAC(K, M) = H( (K' ⊕ opad) || H( (K' ⊕ ipad) || M ) )其中 K 是密钥，M 是消息，H 是哈希函数。看着复杂？其实逻辑很简单：
- 把密钥和消息「揉」在一起再哈希
- 没有密钥的人无法伪造合法的 HMAC
- 即使知道 HMAC 值，也无法反推密钥
实战经验：我在做 API 签名时，常用 HMAC-SHA256。客户端用密钥对请求参数计算 HMAC，服务端用同样的密钥验证。这样既能保证数据完整性，又能验证身份。注意：密钥绝对不能明文传输，一般通过离线方式或密钥协商协议分发。
4.4 实际应用中的注意事项
说了这么多理论，来点实际的。我在项目中踩过的坑：
- 哈希长度扩展攻击：MD5、SHA-1、SHA-256 都存在这个问题。简单说，知道 H(M) 和 M 长度，就能算出 H(M || padding || extra)。HMAC 可以防御这种攻击。
- 彩虹表攻击：如果只是简单哈希密码，攻击者可以用预计算的哈希表快速破解。解决方案是加盐（salt），每个用户用不同的随机盐值。
- 性能陷阱：哈希计算不是免费的。我曾经优化过一个系统，发现大量时间花在重复计算相同数据的哈希上。加个缓存，性能提升明显。
核心原则：完整性保护不是「用了哈希就完事」。你需要考虑：用什么算法？密钥怎么管理？有没有重放攻击风险？HMAC 的密钥多久轮换一次？这些细节决定了一个方案是否真正安全。
好了，哈希函数这块就讲到这里。记住一句话：哈希是完整性保护的基石，但基石也要打牢。选对算法、用对模式、管好密钥，这三件事缺一不可。