摘要

  • 1992 年 4 月的 RFC 1321不只说明 MD5 算法，还收录 C 语言参考实现、测试驱动和七组预期结果，让不同实现有了可运行、可比较的共同目标。
  • 2011 年的 RFC 6151更新了安全判断：需要抗碰撞性的场合，包括数字签名，已不宜使用 MD5。旧测试结果仍能准确说明 MD5 怎样计算。

一份带参考程序的技术备忘录

今天看见一串 MD5 十六进制字符，很容易把它当成电脑自言自语。RFC 1321从更基础的地方讲起：任意长度的消息先填充到规定边界，接上原始长度，用四个 32 位字作初始状态，再按 512 位分组处理。字节顺序、填充位置、移位方式，只要一处理解不同，两台机器面对同一段文字就会给出不同摘要。纸面规则需要落到每一位上，互通才会发生。

Rivest 把落地的梯子也装进了文档。附录 A 收录 global.h、md5.h、md5c.c 和 mddriver.c。前三个文件给出类型、接口与算法实现，驱动程序则能处理字符串、文件和标准输入。输入 -x，它会跑一套固定测试。附录 A.5 把七组预期输出排在后面：空字符串、a、abc，再到较长的字母和数字序列。对于 abc，标准答案是 900150983cd24fb0d6963f7d28e17f72。题目和答案同页出现，程序员就能判断错误出在自己的程序，还是出在读文档时拐错的那一道弯。

这套参考代码来自用于 Privacy-Enhanced Mail 的 RSAREF 工具包。写一个新实现的人，可以用文字规定核查设计，用参考程序比对行为，再用测试输出检查具体结果。把代码移到另一种机器上的人，也能尽早发现字节顺序之类的问题。RFC 称实现具有可移植性，还提到在小端序平台上可以作的优化。它给出了一条非常务实的交接路线：先让程序在读者自己的环境里跑起来，再谈它是否与别人算得一样。

1992 年这份文件还有当时的安全雄心。MD5 是 MD4 的后续设计。RFC 认为 MD4 获得采用的速度可能跑在充分审查之前，于是让 MD5 在速度上退一步，换取作者期待的更大安全余地。它设想的用途包括数字签名：先把大文件缩成摘要，再交给私钥运算。MD5 被放入公共领域，供审查和可能的标准化；RFC 1321 本身属于 Informational 文档。写下算法、开放实现、期待审查，这几件事在同一份文件里同时发生。

参考程序解决的是“你算的 MD5 与我算的 MD5 是否相同”。测试向量把这个问题缩小成七个可以核对的输出。至于攻击者能否刻意制造两份摘要相同的不同消息，需要密码分析来回答。一个学生可以把书后习题全做对，几年后仍发现课本里关于安全性的判断该重写。算法的运行结果与人们对结果赋予的安全信心，各有自己的证据。

2011 年的 RFC 6151正是对后者的更新。随着攻击研究积累，它明确指出：当应用需要抗碰撞性，例如数字签名，MD5 已经不合适。文档也分别讨论了 HMAC-MD5、用于发现偶然传输错误的校验等不同用途，并建议新的协议设计避开 HMAC-MD5。这是一份按用途重新划线的判断。攻击并没有使 abc 的 MD5 值突然变成另一串字符；改变的是那串字符能够承受怎样的安全承诺。

把 1992 年与 2011 年的两份 RFC 放在一起看，会看见互联网标准文档少有的清楚分工。第一份把算法描述、C 程序和预期输出捆成一个包，让独立的程序员能找到共同的计算目标。第二份重新评估这个目标在安全应用里的位置。参考实现提供了可重复的行为，后来的研究给这种行为重新定价。印在书后的答案没有撕掉，考试却换了题型。