📚 课程目录第3章 SM3杂凑算法

3、SM3杂凑算法

聊完非对称加密，咱们来谈谈一个更基础、但也更容易被忽视的东西——杂凑算法。说白了，它就是数据的“指纹”。你在微服务里做消息校验、身份认证、完整性保护，几乎处处离不开它。国密里的SM3，就是这个指纹的标准化方案。

3.1 SM3计算过程

我第一次看SM3的算法流程时，觉得有点眼熟。它和SHA-256的结构很像，都采用Merkle-Damgård结构，消息分组大小为512位，输出长度为256位。但细节上，它有自己的个性。

SM3的计算过程可以概括为四个步骤：

消息填充：补位至448 mod 512，再追加64位长度信息，使消息正好是512的倍数。
迭代压缩：将填充后的消息分成512位的分组，每个分组通过压缩函数迭代处理。
压缩函数：核心是这个64轮的迭代压缩。它包含消息扩展（W_j、W'_j的生成）和状态更新（A、B、C、D、E、F、G、H八个字的置换）。
输出杂凑值：最后一轮输出8个字（共256位），组成最终的杂凑值。

嗯，这里要注意一个容易踩坑的点。SM3的压缩函数里，消息扩展部分对W_j和W'_j的生成规则与SHA-256不同。我曾在一次实现中，直接搬了SHA-256的扩展逻辑去跑SM3，结果校验失败。排查了半天才发现是W'_j的异或顺序写反了。

我的习惯：做SM3实现时，先把国标GB/T 32905-2016原文打印出来，对照着逐行翻译。代码写完后，用官方测试向量做一轮“全量数据”验证，别只测一个案例。我吃过一次亏，只测了空串，结果长消息场景下出了毛病。

3.2 与SHA256对比

你可能会问，SM3和SHA-256到底有什么区别？我直接用一张表格说清楚。

特性	SHA-256	SM3
输出长度	256位（32字节）	256位（32字节）
消息分组	512位	512位
轮数	64轮	64轮
消息扩展	16→64, 使用经典异或+移位	16→68, 增加W'_j生成，异或和移位组合更复杂
压缩函数	使用6个逻辑函数（异或、与、或等）	使用6个不同的逻辑函数（包括布尔函数GG、FF）
安全强度	128位（抗碰撞）	128位（业内评估与SHA-256同等安全）
性能	软件实现较快，硬件加速广泛	软件实现比SHA-256约慢10%~15%，但硬件优化后可接近

为什么要强调这些差异？因为在实际项目中，性能和安全性往往需要权衡。我记得有个项目，客户要求同时支持SHA-256和SM3，核心业务用SM3，但日志签名用SHA-256加速。这就是个典型的多算法并存场景。

核心观点：SM3不是SHA-256的山寨版。它的消息扩展采用了“更强调雪崩效应”的设计，使得每轮变换对输入的微小变化都极度敏感。这种设计在抗差分攻击上表现不错，是国密系列算法中设计最成熟的之一。

避坑指南：我曾经在对接一个第三方的SM3签名接口时，发现双方算出的杂凑值不一致。排查了一整天，最后发现是对方把字符串按UTF-16编码做杂凑，而我用的是UTF-8。SM3本身没问题，但输入编码必须统一。这是我在项目中遇到过最多的坑，没有之一。

3.3 HMAC-SM3应用场景

光有杂凑算法还不够。在微服务里，你经常需要“带密钥的杂凑”——也就是HMAC（基于哈希的消息认证码）。SM3配上HMAC，就是HMAC-SM3。

它的原理很简单：

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

其中ipad和opad是固定的重复字节，K'是经过填充的密钥。你看，这个结构其实是通用的，只是把底层的哈希函数换成了SM3。

你在微服务里什么时候用得上HMAC-SM3？我给你列几个实际场景：

API签名校验：调用方用HMAC-SM3对请求参数算签名，服务端用同样的密钥验签。这种场景在金融级接口里特别常见。
消息完整性保护：MQ消息里带上HMAC-SM3的摘要，消费方收到后验一下，防止中间人篡改。
生成：有些系统会用HMAC-SM3代替JWT的RS256签名，尤其是当密钥管理要求必须用国密时。
密码派生：在TLS或VPN握手里，HMAC-SM3可以作为PRF（伪随机函数）的一部分。

我建议你用HMAC-SM3时，特别注意密钥的生成和管理。密钥长度至少32字节，尽量从硬件安全模块或密钥管理服务/密钥分发中心（KMS/KDC）获取，别硬编码在配置文件里。

我的做法：在Spring Boot项目中，我习惯用Bouncy Castle的SM3Digest和HMac类，底层自己封装一个工具类。核心逻辑大概是这样：

public class HMacSM3Util {
    private static final int KEY_LENGTH = 32;

    public static byte[] hmacSM3(byte[] key, byte[] data) {
        HMac hmac = new HMac(new SM3Digest());
        byte[] keyBytes = new byte[KEY_LENGTH];
        System.arraycopy(key, 0, keyBytes, 0, Math.min(key.length, KEY_LENGTH));
        hmac.init(new KeyParameter(keyBytes));
        hmac.update(data, 0, data.length);
        byte[] result = new byte[hmac.getMacSize()];
        hmac.doFinal(result, 0);
        return result;
    }
}

别小看这段代码。我曾在一个生产环境里，因为密钥长度没有做截断处理，导致HMAC计算的密钥总是包含多余的零字节，结果签名一直对不上。嗯，这个教训挺深刻的。

下面这张图概括了SM3杂凑算法在微服务中的核心地位和计算流程，你可以把它当作本章的知识图谱来看。

最后说一句，HMAC-SM3在微服务中的价值，不止是“合规”两个字。它能让你在满足监管要求的同时，保持与现有HMAC-SHA256一致的接口设计模式。你想想看，换一个底层函数，不改变使用方式，就能安全合规。这样的好事，值得花半小时把它搞好。