你拿到一个 SM3 Hash，就等于拿到了认证权 —— 图解长度扩展攻击

原创

利刃信安
利刃信安

利刃信安

2026年6月23日 14:30
北京

在小说阅读器读本章

去阅读

你拿到一个 SM3 Hash，就等于拿到了认证权 —— 图解长度扩展攻击

摘要： SM3 是我国商用密码体系中的核心杂凑算法，广泛应用于数字认证、消息认证等场景。然而，许多人并不知道：当你用 SM3(secret || message) 做消息认证时，拿到 hash 值的人，即使不知道密钥，也能伪造任意消息的合法认证。

一、问题场景：一个看似安全的认证方案

某服务端使用 SM3 做消息认证，token 的计算方式为：

token = SM3(secret_key || message)

其中 secret_key 是 16 字节随机密钥，攻击者不知道密钥内容，但已知密钥长度为 16 字节。

攻击者截获了一条合法请求：

攻击者想附加 &admin=true 来提升权限。他能在不知道密钥的情况下，伪造出一个合法的认证请求吗？

答案是：能。 这就是 SM3 长度扩展攻击。

二、原理：为什么拿到 Hash 就等于拿到认证权？

要理解这个漏洞，先看 SM3 的内部结构。

SM3 采用 Merkle-Damgård 结构——消息被分为 512-bit（64 字节）的分组，逐块压缩：

SM3(M) 的计算流程:
  IV(256bit) → [CF] → V₁ → [CF] → V₂ → ... → Vₙ = SM3(M)
                ↑M₁          ↑M₂              ↑Mₙ

压缩函数 CF 的输出（256-bit）直接作为下一块的 IV，最终输出的 hash 值就是最后一个 CF 的输出——换句话说，hash 值就是压缩机的“内部状态”本身。

这导致了一个致命后果：拿到 H = SM3(secret || message) 的人，可以把它当新的 IV，继续压缩自己构造的附加数据块：

攻击者伪造:
  H = SM3(M) → [CF] → V' = SM3(M || padding || evil_extension)
                   ↑evil_extension (含新填充)

攻击者根本不需要知道 secret 的内容——只需要 H 和密钥的长度。 这就是长度扩展攻击（Length Extension Attack）的核心。

三、答案：一步步计算

设 secret_key = 0123456789ABCDEF0123456789ABCDEF（实际攻击不需要密钥，仅用于验证）。

1. padding₁ 的计算

SM3 填充规则 (GB/T 32905-2016 §5.1)：

padding₁ (28 字节, hex)：

80000000000000000000000000000000000000000000000000000120

验证：36 + 28 = 64 字节，恰好一个 512-bit 分组。

2. 伪造 token 的计算

攻击者以 H = 984c2580...819fef33 作为新的 IV，对 \"&admin=true\" 进行 SM3 压缩：

伪造 token：

ef5bd5887e59cb85a6e870ee0d4a2ea5e73150a9b1a5108c5e58b970a6bc411f

3. 构造合法认证请求

攻击者发送：

message = \"user=alice&role=user\"  ← 原消息
        + padding₁_bytes          ← 28 字节原始二进制填充
        + \"&admin=true\"           ← 扩展消息

token   = ef5bd5887e59cb85a6e870ee0d4a2ea5e73150a9b1a5108c5e58b970a6bc411f

服务端计算 SM3(secret || message') 时，完整数据为：

secret(16B) || message(20B) || padding₁(28B) || \"&admin=true\"(11B)  → 75 字节

第一块 64B → CF 输出 H（等于攻击者截获的 token），第二块以 H 为 IV 压缩扩展块 → 输出刚好等于攻击者伪造的 token，验证通过。

四、详解：为什么攻击可行？

直观类比： 把 SM3 看作一台消息搅拌机——每次投入 64 字节原料，搅拌 64 轮后输出 32 字节浓缩液。最终浓缩液就是搅拌机的内部状态。攻击者拿到浓缩液后，直接倒入自己的原料继续搅拌，产出新浓缩液——无需知道之前投入了什么原料。

攻击者需要什么？

正常场景 vs 攻击场景

五、防御方案

结论：不要用裸 hash 做消息认证，使用 HMAC。