4、哈希算法选型：SHA-256 vs SHA-3 vs BLAKE2
哈希算法是固件签名的地基。地基不稳，上面盖的签名验证大楼再漂亮也没用。
我见过不少团队，选哈希算法时只看「是不是国标」或者「是不是最新」。结果呢？要么性能扛不住，要么安全性有隐患。今天咱们就把这事聊透。
4.1 三大主流哈希算法概览
目前固件签名领域，真正能打的就三个：SHA-256、SHA-3、BLAKE2。其他的要么太老（比如MD5、SHA-1），要么太偏门（比如SM3虽然国标但生态不够）。
| 算法 | 输出长度 | 设计年代 | 核心结构 | 硬件友好度 |
|---|---|---|---|---|
| SHA-256 | 256 bit | 2001 | Merkle-Damgård | ★★★★★ |
| SHA-3 | 可配置（推荐256） | 2015 | 海绵结构 | ★★★★☆ |
| BLAKE2 | 可配置（推荐256） | 2012 | HAIFA + 轮函数 | ★★★★☆ |
你可能会问：为什么SHA-256还是主流？说白了，它经过了二十多年的密码分析考验，生态最成熟。我在一个车载T-Box项目里，MCU的硬件加速器只支持SHA-256，想换都换不了。
4.2 抗碰撞性分析
哈希算法的核心指标就是抗碰撞性。简单说：你能不能找到两个不同的输入，算出同一个哈希值。
对于256位输出的哈希算法，理论上需要大约2^128次尝试才能找到一次碰撞。这个数字有多大？比宇宙中的原子数还多。所以从实用角度讲，SHA-256、SHA-3-256、BLAKE2-256的抗碰撞性都是足够的。
关键结论：对于固件签名场景，256位输出的哈希算法已经足够安全。不需要盲目追求512位输出——那只会浪费存储空间和计算时间。
但有个坑要注意。我曾经审计过一个项目，他们用SHA-256做固件完整性校验，但哈希值只存了前64位。这相当于把安全等级从128位降到了32位。嗯，这跟没加密差不多。
避坑指南：不要截断哈希值！如果存储空间紧张，优先考虑用更短的算法（比如BLAKE2s输出256位），而不是截断SHA-256的输出。
4.3 哈希长度与安全等级
这里有个对应关系，我建议你记下来：
| 哈希输出长度 | 安全等级（抗碰撞） | 推荐场景 |
|---|---|---|
| 128 bit | 64 bit | 不推荐用于签名 |
| 160 bit | 80 bit | SHA-1已淘汰 |
| 256 bit | 128 bit | 固件签名首选 |
| 384 bit | 192 bit | 高安全场景 |
| 512 bit | 256 bit | 量子安全过渡期 |
我个人习惯：普通IoT设备用256位就够了。金融级或者军工级才考虑384位以上。别为了「看起来更安全」而牺牲性能。
4.4 硬件实现考量
这才是嵌入式工程师最关心的部分。算法再好，跑不动也是白搭。
我分三个维度来说：
- 计算资源：SHA-256的硬件加速器几乎成了MCU标配。STM32、NXP i.MX、ESP32都有。SHA-3和BLAKE2的硬件加速器相对少见，主要靠软件实现。
- 内存占用：SHA-256需要64字节的工作缓冲区。SHA-3的海绵结构需要更大的状态（200字节）。BLAKE2最省，只需要32字节。
- 功耗：在电池供电设备上，BLAKE2的软件实现比SHA-256快3-4倍，意味着更低的功耗。
我的建议：如果MCU有SHA-256硬件加速器，直接用。如果没有，优先考虑BLAKE2的软件实现——它比SHA-256的软件实现快得多，而且安全性不差。
我曾经在一个低功耗传感器项目里，MCU是Cortex-M0+，没有硬件加速器。一开始用SHA-256软件库，每次哈希计算要花80ms，电池撑不了几天。换成BLAKE2s之后，降到15ms，功耗直接砍半。
4.5 选型决策流程
说了这么多，到底怎么选？我画了张图，帮你理清思路：
4.6 实战建议总结
最后，给你几个可以直接用的结论：
- 有硬件加速器：无脑选SHA-256。生态最好，工具链最成熟。
- 无硬件加速器 + 低功耗：选BLAKE2s。软件实现快，省电。
- 无硬件加速器 + 高性能：SHA-256或SHA-3都行，看个人偏好。
- 国标合规要求：选SM3，但要注意硬件支持情况。
一个小技巧：如果项目还在原型阶段，不确定最终用哪个MCU，可以先在软件层封装一个哈希接口。这样后面换算法时，只需要改底层实现，上层签名验证逻辑不用动。
哈希算法选型这事，没有银弹。关键是根据你的硬件平台、功耗预算、安全需求来权衡。别盲目追新，也别死守老古董。