校验算法基础：哈希与CRC，选对才是硬道理
做固件校验这么多年，我见过太多人一上来就问：「用MD5还是SHA-256？」其实这个问题背后藏着两个更关键的问题：你要防什么？你的芯片跑得动吗？
这一章咱们就把哈希算法和CRC算法掰开揉碎讲清楚。不扯玄乎的数学公式，只讲你写代码时真正需要知道的东西。
哈希算法：固件校验的「指纹」技术
哈希算法，说白了就是把任意长度的数据，压缩成一个固定长度的「摘要」。这个摘要就像人的指纹——理论上独一无二，而且无法从指纹反推出人的长相。
我刚开始做固件时，总觉得哈希就是个校验和。直到有一次，客户反馈设备升级后频繁死机，我查了三天才发现是镜像被篡改了一字节，而CRC校验居然通过了……嗯，从那以后我对哈希算法再也不敢马虎了。
MD5：老当益壮，但别用于安全场景
MD5输出128位（16字节）的摘要。速度极快，在老旧MCU上也能跑得动。但它的碰撞漏洞已经被公开——2004年就有研究者找到了构造碰撞的方法。
MD5现在适合什么场景？我个人习惯用它做非安全性的数据去重、文件一致性比对。比如在开发阶段快速确认两个固件是否相同，MD5完全够用。
SHA-1：正在退役的「老兵」
SHA-1输出160位（20字节）。曾经是业界标准，但Google在2017年展示了SHAttered攻击——成功构造了两个不同PDF文件拥有相同SHA-1哈希值。
现在SHA-1已经被大多数安全标准弃用。如果你还在用SHA-1做固件签名校验，我建议尽快升级。我在一个遗留项目里见过SHA-1的校验代码，当时就建议客户迁移到SHA-256——不是因为SHA-1马上会被攻破，而是合规审计越来越严。
SHA-256：当前固件校验的「黄金标准」
SHA-256输出256位（32字节），属于SHA-2家族。目前没有已知的实际碰撞攻击。大多数现代MCU都内置了SHA-256硬件加速模块，跑起来并不慢。
你想想看，一个32字节的摘要，就能代表整个固件镜像的完整性。我参与过的工业控制器项目，全部强制使用SHA-256做镜像校验，客户审计一次通过。
哈希算法对比表
| 算法 | 输出长度 | 安全性 | 速度（相对） | 推荐场景 |
|---|---|---|---|---|
| MD5 | 128位（16字节） | ❌ 已破解 | 极快 | 非安全去重、开发调试 |
| SHA-1 | 160位（20字节） | ⚠️ 已示警 | 快 | 遗留系统迁移中 |
| SHA-256 | 256位（32字节） | ✅ 安全 | 中等 | 固件校验、签名验证 |
| SHA-512 | 512位（64字节） | ✅ 安全 | 较慢 | 高安全需求、64位平台 |
CRC算法：轻量级的「错误检测」利器
CRC（循环冗余校验）和哈希算法不同。哈希追求的是「难以碰撞」，CRC追求的是「快速检测传输错误」。说白了，CRC不是用来防黑客的，是用来防硬件噪声的。
我记得第一次在UART通信里加CRC校验，效果立竿见影——之前偶尔出现的乱码数据，加了CRC后全部被拦截。但要注意，CRC不能用于安全校验，因为它的数学结构太简单，攻击者可以轻松构造碰撞。
CRC的原理：多项式除法
CRC的核心思想是把数据看作一个巨大的二进制数，然后用一个固定的「生成多项式」做除法，余数就是CRC值。接收方用同样的多项式做除法，如果余数为0，说明数据没有损坏。
这里有个关键点：CRC的检错能力取决于生成多项式的选择。多项式选得好，可以检测出所有单比特错误、双比特错误、奇数个错误，甚至一定长度的突发错误。
常见CRC分类
- CRC-8：输出8位，用于小数据包、单字节校验。比如1-Wire总线就用CRC-8。
- CRC-16：输出16位，Modbus协议、USB数据包都在用。我做过的一个传感器项目，用CRC-16校验每帧数据，误码率从万分之一降到了百万分之一以下。
- CRC-32：输出32位，以太网、ZIP文件、PNG图片的标准校验。固件镜像校验也常用CRC-32做快速完整性检查。
- CRC-64：输出64位，用于大文件校验、数据库校验和。
哈希 vs CRC：什么时候用哪个？
这个问题我经常被问到。其实很简单：
- 防篡改、防伪造 → 用哈希（SHA-256）
- 防传输噪声、硬件错误 → 用CRC
- 两者都要 → 先用CRC做快速检测，再用哈希做安全校验
我在一个车载ECU项目里就是这么做的：CAN总线传输时用CRC-16检测每帧错误，固件刷写完成后用SHA-256校验整个镜像。CRC负责「快」，SHA-256负责「准」，各司其职。
知识体系总览
下面这张图把本章的核心知识点串起来了。你可以把它当作一个快速索引——遇到校验需求时，先看这张图，再决定用哪种算法。
代码示例：CRC-32的C语言实现
光说不练假把式。下面是一个轻量级的CRC-32实现，我经常在裸机项目里用。它不需要任何库依赖，直接复制就能用。
#include <stdint.h>
// CRC-32（IEEE 802.3）查找表
static const uint32_t crc32_table[256] = {
0x00000000, 0x77073096, 0xEE0E612C, 0x990951BA,
0x076DC419, 0x706AF48F, 0xE963A535, 0x9E6495A3,
// ... 实际项目中需要完整256项
};
uint32_t crc32_calculate(const uint8_t *data, uint32_t len) {
uint32_t crc = 0xFFFFFFFF;
for (uint32_t i = 0; i < len; i++) {
uint8_t index = (crc ^ data[i]) & 0xFF;
crc = (crc >> 8) ^ crc32_table[index];
}
return crc ^ 0xFFFFFFFF;
}哈希算法的代码示例：SHA-256快速入门
SHA-256的实现比较复杂，我不建议你自己从头写。用现成的库就好——mbedTLS、OpenSSL、或者芯片厂商提供的加密库都行。
下面是用mbedTLS计算SHA-256的典型代码：
#include "mbedtls/sha256.h"
int calculate_sha256(const uint8_t *input, size_t len, uint8_t output[32]) {
mbedtls_sha256_context ctx;
mbedtls_sha256_init(&ctx);
mbedtls_sha256_starts(&ctx, 0); // 0表示SHA-256，1表示SHA-224
mbedtls_sha256_update(&ctx, input, len);
mbedtls_sha256_finish(&ctx, output);
mbedtls_sha256_free(&ctx);
return 0;
}实战选择建议
最后，我根据多年经验总结了一个快速决策流程：
- 先看芯片资源：Flash < 64KB？优先用CRC-32 + 轻量哈希（如SHA-224）。
- 再看安全需求：需要防恶意篡改？必须用SHA-256或以上。
- 最后看实时性：OTA升级时每包都要校验？CRC做快速过滤，SHA-256做最终确认。
记住一句话：没有最好的算法，只有最合适的组合。我在实际项目中，经常是CRC和哈希搭配使用——CRC负责「快检」，哈希负责「终验」，两者互补，固件安全才有保障。