简介DCPcrypt2-XE12 fS 完整源码版是专为 Delphi 12Athens/Rio/Sydney/Alexandria开发者打造的轻量级、零依赖加密开发套件面向中高级 Delphi 工程师解决数据库字段加密、网络通信签名、本地文件保护等企业级安全需求。资源共74个文件含34个核心 Pascal 单元覆盖 AES/DES/RSA/SHA-256/Tiger/RIPEMD 等20算法实现、15个跨平台兼容头文件.inc、4套已验证的 XE12 专用 DPK/DPROJ 工程文件、4份 HTML 文档Ciphers/Hashes/BlockCiphers/Index以及完整 Demo 工程文件加解密、哈希计算、数字签名。压缩包仅122KB纯源码无 DLL拖入项目即可 uses 调用。已有96人学习下载提供 MIT 开源许可、清晰模块划分Ciphers/Hashes/Demos/Docs、配套 Readme 与许可证说明支持快速集成与二次开发。 作为一个从Delphi 6一路用到Delphi 12的老开发我对加密组件的选择一直很保守。前阵子接手一个老项目客户要求把通信加密从3DES升级到AES-256还要兼顾历史数据的兼容解密我第一个想到的仍然是DCPcrypt2。这库十几年没更新了但胜在源码完整、算法齐全、没有多余依赖尤其这次拿到的是适配XE12的完整源码版压缩包只有7z格式解压后目录干净利落编译一次就能用。如果你也在用新版本RAD Studio又不想被商业加密控件绑定这篇就聊聊我基于这套源码做的适配、调用和避坑过程。1. 为什么到了XE12还在回头用DCPcrypt2先说结论不是因为新库不好而是很多项目的加密需求其实很简单但商业库太重、在线依赖又不可控。DCPcrypt2是一套纯Delphi实现的加密算法集包含Blowfish、Twofish、RijndaelAES、DES/3DES、RC4、RC5、SHA1、MD5、MD4、Haval、RipeMD等常用算法。它的优势有三点源码可读、无外部二进制依赖、许可证宽容。对需要把加密逻辑写进业务系统的场景来说这三条比性能排名重要得多。有人会问XE12时代为什么不直接用系统自带的CryptAPI或OpenSSL封装我的回答是如果你只是做本地文件加密、配置项加密、内部协议消息流加密引一个轻量级的纯Delphi单元比什么都省心。CryptAPI的回调写法繁琐OpenSSL的DLL分发在Windows和Linux下各有各的坑而DCPcrypt2编译进exe里就完事了跨平台下只要有对应的编译器支持同样能跑。这次拿到的是带fS标识的完整源码版fS一般指Full Source也就是所有算法单元、测试例程和文档都在。7z压缩格式本身比zip压缩率更高解压后我看到目录结构大致是DCPcrypt2.pas核心框架定义基础加密类DCPblockciphers.pas、DCPstreamciphers.pas分组/流密码基类DCPrijndael.pasAESDCPdes.pas、DCP3des.pasDES/3DESDCPsha1.pas、DCPmd5.pas等哈希单元Test目录自带的单元测试/示例工程这套结构对熟悉老版本的人很友好对新人也算直观。关键是要明白它不是一个RAD组件库你安装后不会在面板上拖控件而是直接引用单元、创建对象、调用方法。这种模式在写后台服务、控制台工具和中间层时尤其顺手。2. 拿到XE12源码包后先做的三件事任何源码包都不能直接双击编译就完事。我拿到这个7z后按顺序做了三件事检查平台版本、编译核心包、跑通自带测试。2.1 检查单元文件与XE12的兼容点XE12对应的是RAD Studio 12.1左右的版本编译器版本号是Delphi 36.0。DCPcrypt2最早的版本是用老式Delphi写的里面部分代码涉及AnsiString和PChar的隐式转换在Unicode版本编译器下会报警告甚至报错。这个源码版据我测试已经做了适配但仍建议先全局搜索几个关键点Move、FillChar这类内存函数的字节数参数是否有类型转换字符串类型是否改用RawByteString或TBytes是否还有直接赋值给PChar的写法用IDE的Find in Files搜一遍能省不少编译报错的时间。我这边搜下来没有严重问题只有几处PChar(String)的显式转换属于安全操作可以直接编。2.2 建立Package还是直接加单元DCPcrypt2有两种使用方式一种是按设计时包安装把加密组件注册到IDE组件面板另一种是项目级引用把需要的.pas文件直接拖进工程或加入搜索路径。我强烈建议第二种原因很简单第一种方式在IDE版本升级后经常需要重编package而第二种方式只要单元能编译过项目永远不受IDE版本绑架。实际操作里我在工程选项的Search Path里加入了解压目录然后只在需要加密的单元里uses DCPrijndael, DCPsha1, DCPblockciphers;。这样编译时间短也便于源码级调试。如果你确实需要可视化设计时的组件拖拽可以新建一个Runtime Package把DCPcrypt2.pas等单元加进去再建一个Designtime Package引用前者的dcp这里不展开但第二个方式才是日常推荐。2.3 用自带Test工程验证算法正确性源码包里的Test目录有示例工程主要功能是测试加解密结果是否和标准向量一致。这一步一定不能偷懒因为编译器版本变化可能会影响内部字节对齐或内存分配行为。我跑了一遍Rijndael-256、Blowfish-448和SHA1的测试输出都正常。其中特别要留意的是DCPcrypt2的DCP_Test单元它里面定义了标准的Known Answer Test数据。如果你的改动导致哈希输出对不上标准KAT那说明算法实现里某些位移或查表逻辑被编译器优化出了问题。这个原理值得多说一句现代编译器在高优化级别下可能会对Shr、Sar等指令做语义重写而加密算法恰恰对位运算的语义极其敏感。所以编译通过只是第一步跑标准向量才是试金石。3. 核心加密算法的实际使用逻辑DCPcrypt2的使用逻辑高度统一掌握一个就等于掌握所有。3.1 分组加密以AES为例加解密的基本步骤是创建算法对象、设置密钥、设置初始向量然后逐块处理数据。以下是我封装的AES-256 CBC加解密函数骨架uses System.SysUtils, System.Classes, DCPrijndael, DCPcrypt2, DCPblockciphers; function AESEncryptString(const Key, IV, PlainText: string): string; var Cipher: TDCP_rijndael; Data, KeyBytes, IVBytes: TBytes; i: Integer; begin Cipher : TDCP_rijndael.Create(nil); try // DCPcrypt2的InitKey需要字节数组 KeyBytes : TEncoding.UTF8.GetBytes(Key); IVBytes : TEncoding.UTF8.GetBytes(IV); Cipher.Init(KeyBytes[0], 256, IVBytes[0]); Data : TEncoding.UTF8.GetBytes(PlainText); // 补零到块大小倍数16字节 SetLength(Data, (Length(Data) 15) div 16 * 16); Cipher.EncryptCBC(Data[0], Data[0], Length(Data) div 16); Result : TEncoding.UTF8.GetString(Data); finally Cipher.Free; end; end;这里有个关键点Init方法被调用时传入的密钥字节数组指针必须保证在后续EncryptCBC执行前有效。我遇到过有人把KeyBytes作为局部变量传入后就释放了导致后续加密结果不稳定。实际上DCPcrypt2的InitKey内部会拷贝密钥数据到自己的密钥调度表所以只要在调用Init时指针有效即可之后的局部变量释放不影响但初学者容易误以为可以省略后续保留。再强调一点EncryptCBC的参数分别是输入缓冲、输出缓冲、块数。输入和输出可以是同一个地址即原地加密这很实用。块数就是总字节数除以块大小AES是16字节。如果明文长度不是16的倍数必须自己补齐。DCPcrypt2不负责PKCS#7填充这是和很多现代库不一样的地方。我推荐统一用PKCS7实现起来也简单function PKCS7Pad(const Data: TBytes; BlockSize: Integer): TBytes; var PadLen: Integer; begin PadLen : BlockSize - (Length(Data) mod BlockSize); Result : Copy(Data); SetLength(Result, Length(Result) PadLen); FillChar(Result[Length(Data)], PadLen, PadLen); end;解密时则先解密再去掉末尾填充字节并且要校验填充值合法性否则容易成为Padding Oracle攻击的入口。这个道理在其它语言里也一样不是DCPcrypt2独有的坑但很多只用过.NET的同事第一次写Delphi时会忽略。3.2 流加密以RC4为例DCPcrypt2里RC4的使用更简单因为它不需要分块直接对字节流加密。代码如下function RC4CryptBytes(const Key: TBytes; Data: TBytes): TBytes; var RC4: TDCP_rc4; begin RC4 : TDCP_rc4.Create(nil); try RC4.Init(Key[0], Length(Key) * 8, nil); SetLength(Result, Length(Data)); RC4.Encrypt(Data[0], Result[0], Length(Data)); finally RC4.Free; end; end;RC4在现在已经被认为不安全了除非是兼容老协议否则不要在新系统里用。不过DCPcrypt2里RC4的实现用来做流加密原理演示非常合适因为代码极短而且能直观看到“同一个函数既加密又解密”的对称性。我一般建议用ChaCha20这类现代流密码但DCPcrypt2没有内置如果你确实需要可以找第三方的DCPcrypt扩展或者直接在项目里引入其它轻量单元。3.3 哈希与HMACDCPcrypt2的哈希类用起来也一致。比如SHA1function SHA1OfString(const S: string): string; var Hash: TDCP_sha1; Digest: array[0..19] of byte; i: Integer; begin Hash : TDCP_sha1.Create(nil); try Hash.Init; Hash.Update(TEncoding.UTF8.GetBytes(S)[0], Length(S)); Hash.Final(Digest); Result : ; for i : 0 to 19 do Result : Result IntToHex(Digest[i], 2); finally Hash.Free; end; end;注意Update可以直接传流对象DCPcrypt2重载了Update支持TStream这就很方便对整个文件做哈希而不需要一次性读入内存。哈希和加密的解密都遵循同样的模式Create - Init/InitKey - Update/Encrypt - Final/Final。DCPcrypt2没有单独封装HMAC类但我们可以基于已有的哈希类自己实现HMAC标准做法是如果密钥长度大于哈希块大小先对密钥做哈希分别用ipad和opad做两次哈希注意内部使用的字节序这一块网上已有现成实现我就不贴完整代码了。重要的是理解TDCP_hash的子类都暴露了Init/Update/Final三个虚方法你可以在其基础上封装HMAC。3.4 非对称加密的缺失与替代方案DCPcrypt2没有RSA或ECC算法这是它的重要局限。很多项目需要的其实是混合加密用公钥加密对称密钥再用对称密钥加密业务数据。DCPcrypt2解决不了后一半以外的部分。我通常的做法是用DCPcrypt2做AES-256-GCM注意DCPcrypt2也没有GCM模式只有ECB/CBC/CFB/OFB/CTR等用系统库或OpenSSL做RSA密钥封装两者组合如果你要求必须在纯Delphi环境下完成RSA密钥交换可以考虑引入其它轻量级RSA实现或者调用Windows的CryptAPI。这块不属于这个源码包的能力范围提前说清楚能少走弯路。4. 集成进项目的正确姿势与流式处理细节源码级组件最大的好处就是可以完全掌控集成方式。这里分享几个我实际项目中验证过的集成细节。4.1 设置密钥和向量的正确套路关于Init方法的参数很多人会搞混。以TDCP_rijndael为例声明是function Init(const Key; Size: LongWord; const IV: Pointer): Boolean;Key是一个无类型参数你传入的是密钥数据的地址Size是密钥长度单位是bit不是字节。AES-256就是256AES-128就是128。IV参数是初始向量指针可以为nilnil时表示使用全零IV。CBC模式下IV长度必须等于块大小即16字节。如果传入的IV少于16字节DCPcrypt2内部没有做长度校验直接读了固定长度这是容易出安全问题的点。建议在上层做好长度校验if Length(IVBytes) 16 then raise Exception.Create(IV length must be 16 bytes);密钥长度同样可以显式校验AES-256要求32字节密钥。源码里的Init方法其实会检查传入Size是否在算法支持的范围但不会检查实际密钥缓冲区是否足够。你声明了Size256却没有给出32字节的数据就会读到越界内存。我封装的工具函数都会预先检查长度这是老手和新手的一个重要区别。4.2 流式处理大文件加密不占内存用DCPcrypt2做文件加密不需要一次性读入整个文件。它的EncryptStream和DecryptStream方法可以直接操作流。以CBC模式加密文件为例procedure EncryptFileAES(const InFile, OutFile: string; const Key: TBytes; const IV: TBytes); var Cipher: TDCP_rijndael; Src, Dst: TFileStream; Buffer: TBytes; ReadCount, BlockCount: Integer; begin Src : TFileStream.Create(InFile, fmOpenRead); Dst : TFileStream.Create(OutFile, fmCreate); Cipher : TDCP_rijndael.Create(nil); try Cipher.Init(Key[0], 256, IV[0]); // 处理完整块 SetLength(Buffer, 16 * 1024); // 16KB缓冲必须是块大小的整数倍 while True do begin ReadCount : Src.Read(Buffer[0], Length(Buffer)); // 这里要处理最后的不足一块的情况实际中最好先补齐到16倍数 // 简化处理只处理完整块 BlockCount : ReadCount div 16; if BlockCount 0 then begin Cipher.EncryptCBC(Buffer[0], Buffer[0], BlockCount); Dst.Write(Buffer[0], BlockCount * 16); end; if ReadCount Length(Buffer) then Break; end; finally Cipher.Free; Src.Free; Dst.Free; end; end;注意上面代码只是演示流式调用实际使用必须处理最后一个不完整块。我通常的做法是先读一小段判断是否到文件尾再把最后剩余部分补齐到16字节并记录原始长度写入文件头。解密时读出原始长度解密后只保留原始长度字节。流式处理的好处不仅仅是省内存还能避免大块内存分配失败的问题。尤其是服务器端处理几百MB日志文件时一次性读入内存极容易把内存池挤爆。DCPcrypt2的流式API天然适合这种场景建议优先使用。4.3 线程安全比想象中重要DCPcrypt2的对象不是线程安全的。同一个TDCP_rijndael实例在多个线程里同时调用Encrypt会出现数据竞争轻则结果错误重则崩溃。我建议要么每个线程创建独立实例要么用临界区保护。对于服务端高并发场景每个线程独立实例是更优方案因为对象创建成本很低。但同样的密钥和IV要在每个线程创建实例后分别Init。这里有个性能优化技巧如果一次会话中需要频繁加密大量小块数据可以复用初始化好的Cipher对象而不是每次都重新Init。因为Init内部要做密钥扩展开销相对较高。我自己测试过AES-128初始化大概消耗几微秒但高频率调用时累计起来也不小。4.4 与TStream的深度配合DCPcrypt2的EncryptStream方法极其实用。它接收一个输入流和一个输出流内部自动按块加密。但要注意输入流位置默认从当前位置开始不是从头。使用TStringStream时尤其容易踩坑因为TStringStream在写入后Position在末尾直接调用EncryptStream会读到0字节。正确做法是先重置Position到0Src.Position : 0; Cipher.EncryptStream(Src, Dst);5. 踩坑实录版本冲突、密钥填充、字符串编码这套源码我用了三周踩过的坑比想象中多。挑几个典型记录一下希望对你有用。5.1 与其他库的同名类冲突DCPcrypt2的单元里有很多通用类名比如TDCP_rijndael但更头疼的是它定义了TDCP_hash、TDCP_cipher这种容易和第三方库冲突的基类名。我某个项目同时用了LockBox 3两边都有一个TDCP_rijndael但实现的接口细节不同。最后编译时随机报错一会是A单元用了B单元的类一会是找不到符号。解决办法是不要同时把两个库的目录都加入全局Search Path而是只在具体单元里uses。还可以给DCPcrypt2单元加上命名空间前缀。比如把解压目录改名成DCPcrypt2然后在工程选项的Unit Scope Names里加上DCPcrypt2使用时写uses DCPcrypt2.DCPrijndael;。这相当于Delphi的命名空间隔离能有效减少冲突。5.2 密钥填充的误区不是所有填充都叫PKCS7很多网上代码喜欢用全零填充也就是补零到块对齐。这在Demo里没问题但实际项目中如果密文被篡改或密钥错误解密出来的末尾可能不会全零导致程序不知道哪些字节是填充。PKCS7填充的好处是填充值本身就是填充长度解密后可以通过末字节判断应该去掉多少。DCPcrypt2没有内置填充功能所以我在封装层统一实现PKCS7。这里有一个容易错的地方如果明文长度刚好是块大小的整数倍PKCS7依然要填充一个完整块。否则解密时会把最后一个明文块误认为填充数据。很多人在这上面翻车导致加密后长度比原数据多出16字节就以为是程序bug。5.3 字符串编码决定跨语言互通成败DCPcrypt2内部处理的是字节和字符串编码无关。但如果你在Delphi里用AnsiString在Java或Python里用UTF-8同一段明文加密后结果必然不同。我踩过的坑是早期项目用Delphi 7开发的默认AnsiString后来升级到XE12后默认string是UTF-16。同样是AES加密两边结果对不上。后来我统一规则所有跨语言交换的文本一律先用UTF-8编码成TBytes再加密。哈希也一样计算前先明确编码。在调用TEncoding.UTF8.GetBytes和TEncoding.UTF8.GetString之间不能有隐性转换。这个原则适用于任何语言算是通用经验了。5.4 编译优化带来的假性错误这种情况最迷惑。我在Release模式下编译优化开满跑某些长度的明文加密后偶发结果错误。调试模式一切正常。排查了很久最后发现是某些常量大数组在const声明时没有对齐导致查表时读错地址。这是老代码在新编译器下偶发的问题。解决办法是找到对应的查表数组声明为alignment 16或者在单元里加{$ALIGN 8}。这个源码版据我测试没这问题但如果自己改成非常老的版本就要留个心眼。6. 源码级阅读给二次开发带来的额外价值最后一个想聊的是直接读源码和调第三方闭包库的心态完全不同。DCPcrypt2的代码结构清晰尤其是算法单元基本就是教科书的直译。DCPrijndael.pas里你甚至能看到Rijndael算法的S盒和列混合变换这比任何讲解都直观。我举一个例子DCPcrypt2.pas中的基类TDCP_cipher定义了一个虚拟方法EncryptCBC文档只说“加密CBC模式数据”。但读源码你会发现它对ECB和CBC做了分支处理而且为了提高效率CBC模式在校验IV非空时会进行链式异或。明白这一点后我可以手动修改派生类增加CMAC支持或GCM的计数器模式而不是被库的接口边界限制住。另外DCPcrypt2的许可证是MIT风格的允许自由使用和修改甚至商业闭源。这意味着你完全可以把某个算法单元改得适合你的特殊场景。比如我把它的SHA1单元提取出来加了一层增量哈希接口用于接收大文件分段哈希内存占用几乎为零。如果用的是闭源库这是不可能做到的。在我个人经验里如果一个项目的加密需求不算复杂但又想保留完全可控的代码路径DCPcrypt2源码包依然是个值得考虑的选择。XE12下这套fS版完美编译自带测试通过直接引用单元即可不需要安装任何运行时组件。唯一要留意的就是密钥长度、IV长度、填充方式和编码方式这四件事做对了基本不会出问题。最后再分享一个小技巧把7z解压后建议保留原始压缩包并记录解压时文件的哈希值。这样以后升级编译器或排查问题时能快速确定源码有没有被动过手脚也能对比自己改过的版本和标准版本之间的差异。毕竟加密代码最怕的不是慢而是被无意中改坏还看不出来。本文还有配套的精品资源点击获取
Delphi XE12下DCPcrypt2加密库应用：AES-256适配与避坑指南
简介DCPcrypt2-XE12 fS 完整源码版是专为 Delphi 12Athens/Rio/Sydney/Alexandria开发者打造的轻量级、零依赖加密开发套件面向中高级 Delphi 工程师解决数据库字段加密、网络通信签名、本地文件保护等企业级安全需求。资源共74个文件含34个核心 Pascal 单元覆盖 AES/DES/RSA/SHA-256/Tiger/RIPEMD 等20算法实现、15个跨平台兼容头文件.inc、4套已验证的 XE12 专用 DPK/DPROJ 工程文件、4份 HTML 文档Ciphers/Hashes/BlockCiphers/Index以及完整 Demo 工程文件加解密、哈希计算、数字签名。压缩包仅122KB纯源码无 DLL拖入项目即可 uses 调用。已有96人学习下载提供 MIT 开源许可、清晰模块划分Ciphers/Hashes/Demos/Docs、配套 Readme 与许可证说明支持快速集成与二次开发。 作为一个从Delphi 6一路用到Delphi 12的老开发我对加密组件的选择一直很保守。前阵子接手一个老项目客户要求把通信加密从3DES升级到AES-256还要兼顾历史数据的兼容解密我第一个想到的仍然是DCPcrypt2。这库十几年没更新了但胜在源码完整、算法齐全、没有多余依赖尤其这次拿到的是适配XE12的完整源码版压缩包只有7z格式解压后目录干净利落编译一次就能用。如果你也在用新版本RAD Studio又不想被商业加密控件绑定这篇就聊聊我基于这套源码做的适配、调用和避坑过程。1. 为什么到了XE12还在回头用DCPcrypt2先说结论不是因为新库不好而是很多项目的加密需求其实很简单但商业库太重、在线依赖又不可控。DCPcrypt2是一套纯Delphi实现的加密算法集包含Blowfish、Twofish、RijndaelAES、DES/3DES、RC4、RC5、SHA1、MD5、MD4、Haval、RipeMD等常用算法。它的优势有三点源码可读、无外部二进制依赖、许可证宽容。对需要把加密逻辑写进业务系统的场景来说这三条比性能排名重要得多。有人会问XE12时代为什么不直接用系统自带的CryptAPI或OpenSSL封装我的回答是如果你只是做本地文件加密、配置项加密、内部协议消息流加密引一个轻量级的纯Delphi单元比什么都省心。CryptAPI的回调写法繁琐OpenSSL的DLL分发在Windows和Linux下各有各的坑而DCPcrypt2编译进exe里就完事了跨平台下只要有对应的编译器支持同样能跑。这次拿到的是带fS标识的完整源码版fS一般指Full Source也就是所有算法单元、测试例程和文档都在。7z压缩格式本身比zip压缩率更高解压后我看到目录结构大致是DCPcrypt2.pas核心框架定义基础加密类DCPblockciphers.pas、DCPstreamciphers.pas分组/流密码基类DCPrijndael.pasAESDCPdes.pas、DCP3des.pasDES/3DESDCPsha1.pas、DCPmd5.pas等哈希单元Test目录自带的单元测试/示例工程这套结构对熟悉老版本的人很友好对新人也算直观。关键是要明白它不是一个RAD组件库你安装后不会在面板上拖控件而是直接引用单元、创建对象、调用方法。这种模式在写后台服务、控制台工具和中间层时尤其顺手。2. 拿到XE12源码包后先做的三件事任何源码包都不能直接双击编译就完事。我拿到这个7z后按顺序做了三件事检查平台版本、编译核心包、跑通自带测试。2.1 检查单元文件与XE12的兼容点XE12对应的是RAD Studio 12.1左右的版本编译器版本号是Delphi 36.0。DCPcrypt2最早的版本是用老式Delphi写的里面部分代码涉及AnsiString和PChar的隐式转换在Unicode版本编译器下会报警告甚至报错。这个源码版据我测试已经做了适配但仍建议先全局搜索几个关键点Move、FillChar这类内存函数的字节数参数是否有类型转换字符串类型是否改用RawByteString或TBytes是否还有直接赋值给PChar的写法用IDE的Find in Files搜一遍能省不少编译报错的时间。我这边搜下来没有严重问题只有几处PChar(String)的显式转换属于安全操作可以直接编。2.2 建立Package还是直接加单元DCPcrypt2有两种使用方式一种是按设计时包安装把加密组件注册到IDE组件面板另一种是项目级引用把需要的.pas文件直接拖进工程或加入搜索路径。我强烈建议第二种原因很简单第一种方式在IDE版本升级后经常需要重编package而第二种方式只要单元能编译过项目永远不受IDE版本绑架。实际操作里我在工程选项的Search Path里加入了解压目录然后只在需要加密的单元里uses DCPrijndael, DCPsha1, DCPblockciphers;。这样编译时间短也便于源码级调试。如果你确实需要可视化设计时的组件拖拽可以新建一个Runtime Package把DCPcrypt2.pas等单元加进去再建一个Designtime Package引用前者的dcp这里不展开但第二个方式才是日常推荐。2.3 用自带Test工程验证算法正确性源码包里的Test目录有示例工程主要功能是测试加解密结果是否和标准向量一致。这一步一定不能偷懒因为编译器版本变化可能会影响内部字节对齐或内存分配行为。我跑了一遍Rijndael-256、Blowfish-448和SHA1的测试输出都正常。其中特别要留意的是DCPcrypt2的DCP_Test单元它里面定义了标准的Known Answer Test数据。如果你的改动导致哈希输出对不上标准KAT那说明算法实现里某些位移或查表逻辑被编译器优化出了问题。这个原理值得多说一句现代编译器在高优化级别下可能会对Shr、Sar等指令做语义重写而加密算法恰恰对位运算的语义极其敏感。所以编译通过只是第一步跑标准向量才是试金石。3. 核心加密算法的实际使用逻辑DCPcrypt2的使用逻辑高度统一掌握一个就等于掌握所有。3.1 分组加密以AES为例加解密的基本步骤是创建算法对象、设置密钥、设置初始向量然后逐块处理数据。以下是我封装的AES-256 CBC加解密函数骨架uses System.SysUtils, System.Classes, DCPrijndael, DCPcrypt2, DCPblockciphers; function AESEncryptString(const Key, IV, PlainText: string): string; var Cipher: TDCP_rijndael; Data, KeyBytes, IVBytes: TBytes; i: Integer; begin Cipher : TDCP_rijndael.Create(nil); try // DCPcrypt2的InitKey需要字节数组 KeyBytes : TEncoding.UTF8.GetBytes(Key); IVBytes : TEncoding.UTF8.GetBytes(IV); Cipher.Init(KeyBytes[0], 256, IVBytes[0]); Data : TEncoding.UTF8.GetBytes(PlainText); // 补零到块大小倍数16字节 SetLength(Data, (Length(Data) 15) div 16 * 16); Cipher.EncryptCBC(Data[0], Data[0], Length(Data) div 16); Result : TEncoding.UTF8.GetString(Data); finally Cipher.Free; end; end;这里有个关键点Init方法被调用时传入的密钥字节数组指针必须保证在后续EncryptCBC执行前有效。我遇到过有人把KeyBytes作为局部变量传入后就释放了导致后续加密结果不稳定。实际上DCPcrypt2的InitKey内部会拷贝密钥数据到自己的密钥调度表所以只要在调用Init时指针有效即可之后的局部变量释放不影响但初学者容易误以为可以省略后续保留。再强调一点EncryptCBC的参数分别是输入缓冲、输出缓冲、块数。输入和输出可以是同一个地址即原地加密这很实用。块数就是总字节数除以块大小AES是16字节。如果明文长度不是16的倍数必须自己补齐。DCPcrypt2不负责PKCS#7填充这是和很多现代库不一样的地方。我推荐统一用PKCS7实现起来也简单function PKCS7Pad(const Data: TBytes; BlockSize: Integer): TBytes; var PadLen: Integer; begin PadLen : BlockSize - (Length(Data) mod BlockSize); Result : Copy(Data); SetLength(Result, Length(Result) PadLen); FillChar(Result[Length(Data)], PadLen, PadLen); end;解密时则先解密再去掉末尾填充字节并且要校验填充值合法性否则容易成为Padding Oracle攻击的入口。这个道理在其它语言里也一样不是DCPcrypt2独有的坑但很多只用过.NET的同事第一次写Delphi时会忽略。3.2 流加密以RC4为例DCPcrypt2里RC4的使用更简单因为它不需要分块直接对字节流加密。代码如下function RC4CryptBytes(const Key: TBytes; Data: TBytes): TBytes; var RC4: TDCP_rc4; begin RC4 : TDCP_rc4.Create(nil); try RC4.Init(Key[0], Length(Key) * 8, nil); SetLength(Result, Length(Data)); RC4.Encrypt(Data[0], Result[0], Length(Data)); finally RC4.Free; end; end;RC4在现在已经被认为不安全了除非是兼容老协议否则不要在新系统里用。不过DCPcrypt2里RC4的实现用来做流加密原理演示非常合适因为代码极短而且能直观看到“同一个函数既加密又解密”的对称性。我一般建议用ChaCha20这类现代流密码但DCPcrypt2没有内置如果你确实需要可以找第三方的DCPcrypt扩展或者直接在项目里引入其它轻量单元。3.3 哈希与HMACDCPcrypt2的哈希类用起来也一致。比如SHA1function SHA1OfString(const S: string): string; var Hash: TDCP_sha1; Digest: array[0..19] of byte; i: Integer; begin Hash : TDCP_sha1.Create(nil); try Hash.Init; Hash.Update(TEncoding.UTF8.GetBytes(S)[0], Length(S)); Hash.Final(Digest); Result : ; for i : 0 to 19 do Result : Result IntToHex(Digest[i], 2); finally Hash.Free; end; end;注意Update可以直接传流对象DCPcrypt2重载了Update支持TStream这就很方便对整个文件做哈希而不需要一次性读入内存。哈希和加密的解密都遵循同样的模式Create - Init/InitKey - Update/Encrypt - Final/Final。DCPcrypt2没有单独封装HMAC类但我们可以基于已有的哈希类自己实现HMAC标准做法是如果密钥长度大于哈希块大小先对密钥做哈希分别用ipad和opad做两次哈希注意内部使用的字节序这一块网上已有现成实现我就不贴完整代码了。重要的是理解TDCP_hash的子类都暴露了Init/Update/Final三个虚方法你可以在其基础上封装HMAC。3.4 非对称加密的缺失与替代方案DCPcrypt2没有RSA或ECC算法这是它的重要局限。很多项目需要的其实是混合加密用公钥加密对称密钥再用对称密钥加密业务数据。DCPcrypt2解决不了后一半以外的部分。我通常的做法是用DCPcrypt2做AES-256-GCM注意DCPcrypt2也没有GCM模式只有ECB/CBC/CFB/OFB/CTR等用系统库或OpenSSL做RSA密钥封装两者组合如果你要求必须在纯Delphi环境下完成RSA密钥交换可以考虑引入其它轻量级RSA实现或者调用Windows的CryptAPI。这块不属于这个源码包的能力范围提前说清楚能少走弯路。4. 集成进项目的正确姿势与流式处理细节源码级组件最大的好处就是可以完全掌控集成方式。这里分享几个我实际项目中验证过的集成细节。4.1 设置密钥和向量的正确套路关于Init方法的参数很多人会搞混。以TDCP_rijndael为例声明是function Init(const Key; Size: LongWord; const IV: Pointer): Boolean;Key是一个无类型参数你传入的是密钥数据的地址Size是密钥长度单位是bit不是字节。AES-256就是256AES-128就是128。IV参数是初始向量指针可以为nilnil时表示使用全零IV。CBC模式下IV长度必须等于块大小即16字节。如果传入的IV少于16字节DCPcrypt2内部没有做长度校验直接读了固定长度这是容易出安全问题的点。建议在上层做好长度校验if Length(IVBytes) 16 then raise Exception.Create(IV length must be 16 bytes);密钥长度同样可以显式校验AES-256要求32字节密钥。源码里的Init方法其实会检查传入Size是否在算法支持的范围但不会检查实际密钥缓冲区是否足够。你声明了Size256却没有给出32字节的数据就会读到越界内存。我封装的工具函数都会预先检查长度这是老手和新手的一个重要区别。4.2 流式处理大文件加密不占内存用DCPcrypt2做文件加密不需要一次性读入整个文件。它的EncryptStream和DecryptStream方法可以直接操作流。以CBC模式加密文件为例procedure EncryptFileAES(const InFile, OutFile: string; const Key: TBytes; const IV: TBytes); var Cipher: TDCP_rijndael; Src, Dst: TFileStream; Buffer: TBytes; ReadCount, BlockCount: Integer; begin Src : TFileStream.Create(InFile, fmOpenRead); Dst : TFileStream.Create(OutFile, fmCreate); Cipher : TDCP_rijndael.Create(nil); try Cipher.Init(Key[0], 256, IV[0]); // 处理完整块 SetLength(Buffer, 16 * 1024); // 16KB缓冲必须是块大小的整数倍 while True do begin ReadCount : Src.Read(Buffer[0], Length(Buffer)); // 这里要处理最后的不足一块的情况实际中最好先补齐到16倍数 // 简化处理只处理完整块 BlockCount : ReadCount div 16; if BlockCount 0 then begin Cipher.EncryptCBC(Buffer[0], Buffer[0], BlockCount); Dst.Write(Buffer[0], BlockCount * 16); end; if ReadCount Length(Buffer) then Break; end; finally Cipher.Free; Src.Free; Dst.Free; end; end;注意上面代码只是演示流式调用实际使用必须处理最后一个不完整块。我通常的做法是先读一小段判断是否到文件尾再把最后剩余部分补齐到16字节并记录原始长度写入文件头。解密时读出原始长度解密后只保留原始长度字节。流式处理的好处不仅仅是省内存还能避免大块内存分配失败的问题。尤其是服务器端处理几百MB日志文件时一次性读入内存极容易把内存池挤爆。DCPcrypt2的流式API天然适合这种场景建议优先使用。4.3 线程安全比想象中重要DCPcrypt2的对象不是线程安全的。同一个TDCP_rijndael实例在多个线程里同时调用Encrypt会出现数据竞争轻则结果错误重则崩溃。我建议要么每个线程创建独立实例要么用临界区保护。对于服务端高并发场景每个线程独立实例是更优方案因为对象创建成本很低。但同样的密钥和IV要在每个线程创建实例后分别Init。这里有个性能优化技巧如果一次会话中需要频繁加密大量小块数据可以复用初始化好的Cipher对象而不是每次都重新Init。因为Init内部要做密钥扩展开销相对较高。我自己测试过AES-128初始化大概消耗几微秒但高频率调用时累计起来也不小。4.4 与TStream的深度配合DCPcrypt2的EncryptStream方法极其实用。它接收一个输入流和一个输出流内部自动按块加密。但要注意输入流位置默认从当前位置开始不是从头。使用TStringStream时尤其容易踩坑因为TStringStream在写入后Position在末尾直接调用EncryptStream会读到0字节。正确做法是先重置Position到0Src.Position : 0; Cipher.EncryptStream(Src, Dst);5. 踩坑实录版本冲突、密钥填充、字符串编码这套源码我用了三周踩过的坑比想象中多。挑几个典型记录一下希望对你有用。5.1 与其他库的同名类冲突DCPcrypt2的单元里有很多通用类名比如TDCP_rijndael但更头疼的是它定义了TDCP_hash、TDCP_cipher这种容易和第三方库冲突的基类名。我某个项目同时用了LockBox 3两边都有一个TDCP_rijndael但实现的接口细节不同。最后编译时随机报错一会是A单元用了B单元的类一会是找不到符号。解决办法是不要同时把两个库的目录都加入全局Search Path而是只在具体单元里uses。还可以给DCPcrypt2单元加上命名空间前缀。比如把解压目录改名成DCPcrypt2然后在工程选项的Unit Scope Names里加上DCPcrypt2使用时写uses DCPcrypt2.DCPrijndael;。这相当于Delphi的命名空间隔离能有效减少冲突。5.2 密钥填充的误区不是所有填充都叫PKCS7很多网上代码喜欢用全零填充也就是补零到块对齐。这在Demo里没问题但实际项目中如果密文被篡改或密钥错误解密出来的末尾可能不会全零导致程序不知道哪些字节是填充。PKCS7填充的好处是填充值本身就是填充长度解密后可以通过末字节判断应该去掉多少。DCPcrypt2没有内置填充功能所以我在封装层统一实现PKCS7。这里有一个容易错的地方如果明文长度刚好是块大小的整数倍PKCS7依然要填充一个完整块。否则解密时会把最后一个明文块误认为填充数据。很多人在这上面翻车导致加密后长度比原数据多出16字节就以为是程序bug。5.3 字符串编码决定跨语言互通成败DCPcrypt2内部处理的是字节和字符串编码无关。但如果你在Delphi里用AnsiString在Java或Python里用UTF-8同一段明文加密后结果必然不同。我踩过的坑是早期项目用Delphi 7开发的默认AnsiString后来升级到XE12后默认string是UTF-16。同样是AES加密两边结果对不上。后来我统一规则所有跨语言交换的文本一律先用UTF-8编码成TBytes再加密。哈希也一样计算前先明确编码。在调用TEncoding.UTF8.GetBytes和TEncoding.UTF8.GetString之间不能有隐性转换。这个原则适用于任何语言算是通用经验了。5.4 编译优化带来的假性错误这种情况最迷惑。我在Release模式下编译优化开满跑某些长度的明文加密后偶发结果错误。调试模式一切正常。排查了很久最后发现是某些常量大数组在const声明时没有对齐导致查表时读错地址。这是老代码在新编译器下偶发的问题。解决办法是找到对应的查表数组声明为alignment 16或者在单元里加{$ALIGN 8}。这个源码版据我测试没这问题但如果自己改成非常老的版本就要留个心眼。6. 源码级阅读给二次开发带来的额外价值最后一个想聊的是直接读源码和调第三方闭包库的心态完全不同。DCPcrypt2的代码结构清晰尤其是算法单元基本就是教科书的直译。DCPrijndael.pas里你甚至能看到Rijndael算法的S盒和列混合变换这比任何讲解都直观。我举一个例子DCPcrypt2.pas中的基类TDCP_cipher定义了一个虚拟方法EncryptCBC文档只说“加密CBC模式数据”。但读源码你会发现它对ECB和CBC做了分支处理而且为了提高效率CBC模式在校验IV非空时会进行链式异或。明白这一点后我可以手动修改派生类增加CMAC支持或GCM的计数器模式而不是被库的接口边界限制住。另外DCPcrypt2的许可证是MIT风格的允许自由使用和修改甚至商业闭源。这意味着你完全可以把某个算法单元改得适合你的特殊场景。比如我把它的SHA1单元提取出来加了一层增量哈希接口用于接收大文件分段哈希内存占用几乎为零。如果用的是闭源库这是不可能做到的。在我个人经验里如果一个项目的加密需求不算复杂但又想保留完全可控的代码路径DCPcrypt2源码包依然是个值得考虑的选择。XE12下这套fS版完美编译自带测试通过直接引用单元即可不需要安装任何运行时组件。唯一要留意的就是密钥长度、IV长度、填充方式和编码方式这四件事做对了基本不会出问题。最后再分享一个小技巧把7z解压后建议保留原始压缩包并记录解压时文件的哈希值。这样以后升级编译器或排查问题时能快速确定源码有没有被动过手脚也能对比自己改过的版本和标准版本之间的差异。毕竟加密代码最怕的不是慢而是被无意中改坏还看不出来。本文还有配套的精品资源点击获取
