4. 哈希函数与消息认证：SHA-256、HMAC原理，防篡改机制

聊到加密传输，很多人第一反应就是「把数据锁起来」。但有个问题常被忽略——你怎么知道收到的密文，中途没被人动过手脚？

我早年做金融接口时，就吃过这个亏。对方传过来一串报文，解密后金额对不上，排查了半天才发现是中间人把密文里的某个字节改了。虽然解出来是乱码，但业务系统没做完整性校验，直接拿乱码当合法数据处理了……嗯，从那以后，我对「防篡改」这三个字格外敏感。

这一章，我们就来拆解哈希函数和消息认证码。说白了，它们就是数据的「指纹」和「防拆封条」。

4.1 哈希函数：数据的数字指纹

哈希函数，也叫散列函数。它能把任意长度的输入，压缩成固定长度的输出——这个输出就是哈希值，或者叫摘要。

我个人习惯把哈希值比作「指纹」。每个人的指纹长度差不多，但独一无二；你稍微蹭破点皮，指纹就变了。哈希函数也一样：输入差一个比特，输出就面目全非。

一个合格的密码学哈希函数，必须满足三个核心性质：

• 抗原像性：给定哈希值，几乎不可能反推出原始输入。说白了，就是单向的，只能正着算，不能倒着推。
• 抗第二原像性：给定一个输入和它的哈希值，找不到另一个不同的输入，能算出同样的哈希值。这叫「抗碰撞」的弱版本。
• 抗碰撞性：找不到任意两个不同的输入，让它们的哈希值相同。这是强版本，也是安全性的底线。

4.2 SHA-256：目前最主流的哈希算法

SHA-256 属于 SHA-2 家族，输出 256 位（32 字节）的摘要。它在 TLS 证书、区块链、文件校验里随处可见。你想想看，比特币的挖矿核心就是不停地算 SHA-256。

它的内部结构大致是这样的：

1. 填充：把输入消息补到 512 位的整数倍，末尾附加原始长度信息。
2. 分块：每 512 位为一个消息块。
3. 迭代压缩：每个块经过 64 轮运算，更新 8 个 32 位的工作变量。
4. 输出：最后把 8 个变量拼接成 256 位的摘要。

下面我用 Python 演示一下 SHA-256 的基本用法。实际项目中，你直接用标准库就行，千万别自己实现——我见过有人手写 SHA-256 写错了轮函数，调试了三天……

import hashlib

message = b"Hello, this is a secret message."
digest = hashlib.sha256(message).hexdigest()

print(f"原始消息: {message}")
print(f"SHA-256摘要: {digest}")
print(f"摘要长度: {len(digest)} 个十六进制字符")  # 64个字符 = 256位

输出示例：

原始消息: b'Hello, this is a secret message.'
SHA-256摘要: 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
摘要长度: 64 个十六进制字符

你试着改一下消息里的任何一个字符，哪怕只改一个字母的大小写，摘要就会完全不一样。这就是所谓的「雪崩效应」。

4.3 哈希的局限性：光有指纹不够

哈希函数能保证数据没被改过吗？能，但有个前提——你拿到的哈希值本身必须是可信的。

举个例子：我发给你一个文件，同时把它的 SHA-256 摘要贴在了网站上。你下载文件后自己算一遍摘要，跟网站上的对比，一致就说明文件没被篡改。这个逻辑成立，是因为网站是可信的。

但如果攻击者同时篡改了文件和网站上的摘要呢？或者，攻击者在传输过程中把文件和摘要一起替换了呢？

这就是哈希函数的软肋——它不验证「谁」产生的摘要。它只告诉你「数据变了没」，但不告诉你「这个摘要是不是来自合法发送方」。

要解决这个问题，就需要引入密钥。这就是 HMAC 登场的地方。

4.4 HMAC：带密钥的哈希消息认证码

HMAC 的全称是 Hash-based Message Authentication Code。它本质上是在哈希函数外面包了一层密钥参与的计算。

它的核心思想很简单：只有持有相同密钥的双方，才能算出相同的 MAC 值。攻击者不知道密钥，就算他能篡改数据，也算不出合法的 MAC。

HMAC 的标准定义是 RFC 2104，它的计算过程可以概括为：

HMAC(K, m) = H( (K' ⊕ opad) || H( (K' ⊕ ipad) || m ) )

其中：

• K' 是经过填充或哈希处理后的密钥
• ipad 是 0x36 重复的字节块
• opad 是 0x5c 重复的字节块
• || 表示拼接
• H 是底层的哈希函数（比如 SHA-256）

你可能会问：为什么不直接算 H(K || m)？那样简单多了。但密码学里「简单」往往意味着「有漏洞」。直接拼接密钥和消息，容易受到长度扩展攻击。HMAC 用两次哈希和异或操作，就是为了堵住这些漏洞。

下面是一个 Python 示例：

import hmac
import hashlib

key = b"this-is-a-secret-key-32bytes!"
message = b"Transfer $1000 to account 12345"

mac = hmac.new(key, message, hashlib.sha256).hexdigest()
print(f"HMAC-SHA256: {mac}")

# 验证端用同样的 key 和 message 重新计算，对比 mac
expected_mac = hmac.new(key, message, hashlib.sha256).hexdigest()
if hmac.compare_digest(mac, expected_mac):
    print("消息认证通过：数据完整且来源可信")
else:
    print("认证失败：数据可能被篡改或密钥不匹配")

4.5 防篡改机制：HMAC 如何保护传输通道

在实际的加密传输通道里，HMAC 通常和对称加密配合使用。常见的模式有两种：

模式	做法	特点
Encrypt-then-MAC	先加密明文，再对密文计算 HMAC	最安全，推荐使用。能同时检测密文篡改和密文替换
MAC-then-Encrypt	先对明文计算 HMAC，再把明文和 MAC 一起加密	存在安全隐患，某些场景下可被利用
Encrypt-and-MAC	分别加密明文和计算明文 HMAC，并行发送	可能泄露明文信息，不推荐

我个人在项目里只用 Encrypt-then-MAC。接收方收到数据后，先验证 HMAC，验证通过才解密。这样任何密文篡改，在解密前就会被发现。

下面这张图展示了 Encrypt-then-MAC 的完整流程：

4.6 避坑指南：我踩过的 HMAC 的坑

讲了这么多原理，最后分享几个实战中容易翻车的地方：

• 密钥太短或太弱：HMAC 的安全性完全依赖密钥。别用「123456」这种密钥，也别用太短的。我建议密钥长度至少和底层哈希的输出长度一致——对 SHA-256 来说，就是 32 字节。
• 密钥复用：加密密钥和 HMAC 密钥不要用同一个。如果攻击者攻破了加密，他就能拿到 HMAC 密钥，整个认证体系就崩了。我习惯用 HKDF（基于 HMAC 的密钥派生函数）从一个主密钥派生出两个子密钥。
• 忽略密钥轮换：一个密钥用太久，暴露风险会累积。我曾经在审计一个老系统时，发现 HMAC 密钥三年没换过……嗯，后来我帮他们加上了自动轮换机制，每 30 天换一次。
• 时序比较漏洞：前面提过了，用 hmac.compare_digest，别用 ==。