2. SM3 密码杂凑算法：原理、对比与实战

SM3 国密杂凑算法，说白了就是咱们自己的“数字指纹”算法。我最早接触它是在一个政务系统的数据完整性改造项目里，客户要求所有传输文件的哈希值必须用 SM3 算。当时我还在想，这跟 SHA-256 到底差在哪？后来踩了几个坑，才真正摸透了它的脾气。

2.1 SM3 算法原理与流程

SM3 的输出长度是 256 位，也就是 32 个字节。它的核心逻辑可以概括为：填充 → 迭代压缩 → 输出摘要。我习惯把它的流程拆成三步来讲。

2.1.1 消息填充

跟所有杂凑算法一样，SM3 先把输入消息补成 512 位的整数倍。具体做法是：

• 先补一个 “1” 比特
• 再补若干个 “0”，直到长度模 512 等于 448
• 最后附加 64 位的原始消息长度（大端序）

嗯，这里要注意：填充后的消息长度一定是 512 的整数倍。我曾经在自测时忘了检查边界情况，结果一个刚好 448 位的消息填充后多了一整个分组，调试了半天才发现。

2.1.2 迭代压缩

SM3 采用 Merkle-Damgård 结构，把填充后的消息分成 512 位的分组，每个分组再拆成 16 个 32 位字。然后通过消息扩展生成 132 个扩展字，最后进入 64 轮压缩函数。

压缩函数里用到了布尔函数、循环移位、模加运算。我个人觉得它跟 SHA-256 最像的地方就在这里，但细节上 SM3 多了一些“国产化”的设计，比如使用了 16 个常数和 64 个不同的轮常数。

2.1.3 输出摘要

最后一轮压缩完成后，把 8 个 32 位工作寄存器的值拼接起来，就是最终的 256 位摘要。这个过程不可逆，你没法从摘要反推出原始消息——这也是杂凑算法的基本要求。

2.2 SM3 与 SHA-256 的对比分析

很多同学会问：SM3 和 SHA-256 到底谁更强？我的答案是：安全性在同一量级，但 SM3 有“主场优势”。你想想看，国密标准在设计时参考了 SHA-256 的成熟框架，又针对一些潜在攻击做了加固。

对比维度	SM3	SHA-256
输出长度	256 位	256 位
分组长度	512 位	512 位
压缩轮数	64 轮	64 轮
消息扩展	16→132 字（更复杂）	16→64 字
布尔函数	FF、GG（含非线性）	Ch、Maj（线性为主）
循环移位	多种移位组合	固定右移
抗碰撞性	优于 SHA-256（理论）	标准安全
合规性	国标 GB/T 32905-2016	FIPS PUB 180-4

2.3 SM3 在完整性校验中的应用场景

完整性校验，说白了就是确保数据没被人动过手脚。SM3 在这个领域有三大典型场景，我一个个说。

2.3.1 文件完整性校验

最常见的用法：发布方计算文件的 SM3 摘要，接收方下载后重新计算，比对两个摘要是否一致。我曾经在一个固件升级系统里这么干过：

// 伪代码示例：SM3 文件完整性校验
String filePath = "/firmware/update.bin";
String expectedHash = "a1b2c3d4e5f6..."; // 发布方提供的 SM3 摘要

byte[] fileData = readFile(filePath);
String actualHash = SM3.hash(fileData);

if (expectedHash.equals(actualHash)) {
    // 校验通过，执行升级
} else {
    // 校验失败，拒绝升级
    throw new SecurityException("文件完整性校验失败");
}

2.3.2 数字签名中的摘要生成

SM2 数字签名算法（后面章节会细讲）需要先对消息做 SM3 摘要，再对摘要签名。这个流程保证了签名效率——你想想看，直接对几百兆的文件做签名运算，性能扛不住。先摘要再签名，是业界标准做法。

2.3.3 启动过程中的完整性度量

在可信启动（Trusted Boot）场景里，每个启动阶段的组件（BIOS、Bootloader、内核）都会计算 SM3 摘要，并存储在 TPM 或安全芯片的 PCR 寄存器中。如果某个阶段的摘要跟预期值不符，系统就拒绝启动。

我参与过一个信创服务器的启动加固项目，就是用 SM3 做逐级度量。当时遇到一个棘手问题：Bootloader 升级后，PCR 值没同步更新，导致系统无法启动。后来我们加了一个“预期值白名单”机制，才解决了这个兼容性问题。

嗯，SM3 的内容就讲到这里。它的原理不复杂，但实际落地时细节很多。我建议你在自己的项目里先写个简单的文件校验工具跑一遍，感受一下“摘要不一致”时的那种紧张感——相信我，经历过一次你就再也不会忘了。