哈希算法基础：MD5、SHA-1、SHA-256原理对比、哈希碰撞与安全性、在EDR中的应用场景
聊到EDR的数据完整性，哈希算法是绕不开的基础设施。说白了，哈希就是给数据打一个「数字指纹」。你想想看，一个文件不管多大，经过哈希运算后，都会得到一个固定长度的字符串。这个字符串就像人的指纹一样，理论上具有唯一性。
我个人习惯把哈希算法比作「碎纸机+搅拌机」的组合——你把一张纸扔进去，出来一堆纸屑，但你永远没法把纸屑还原成原来的纸。这就是哈希的核心特性：单向性。
MD5、SHA-1、SHA-256 原理对比
先说说这三个最常见的哈希算法。我刚开始做安全那会儿，MD5还是主流，后来慢慢被SHA-1取代，现在SHA-256基本成了标配。为什么会这样？我们一个个来看。
| 算法 | 输出长度 | 分组大小 | 轮数 | 安全性状态 |
|---|---|---|---|---|
| MD5 | 128位 (16字节) | 512位 | 4轮 (64步) | 已破解，不推荐 |
| SHA-1 | 160位 (20字节) | 512位 | 4轮 (80步) | 已破解，谨慎使用 |
| SHA-256 | 256位 (32字节) | 512位 | 64轮 | 目前安全 |
MD5：1992年诞生，运算速度快，但安全性已经千疮百孔。我记得2012年的时候，有个项目组坚持用MD5做文件完整性校验，结果被攻击者伪造了哈希值，导致恶意软件混进了发布包。嗯，从那以后我再也不敢在正式环境用MD5了。
SHA-1：比MD5多了32位输出，理论上更安全。但2017年Google和CWI研究所联合攻破了SHA-1，用110块GPU算了两周就找到了碰撞。你想想看，连Google都能做到，黑产组织肯定也能。
SHA-256：目前EDR领域的首选。输出256位，碰撞概率极低。我做过一个粗略估算：要找到SHA-256的碰撞，用目前最快的超级计算机也得算上亿年。这个安全余量，对于EDR场景来说完全够用。
核心结论：在EDR产品中，文件哈希校验、威胁情报匹配、完整性监控这三个场景，我建议统一使用SHA-256。MD5和SHA-1只适合做非安全场景的快速比对，比如去重、缓存等。
哈希碰撞与安全性
哈希碰撞，说白了就是两个不同的输入，算出了同一个哈希值。这听起来像是小概率事件，但数学上确实存在。
为什么会有碰撞？因为哈希函数的输出空间是有限的。MD5只有2^128种可能，而输入空间是无限的。根据鸽巢原理，碰撞必然存在。只是找到碰撞的难度不同。
我曾经在EDR产品中遇到过一个问题：威胁情报库里有几百万个恶意文件的SHA-1哈希值，结果发现有两个完全不同的文件，SHA-1值竟然一样。排查了半天，发现是SHA-1碰撞攻击导致的。从那以后，我们就把威胁情报的哈希匹配改成了SHA-256 + 文件大小双重校验。
避坑指南：我曾经见过有人用MD5做数字签名，这是非常危险的做法。攻击者可以构造一个恶意文件，使其MD5值与合法文件完全一致。在EDR场景中，如果哈希校验被绕过，整个完整性保护体系就形同虚设。
这里有个重要的概念叫「生日攻击」。简单说就是：要找两个文件哈希值相同，比找一个文件哈希值等于某个特定值要容易得多。SHA-256的抗生日攻击能力是2^128，而MD5只有2^64。差距有多大？2^64次运算，用现在的GPU集群几天就能跑完；2^128次运算，把全世界的算力加起来也跑不完。
在EDR中的应用场景
哈希算法在EDR中无处不在。我总结了一下，主要有这几个场景：
- 文件完整性监控：监控关键系统文件、配置文件、二进制文件的哈希值变化。一旦发现哈希值变了，说明文件被篡改过。
- 威胁情报匹配：将可疑文件的哈希值与已知恶意文件的哈希值进行比对。这是EDR最基础的功能之一。
- 内存取证：对内存中的代码段进行哈希校验，检测是否有代码注入或hook行为。
- 日志完整性：对日志条目进行链式哈希，防止攻击者篡改日志掩盖痕迹。
- 软件发布验证：验证EDR Agent自身更新包的完整性，防止被中间人攻击替换。
我个人最看重的是文件完整性监控这个场景。你想想看，如果攻击者篡改了系统文件，EDR却检测不到，那整个安全防线就崩塌了。所以我在设计EDR架构时，会把哈希校验放在内核层，用驱动级别的钩子来拦截文件写入操作，实时计算哈希值。
实战技巧：在EDR中做哈希校验时，不要只算文件内容的哈希。我建议把文件的元数据（创建时间、修改时间、文件大小、权限等）也纳入哈希计算。这样能防止攻击者通过修改文件时间戳来绕过检测。
下面是我在EDR中常用的哈希校验代码片段，用C语言实现，运行在内核驱动中：
// EDR文件完整性校验 - 内核态实现
// 使用SHA-256 + 文件元数据联合校验
typedef struct _FILE_INTEGRITY_INFO {
UCHAR sha256Hash[32]; // SHA-256哈希值
UINT64 fileSize; // 文件大小
UINT64 lastWriteTime; // 最后写入时间
UINT32 fileAttributes; // 文件属性
} FILE_INTEGRITY_INFO, *PFILE_INTEGRITY_INFO;
NTSTATUS CalculateFileHash(
_In_ PUNICODE_STRING FilePath,
_Out_ PFILE_INTEGRITY_INFO IntegrityInfo
) {
// 1. 打开文件
// 2. 读取文件内容，计算SHA-256
// 3. 获取文件元数据
// 4. 将哈希值与基线库比对
// 5. 如果不一致，触发告警
return STATUS_SUCCESS;
}这里有个细节要注意：哈希计算本身是有性能开销的。对于大文件（比如几百MB的数据库文件），每次写入都重新计算哈希会严重影响性能。我建议的做法是：只对关键系统文件和可执行文件做实时哈希校验，对于数据文件，可以采用定时扫描的方式。
最后说一句，哈希算法不是万能的。它只能告诉你「文件变了」，但不能告诉你「为什么变了」。在EDR中，哈希校验需要和行为分析、进程监控等其他手段配合使用，才能形成完整的防护体系。
这张图展示了我设计的EDR哈希校验流程。从文件/进程/日志输入开始，经过内核态的SHA-256计算，然后分两条路径：一条与基线哈希库比对，检测文件是否被篡改；另一条与威胁情报库匹配，检测是否为已知恶意文件。最终触发告警或阻断动作。
在实际部署中，我建议把基线哈希库存储在安全区域，比如TPM芯片或远程可信服务器中。如果攻击者连基线库都能篡改，那哈希校验就失去了意义。