SM3 和 SHA-256 有什么区别？国密哈希与 NIST 哈希的对比与选择

一句话结论

SM3 和 SHA-256 安全强度同级（都输出 256 位摘要），技术选型上可以互换；真正的分界线还是合规——国密场景必须 SM3，国际场景默认 SHA-256。

不要把「能不能互换」理解成「随便混用」。算法强度接近，不等于存量摘要、协议套件、审计条款可以混着写；选型正确之后，还要保证全链路只认一个（或显式双栈）摘要标识。

基本面对比

两者结构同源（都是 Merkle-Damgård 迭代），轮函数设计不同——SM3 的消息扩展和压缩函数是独立设计，经过全国密码算法设计竞赛打磨。密码学上两者目前都没有被实际攻击的先例。

标准测试向量（联调必备）

SM3("abc")    = 66c7f0f462eeedd9d1f2d46bdc10e4e24167c4875cf2f7a2297da02b8f4ba8e0
SM3("")       = 1ab21d8355cfa17f8e61194831e81a8f22bec8c728fefb747ed035eb5082aa2b

SHA-256("abc") = ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

联调对不上时，先用在线 SM3 工具算一遍 abc——和上面一致说明你的实现没问题，问题在传输编码（UTF-8 vs GBK、hex 大小写、有没有带换行符）。本站 SM3 在浏览器内用 sm-crypto 计算，适合核对向量与小文本；大文件批量哈希请走原生绑定或服务端实现。

性能差异

纯软件实现两者速度接近（SM3 略慢 10-20%）。关键差异在硬件加速：现代 x86/ARM CPU 有 SHA-NI 指令集，SHA-256 走硬件能快 5-10 倍；SM3 的硬件加速在国内的密码卡、TEE 环境里有。高吞吐场景（每秒上万次哈希）在通用服务器上 SHA-256 有实际性能优势，在国密硬件环境里 SM3 反超。

浏览器侧再补一句：Web Crypto 原生 SHA-256 通常远快于纯 JS 的 SM3。页面工具用来验证联调向量足够；若要哈希 GB 级数据，不要指望浏览器标签页。

HMAC 构造是通用的

HMAC 的构造不依赖具体哈希算法（密钥填充 + 两次哈希）：

HMAC-SM3   = HMAC(K, m) 用 SM3 作底层
HMAC-SHA256 = HMAC(K, m) 用 SHA-256 作底层

国密 TLS（TLCP 协议）里的伪随机函数、密钥派生都用 HMAC-SM3；JWT 的 HS256 用 HMAC-SHA256。算法替换时 HMAC 层代码不用改，换个底层函数即可——但已签发的签名/MAC 会全部失效，迁移要另做双读窗口，不能只「换库」。

什么时候必须 SM3

1. 等保 2.0 三级及以上：密码算法要求使用国密套件（SM2/SM3/SM4）
2. 政务系统：电子签章（GB/T 38540）、电子证照用 SM3 做摘要
3. 金融：人行《金融数据安全 数据安全分级指南》推动国密落地
4. 电子合同/存证：司法链、公证处对接普遍要求 SM3 摘要

合同或验收条款里写了 GB/T 39786、国密算法清单时，选型讨论到此结束——再比「哪个更快」没有意义。

什么时候用 SHA-256

1. 国际互操作（Git commit hash、Bitcoin、TLS 证书链）
2. 已有系统无合规压力，改造成本大于收益
3. 依赖硬件 SHA 加速的高吞吐场景
4. 需要 FIPS 140 路径认证的部署（SM3 通常不在同一模块里）

现实里两者往往要共存

真实系统很少「整库只选一个哈希」——不同表面会跑很多年双栈：

• 对外接口（监管报送、合作方网关）：合同要求 SM3 就 SM3，其余走 SHA-256——按合同定，不按「代码库偏好」定
• 内部存储：尽量固定一种算法；库里混存两种摘要，校验代码迟早长出两个分支，最后变成「为什么这个校验和对不上」的事故
• 协议层与应用层：TLCP 握手带 SM3，应用层仍可能用 SHA-256 签名——它们靠作用域共存，而不是在同一层协商
• 迁移陷阱：把已存的 SM3 摘要「改成」SHA-256，必须能重新哈希原文（不能对摘要再哈希还指望可验证）——计划的是数据访问路径，不只是换算法名

合规决策树

三个问题基本能定稿。第一：系统是否落入中国监管范围（政务、金融、关基，或合同引用 GB/T 39786）？是 → SM3，这是管辖问题不是技术口味。第二：同一部署是否还要 FIPS 验证？是 → SHA-256，因为 SM3 通常没有对应 FIPS 模块。第三：两边范围同时存在（国内部署对接全球平台）？做双摘要信封——国内腿用 SM3-HMAC，国际腿用 SHA-256，消息头同时携带。双栈多的是一个字段，不是一次重构。

迁移窗口怎么开

在现有 MAC/签名方案里替换摘要，会使所有旧标签失效：规划「读时双接受、写时只写新算法」的窗口，而不是旗日切换。令牌格式里从第一天就带上算法标识（alg: SM3 / alg: SHA256），旧记录可解释；事后补元数据比多带一个字节痛苦得多。

可用 哈希校验工具 对照同一文件的多种摘要，确认迁移脚本没有悄悄改了换行或编码。

常见坑

• 编码不一致：中文输入的 UTF-8/GBK 编码差异导致摘要对不上——联调先统一编码
• hex 大小写：SM3 输出习惯小写，部分 Java 库输出大写，比较时先 lowercase
• SM3 和 SM3-HMAC 混淆：裸哈希和带密钥的 HMAC 是两回事，接口文档要分清
• 把浏览器工具当批量引擎：小文本与标准向量没问题；超大输入请换原生实现

排查清单

1. 合规要求 → SM3；国际互操作 → SHA-256
2. 联调对不上 → 先用 abc 测试向量隔离定位
3. 中文输入 → 确认两端编码一致（UTF-8）
4. 高吞吐 → 通用服务器 SHA-256 有硬件优势，国密硬件里 SM3 反超
5. HMAC 场景 → 构造通用，替换成本在底层函数与存量标签
6. 双栈场景 → 按表面分算法，并在令牌里显式标注

相关阅读

更完整的国密落地与编号说明见 国密算法入门、国密标准编号解读 与 国密实务指南；非对称选型见 SM2 和 RSA 怎么选。

实现注记

无论 SM3 还是 SHA-256，校验大文件都有同一个竞态要防：哈希耗时数十秒，期间换文件、换算法，过期结果晚到会把 A 文件的名配到 B 文件的哈希上，校验语义失效。这类工具需要乱序守卫：过期结果一到就丢，只认最后一次操作。

感谢阅读这篇 ToolVault 工具匣 技术文章。相关工具：SM3 哈希计算器、SM2 加解密与签名、SM4 加解密、哈希校验工具。访问 首页 查看更多开发者工具。