★ FEATURED ARTICLE 聊个很实际的问题。你在老项目里翻代码翻到口令校验、接口签名、文件完整性检查十有八九能看到一个名为“MD5加密”的函数。用Delphi写这类逻辑的人特别多因为Delphi在传统桌面应用、工业控制、企业内部工具里的存量太大了。可是到了手写一个MD5组件的时候问题就来了网上流传的代码要么是几十年前的老写法编译不过新版Delphi要么过度依赖三方库集成起来一身汗。这篇就围绕Delphi环境下如何实现一套高效、可维护的MD5方案展开把组件设计、核心算法、编码陷阱、工程化封装一次讲清楚。这篇适合谁看两类人。一类是维护老系统的开发者需要把Delphi 7时代的MD5代码迁移到新版本或者给老模块补一个可测试的哈希组件另一类是刚接触Delphi、想搞明白哈希算法内部到底做了什么的同学而不是只会调用一个现成函数。文章里会给出可以直接抄走的完整单元代码也会解释每一步为什么要这么写遇到坑怎么定位。1. 先把“MD5加密”这个叫法掰清楚1.1 MD5不是加密是摘要严格从专业角度说MD5不是加密算法它是一种消息摘要算法也叫哈希算法。加密算法讲究的是双向变换数据经密钥加密后可以解密还原MD5是不可逆的无论输入多长输出固定为128位也就是16个字节通常展示成32个十六进制字符。为什么大家都管它叫“MD5加密”因为早期开发者在做口令校验、数据比对时习惯把“算摘要”说成“加密”这个叫法从论坛时代就传下来了。你可以纠正别人但不必鄙视这种叫法关键是心里清楚MD5提供的是完整性校验能力而不是保密能力。这个概念直接决定了你怎么用这个组件。如果你拿着MD5去保护机密数据设计本身就是错的如果你拿它做防篡改指纹、接口参数签名、重复数据检测那方向就对了一大半。1.2 MD5的典型适用场景我在实际项目里见过最多的是下面这几类场景它们都适合用MD5文件完整性校验下载工具、升级包、备份程序做哈希比对确认文件没被改过或没传坏。接口参数签名调用方和服务端约定一个密钥参与计算的参数拼起来算MD5用来防止参数被篡改。数据去重与缓存键对大段文本或二进制内容算指纹作为缓存、索引、幂等判断的key。口令校验老系统的登录模块。虽然现在正规做法是用慢哈希算法但存量系统里确实还有大量MD5口令字段迁移时需要兼容。下面是MD5和几个常见算法的直观对比算法输出长度可逆性碰撞安全性典型用途MD5128位不可逆已可构造碰撞完整性校验、非对抗场景指纹SHA-1160位不可逆已可构造碰撞老版本文件校验SHA-256256位不可逆目前安全证书、数字签名AES分组加密可逆与密钥强度相关数据保密传输Shown里的对比不是想说MD5一无是处。它计算速度快、实现简单、跨平台一致性好在非对抗场景下依然非常顺手。关键是分清对抗和非对抗防意外损坏用MD5没问题防恶意伪造就要慎重或者改用HMAC类方案后面我会专门展开。1.3 为什么还要自己实现一遍Delphi下最省事的方案其实是调用系统APIWindows的加密接口、各类开源库都有MD5实现。但实际集成时经常遇到问题系统API版本差异、DLL部署麻烦、旧系统不能随便引入新依赖。对于一个被反复使用的内部工具类场景自己维护一个纯Pascal实现的MD5单元反而是性价比最高的选择。自己实现还有一个好处出问题的时候你能定位。哈希值对不上如果是调第三方库只能怀疑编码、文件读取位置、大小写这些外部因素如果是自己的代码数据是怎么填充的、长度怎么写入的每一步都能对照规范排查。这种掌控感在工程维护中非常值钱。2. 动手前把算法核心步骤拧明白2.1 MD5处理流程概览MD5的整个计算过程可以拆成四步数据填充让数据长度满足总长度 mod 64 56也就是先补一个0x80再补若干个0x00最后留出8字节写原始比特长度。初始化状态准备4个32位链接变量也就是常说的魔数。分块压缩按64字节一组处理数据每一组通过四轮非线性运算更新链接变量。输出摘要把4个链接变量按小端字节序拼接成16字节。如果你之前没接触过这类哈希算法可以这样理解MD5像一台绞肉机输入任何长度的数据出来都是固定长度的肉馅。绞肉机内部不停地把数据重新搅碎混合哪怕你只改了一个字节出来的肉馅也完全不一样。2.2 让代码兼容不同版本Delphi的优先事项写Delphi代码首先要面对版本差异。老项目还在用Delphi 7新项目已经支持UnicodeString这两者在字符串转字节时的行为完全不同。我做这套代码时定的原则是核心算法只认字节数组不直接处理字符串。所有字符串进来先显式转成字节再交给核心类。这样不管外面是什么版本、什么编码核心逻辑都能保持稳定。字符串编码的问题统一放在封装层解决这也符合组件设计的单一职责思路。另外MD5计算大量使用32位无符号整数加法Delphi里对应Cardinal。有个坑必须在开始前心里有数编译器如果开启了溢出检查这类加法在极端情况下会抛异常。实际项目里遇到过调试半小时最后发现是编译器选项的问题。建议在自己的单元头部加上{$OVERFLOWCHECKS OFF}或者确保项目关闭该选项。3. 从零实现一个可复用的TMD5类3.1 数据结构与类型定义核心类需要维护四个字段4个链接变量、输入缓冲区、缓冲区中已有字节数、输入总字节数。type TMD5Digest array[0..15] of Byte; TMD5 class private FState: array[0..3] of Cardinal; FBuffer: array[0..143] of Byte; FBufferLen: Integer; FTotalBytes: Int64; procedure Transform(const AData: PByte); public procedure Initialize; procedure Update(const AData; ADataLen: Integer); function Finalize: TMD5Digest; class function DigestToString(const ADigest: TMD5Digest): string; class function GetHashString(const AData: TBytes): string; end;注意FBuffer的长度我特意放大到了144字节而不是常见的64字节。原因很直接最终填充阶段缓冲区里原本可能已经存了最多63字节的数据后面还要追加填充字节和8字节长度字段理论峰值需要128字节左右。初始计算时我用64字节的缓冲区踩过一次越界调试了很久才定位到数组越界后来干脆放大虽然内存开销可以忽略但省心得多。3.2 常量表四轮运算的基石MD5压缩函数里用到了两组关键常量位移量表和正弦常量表。位移量按四轮循环固定分布正弦常量表则是根据abs(sin(i))的整数部分计算出来的64个32位值算法规范里直接给出了现成的表实现时按顺序抄进去即可。const MD5_S: array[0..63] of Byte ( 7, 12, 17, 22, 7, 12, 17, 22, 7, 12, 17, 22, 7, 12, 17, 22, 5, 9, 14, 20, 5, 9, 14, 20, 5, 9, 14, 20, 5, 9, 14, 20, 4, 11, 16, 23, 4, 11, 16, 23, 4, 11, 16, 23, 4, 11, 16, 23, 6, 10, 15, 21, 6, 10, 15, 21, 6, 10, 15, 21, 6, 10, 15, 21 ); MD5_K: array[0..63] of Cardinal ( $D76AA478, $E8C7B756, $242070DB, $C1BDCEEE, $F57C0FAF, $4787C62A, $A8304613, $FD469501, $698098D8, $8B44F7AF, $FFFF5BB1, $895CD7BE, $6B901122, $FD987193, $A679438E, $49B40821, $F61E2562, $C040B340, $265E5A51, $E9B6C7AA, $D62F105D, $02441453, $D8A1E681, $E7D3FBC8, $21E1CDE6, $C33707D6, $F4D50D87, $455A14ED, $A9E3E905, $FCEFA3F8, $676F02D9, $8D2A4C8A, $FFFA3942, $8771F681, $6D9D6122, $FDE5380C, $A4BEEA44, $4BDECFA9, $F6BB4B60, $BEBFBC70, $289B7EC6, $EAA127FA, $D4EF3085, $04881D05, $D9D4D039, $E6DB99E5, $1FA27CF8, $C4AC5665, $F4292244, $432AFF97, $AB9423A7, $FC93A039, $655B59C3, $8F0CCC92, $FFEFF47D, $85845DD1, $6FA87E4F, $FE2CE6E0, $A3014314, $4E0811A1, $F7537E82, $BD3AF235, $2AD7D2BB, $EB86D391 );这段常量表就是MD5的“灵魂参数”只要任何一个数字抄错结果一定对不上标准摘要。所以我把48号以后那几行反复核对了三遍宁可抄慢一点也不能凭记忆写。3.3 初始化与更新Initialize负责把状态复位Update负责接收新数据。Update采用无类型参数设计这样调用方不管是传字节数组、文件缓冲区还是记录类型的字段都能直接传入。procedure TMD5.Initialize; begin FState[0] : $67452301; FState[1] : $EFCDAB89; FState[2] : $98BADCFE; FState[3] : $10325476; FBufferLen : 0; FTotalBytes : 0; FillChar(FBuffer, SizeOf(FBuffer), 0); end; procedure TMD5.Update(const AData; ADataLen: Integer); var p: PByte; ToCopy: Integer; begin p : AData; FTotalBytes : FTotalBytes ADataLen; if FBufferLen 0 then begin ToCopy : 64 - FBufferLen; if ToCopy ADataLen then ToCopy : ADataLen; Move(p^, FBuffer[FBufferLen], ToCopy); Inc(p, ToCopy); Inc(FBufferLen, ToCopy); Dec(ADataLen, ToCopy); if FBufferLen 64 then begin Transform(FBuffer[0]); FBufferLen : 0; end; end; while ADataLen 64 do begin Transform(p); Inc(p, 64); Dec(ADataLen, 64); end; if ADataLen 0 then begin Move(p^, FBuffer[0], ADataLen); FBufferLen : ADataLen; end; end;这段逻辑的核心思想是能凑满64字节就立刻做一次压缩变换凑不满就暂存在缓冲区等下次数据来了再拼。这样设计的好处是支持流式计算也就是你可以分多次把数据喂进来不需要一次性把整个文件或整段文本放进内存。对大文件来说这是关键能力。这里有个工程细节值得多说一句FTotalBytes是Int64类型一定要在Update入口第一时间累加。MD5填充时需要知道原始数据的比特长度这个长度如果算错摘要结果必然错。Int64的取值范围足够覆盖几乎所有实际文件不用担心溢出。3.4 压缩变换MD5的核心循环Transform一次处理64字节是整个算法的心脏。它把64字节拆成16个32位小端整数然后执行4轮、每轮16步的混合运算。procedure TMD5.Transform(const AData: PByte); var Block: array[0..63] of Byte; W: array[0..15] of Cardinal; A, B, C, D, F, G: Cardinal; Temp: Cardinal; J: Integer; begin Move(AData^, Block, 64); for J : 0 to 15 do begin W[J] : Cardinal(Block[J * 4]) or (Cardinal(Block[J * 4 1]) shl 8) or (Cardinal(Block[J * 4 2]) shl 16) or (Cardinal(Block[J * 4 3]) shl 24); end; A : FState[0]; B : FState[1]; C : FState[2]; D : FState[3]; for J : 0 to 63 do begin F : 0; G : 0; case J div 16 of 0: begin F : (B and C) or ((not B) and D); G : J; end; 1: begin F : (D and B) or ((not D) and C); G : (5 * J 1) mod 16; end; 2: begin F : B xor C xor D; G : (3 * J 5) mod 16; end; 3: begin F : C xor (B or (not D)); G : (7 * J) mod 16; end; end; Temp : D; D : C; C : B; B : B RollLeft(A F MD5_K[J] W[G], MD5_S[J]); A : Temp; end; Inc(FState[0], A); Inc(FState[1], B); Inc(FState[2], C); Inc(FState[3], D); end;这一段是新手比较容易看懵的地方其实规律很清晰每轮16步的操作模式完全一致不同的只是所用布尔函数和查表规则。变换过程中A、B、C、D四个变量就像四张座位在轮流换位每步都从右往左挪一档最右侧的变量拿到新的混合值。3.5 收尾填充、长度与输出Finalize负责处理最后的数据块。这里最忌讳的是直接用常规逻辑去拼填充因为边界条件很容易出错。正确做法是先记录原始比特长度再补0x80再补零最后写长度。function TMD5.Finalize: TMD5Digest; var Bits: Int64; PadLen: Integer; I: Integer; begin Bits : FTotalBytes * 8; FBuffer[FBufferLen] : $80; Inc(FBufferLen); PadLen : 56 - (FTotalBytes mod 64); if PadLen 0 then Inc(PadLen, 64); for I : 0 to PadLen - 2 do begin FBuffer[FBufferLen] : 0; Inc(FBufferLen); end; for I : 0 to 7 do begin FBuffer[FBufferLen] : Byte((Bits shr (I * 8)) and $FF); Inc(FBufferLen); end; while FBufferLen 64 do begin Transform(FBuffer[0]); if FBufferLen 64 then begin Move(FBuffer[64], FBuffer[0], FBufferLen - 64); Dec(FBufferLen, 64); end else FBufferLen : 0; end; for I : 0 to 3 do begin Result[I * 4] : Byte(FState[I] and $FF); Result[I * 4 1] : Byte((FState[I] shr 8) and $FF); Result[I * 4 2] : Byte((FState[I] shr 16) and $FF); Result[I * 4 3] : Byte((FState[I] shr 24) and $FF); end; end;关于PadLen的计算我吃过一次亏。最初我按“补到64字节整数倍”的思路去算结果算出来的摘要跟标准结果不一样后来冷静下来对照规范才明白填充的目标不是凑成64的整数倍而是先凑到56的倍数余数再留8字节写长度。这里一定要看清。3.6 摘要转字符串与便捷方法平时用MD5绝大多数场景要的是32位十六进制字符串。于是封装一个转换函数和一个便捷的哈希函数。class function TMD5.DigestToString(const ADigest: TMD5Digest): string; var I: Integer; begin Result : ; for I : 0 to 15 do Result : Result IntToHex(ADigest[I], 2); end; class function TMD5.GetHashString(const AData: TBytes): string; var MD5: TMD5; Digest: TMD5Digest; begin MD5 : TMD5.Create; try MD5.Initialize; if Length(AData) 0 then MD5.Update(AData[0], Length(AData)); Digest : MD5.Finalize; Result : DigestToString(Digest); finally MD5.Free; end; end;IntToHex输出大写的十六进制字符这其实是个容易忽略的兼容点。不同工具生成的MD5字符串大小写习惯不同做字符串比对前最好统一转成小写或者大写不然会出现一个看起来莫名其妙的问题。4. 业务层封装把组件用到真实项目里4.1 字符串哈希要解决编码问题现代Delphi的string是UnicodeString直接拿字符串的内存字节去算哈希得到的结果取决于字符编码。同样一个中文文本用UTF-8编码算出的MD5和用UTF-16算出的完全不同。所以最稳的做法是调用方明确指定编码组件内部统一用UTF-8。class function TMD5.GetStringHash(const AString: string): string; var Bytes: TBytes; begin Bytes : TEncoding.UTF8.GetBytes(AString); Result : GetHashString(Bytes); end;如果你在维护Delphi 7老项目没有TEncoding那就把字符串先转成AnsiString再取它的内存字节去算。关键原则只有一条编码策略要固定别让同一个字符串在不同机器、不同版本上算出不同的哈希值。4.2 大文件哈希用流式处理而不是一次性读入文件哈希是最常见的需求之一。有的初学者会把整个文件读进内存再算遇到几百MB甚至几个GB的安装包内存直接告急。正确做法是用文件流循环读取固定大小的缓冲区。class function TMD5.GetFileHash(const AFileName: string): string; var FS: TFileStream; MD5: TMD5; Buffer: array[0..65535] of Byte; ReadBytes: Integer; begin MD5 : TMD5.Create; FS : TFileStream.Create(AFileName, fmOpenRead or fmShareDenyWrite); try MD5.Initialize; while True do begin ReadBytes : FS.Read(Buffer, SizeOf(Buffer)); if ReadBytes 0 then Break; MD5.Update(Buffer, ReadBytes); end; Result : DigestToString(MD5.Finalize); finally FS.Free; MD5.Free; end; end;缓冲区大小我习惯用64KB。这个大小在多数字符串传输和多线程场景下都表现稳定既不会频繁调用Update导致性能损耗也不会占用太多内存。读流的时候还有一个细节务必确认文件流的当前位置在文件开头如果在这之前已经读了一部分数据哈希结果自然对不上。4.3 接口签名用HMAC-MD5替代裸MD5如果你用MD5做API签名直接把密钥拼接在参数后面算MD5有一个经典的风险长度扩展攻击。攻击者不需要知道密钥只要拿到一组合法的签名就可以在原始消息后面追加额外数据并重新计算出合法的摘要。稍微正规一点的做法是使用HMAC-MD5公式是HMAC MD5((Key XOR opad) MD5((Key XOR ipad) Message))其中ipad是0x36字节串opad是0x5C字节串。HMAC需要把密钥处理成64字节块超过64字节则先对密钥做MD5不足64字节则补零。原理不复杂代码实现的要点是分组操作那些异或后的64字节块再调用两次MD5。这是在现有MD5组件基础上很容易补出来的能力却能把裸拼接带来的安全隐患挡掉一大半。5. 性能优化让MD5组件真正高效起来5.1 一次处理64字节和四个局部变量很多Delphi版本的MD5代码跑不快问题通常不出在算法本身而是出在循环里反复访问对象字段、反复创建临时对象。核心循环里四个链接变量应该放在局部变量里跑最后再写回对象字段这样能明显减少内存访问开销。Transform里我用了Cardinal类型承载中间计算结果它天然环绕溢出符合MD5算法对模2^32运算的要求。使用时要确保编译器选项没有强制开启溢出检查否则边界情况会无缘无故抛异常。单独给单元头加{$OVERFLOWCHECKS OFF}是个一劳永逸的办法。5.2 减少不必要的拷贝与重分配Update接收32位整数作为数据长度这个设计让大块数据的处理非常顺畅。整块数据能直接走循环分支不会为了凑齐64字节做重复的Move拷贝。虽然Transform里保留了一次Move操作但这是为了更好做字节对齐访问实际性能影响很小换来的代码可读性是值得的。字符串哈希路径上也要注意TEncoding.UTF8.GetBytes返回的字节数组有分配开销但这是字符串转码的固有成本无法完全避开。真正的优化空间在调用层不要对一个几百万字符的字符串反复调用GetHashString一次性算完再复用结果。5.3 实测下来的性能体验在使用缓冲读取的文件哈希流程里主流桌面CPU处理100MB级别的文件基本是眨眼间完成。瓶颈几乎都在磁盘I/O而不是MD5本身的运算。即使是我这个纯Pascal实现在处理1GB级别文件时也没有在哈希计算环节感受到明显的性能瓶颈反倒是文件读取的缓冲大小对整体耗时的影响更直观。如果你对性能有极致要求可以进一步做三件事把Transform里的取模运算改成位与运算、把RollLeft声明为inline、在Update循环里避免重复检查缓冲区长度。这些都属于常规优化不必为了性能牺牲可读性。6. 常见问题与排查技巧实录6.1 哈希值对不上外部工具的结果这是我被问得最多的问题。现象是自己算出来的MD5和在线工具、和同事的代码不一样。排查顺序很固定先看编码字符串哈希的编码必须一致再看大小写IntToHex输出大写在线工具多半是小写比对前统一转换最后看数据类型是不是误把带终止符的字符串指针当成纯数据长度传进来了。6.2 空字符串的摘要特殊MD5对空字符串的摘要固定是d41d8cd98f00b204e9800998ecf8427e这是一个非常实用的自检用例。如果你的组件对空字符串算出来不是这个值说明填充逻辑有误很可能是长度字段写入方式不对或者PadLen的计算边界出了问题。把这个用例写进单元测试任何重构都能第一时间发现问题。6.3 同一个文件两次读取结果不一致如果文件哈希结果不稳定先别怀疑算法检查文件是否在读取过程中被其他程序修改了。我遇到过文件被另一个线程锁定着写导致前两次读取内容不同。打开文件流时建议加上fmShareDenyWrite拒绝别人在哈希期间写入。还有一个常见原因就是文件流打开后没有把Position归零。6.4 多线程环境下的使用限制TMD5类维护着内部状态同一个实例绝对不能在多线程里同时调用。正确做法是每个线程创建自己的实例或者用对象池管理、用锁保护。由于这个类本身很轻量创建成本极低我一般直接在线程内部Create用完即释放干脆利落。下表是几个高频问题的速查现象可能原因处理建议中文文本哈希不一致字符串编码不统一统一UTF-8编码并在接口文档写清楚与在线工具结果不同大小写不同或编码不同统一转小写再比对空字符串结果异常填充或长度写入出错先跑d41d8cd98f00b204e9800998ecf8427e用例大文件哈希慢缓冲区太小或磁盘I/O瓶颈缓冲区至少64KB流式处理多线程报错或结果串扰共享同一个实例每线程独立创建实例开启溢出检查后异常编译器选项问题关闭OverflowChecks或局部关闭7. 什么时候不该用MD5把安全边界讲透7.1 碰撞攻击的现实威胁从1996年就有学者指出MD5存在碰撞隐患2004年国内团队给出了实质性的碰撞攻击方法2013年又出现了利用MD5碰撞伪造数字证书的攻击演示。所谓碰撞就是能够构造两个不同内容但MD5值完全相同的数据。这在对抗恶意攻击的场景里是致命的。所以数字签名、证书校验、身份认证这类安全等级极高的场合不要用MD5。这个立场要非常明确不要因为它是经典算法就不好意思说它过时。7.2 口令存储不推荐MD5口令字段用MD5存储算是历史遗留问题但现在绝不能在新系统里这么干。显卡算力上来了MD5对口令的暴力破解快得吓人加上彩虹表的存在简单口令基本是秒破。就算加盐也改变不了MD5计算速度太快这个根本缺陷。新项目对口令存储应该用专门为口令设计的慢哈希算法比如bcrypt、scrypt、Argon2。这一类算法的特点就是故意算得慢、内存占用大让攻击者的暴力破解成本直线上升。存量系统如果没法立刻迁移算法至少要做到加随机盐、分段多次迭代、对比时用恒定时间比较函数同时给迁移留出兼容窗口。7.3 签名场景用HMAC而不是裸MD5API签名场景不建议拿裸MD5拼接密钥。最典型的问题是长度扩展攻击之前已经提过。换成HMAC-MD5后安全性会提升一个层次。如果安全性要求更高直接用HMAC-SHA256配合项目实际的密钥管理体系才是干净的做法。结语几点实际操作中的体感这套TMD5组件我在多个内部项目里复用过最大的感受是写一个MD5类并不难难的是把边界条件和编码问题处理到位。尤其是Finalize里缓冲区尺寸和填充公式第一次写一定要对照最经典的实现逐行检查别嫌麻烦。如果你准备把这套代码落到自己的项目里我建议第一步先做一个最小的单元测试分别对空字符串、字符串abc、一段超过64字节的长文本跑一遍和权威工具比对结果。这三个用例能覆盖填充逻辑的绝大多数分支。等哈希值全部吻合再去接文件流和接口签名心里就踏实得多。另外如果你在维护老系统暂时不能把口令算法换掉的务必在代码注释里写明算法选择的前因后果、换算法时该动哪些模块。这种事不能只靠记忆项目文件里的注释才是留给后来人的真正资产。
阅读完成 · 觉得有帮助？
