简介这是一套面向 Delphi 开发者的加密算法控件包 DCPcrypt v2.0集中实现了 Blowfish、Twofish、Serpent、Mars、CAST128 等对称加密算法以及 SHA、RIPEMD 系列散列算法可帮助开发者在桌面应用中快速加入数据加密、校验和完整性验证功能适合文件加密、网络报文加密、口令散列存储等常见场景也适合中高级 Delphi 程序员作为算法实现的学习蓝本。压缩包共 178 个文件约 652KB以 Pascal 源文件.pas为核心同时包含预编译单元.ppu/.o、备份文件.bak、头文件.inc、资源文件.res/.dcr、Delphi 包工程.dpk以及 HTML 文档既能直接查看底层实现细节也方便重新编译安装到 IDE 中并随时对照备份文件排查改动问题。已有 222 人学习下载。通过这份资源可获得一整套经过整理的加密组件源码与工程配置免去自行收集散落代码的麻烦还能借助帮助文档和备份文件深入理解每个算法的结构、参数与典型用法适合作为 Delphi 加密开发的工具库或教学参考。 加密算法这块很多Delphi老开发者在项目里需要加解密功能时第一反应是翻OpenSSL封装或Windows CryptoAPI但真正落地时往往会发现环境配置复杂、跨版本兼容头疼。而我个人在多个实际项目中最终都选择了DCPcrypt2这套纯Pascal实现的加密算法控件用它完成了从简单字符串加密到文件分块加密再到哈希校验的一整套需求。这篇文章就针对DCPcrypt2控件结合我实际踩过的坑和调优经验讲清楚它到底能做什么、怎么接入、怎么写代码以及和RSA、DH这类非对称算法配合时的选型思路。不管是刚接触Delphi加密开发的新手还是需要在老项目里快速集成加密功能的熟手这篇内容都值得收藏参考。1. 为什么我在Delphi项目里最终选了DCPcrypt21.1 先说说市面上那几类加密方案的痛点早些年我在做Delphi项目时加密需求第一个想到的是调用Windows的CryptoAPI。这个方案的问题是接口太底层光是理解CSP上下文、密钥句柄、数据块转换就能折腾一整天而且代码量庞大调试起来很不直观。后来用过一段Indy自带的加密组件最大的问题在于它和网络IO绑定得太紧很多时候我只想对一个字符串做哈希或加解密却要被迫理解整个IO流框架。商业控件如SecureBlackbox功能确实强大但授权费用不低对中小型项目来说性价比不够而且一升级就面临重新授权的问题。还有一些国产的加密模块文档缺失严重、接口风格各异真要集成到Delphi的老项目里常常是C/C#还行到Pascal环境下各种水土不服。1.2 DCPcrypt2的核心优势纯Pascal、开箱即用、跨编译器版本DCPcrypt2是David Barton早年开发的DCPcrypt控件的改进版一直在开源社区活跃维护。它最大的特点是整套实现都是Delphi Pascal代码不依赖外部DLL也不需要额外安装运行库。这意味着什么我把DCP_*.pas这些单元扔进项目里就能直接用发布EXE时不必附带一堆动态链接库也不存在目标机器上缺C运行时导致加密功能起不来的情况。这一点在给客户做本地化部署时极其重要尤其是那些已经多年没更新系统补丁的老Windows服务器纯静态编译的Delphi程序反而最稳。另外DCPcrypt2对Delphi各版本的兼容性做得相当好。我分别在Delphi 7、XE8、10.3上用过基本就是调整一下Search Path的事代码层面不需要大的改动。对还在维护老项目的团队来说不用为了用加密功能去升级整个IDE。1.3 它能解决什么问题DCPcrypt2覆盖了两大类核心需求对称加密支持Blowfish、Twofish、RijndaelAES、Cast-128/256、DES/3DES等主流分组算法以及RC4这种流加密算法。哈希摘要支持MD4、MD5、RIPEMD-128/160/256/320、SHA-1、SHA-256/SHA-384/SHA-512等常用哈希算法。实际项目中我用它干过这些事登录密码的加盐哈希存储、网络通信中的报文摘要校验、配置文件的整体加密保存、上传下载文件的AES加密、导出数据包的完整性校验。只要不涉及非对称加密这个控件基本都能覆盖。注意DCPcrypt2定位是对称加密和哈希它本身不含RSA、DH这类非对称算法组件。但在第5节我会讲它和第三方非对称库的配合思路这在真实场景里非常常见。2. DCPcrypt2的算法家族先搞清楚你能用什么2.1 对称加密算法的分类和选型DCPcrypt2支持的对称加密算法按结构可分为分组加密和流加密两类。分组加密算法会把明文切成固定大小的数据块来加密常见块大小是64位或128位。控件里比较常用的几个算法块大小密钥长度范围特点Blowfish64位32~448位老牌算法速度快密钥长度灵活Twofish128位128/192/256位Blowfish的后续设计安全性更高RijndaelAES128位128/192/256位现代标准算法推荐优先使用CAST-12864位40~128位PGP中常用兼容性不错DES/3DES64位56/112/168位老旧算法除非兼容遗留系统否则不推荐流加密算法方面DCPcrypt2提供了RC4。RC4实现极其简单、速度飞快但安全性在现代标准下已显不足目前我一般只用于非敏感数据的混淆真正需要保护的数据不走RC4。选型时我的建议很直接新项目一律用RijndaelAES这是目前行业公认的安全标准没有理由再用别的。Blowfish适合需要兼容国外老旧接口的系统Twofish适合喜欢它的设计但在实际互操作场景中比较少见的项目。2.2 哈希算法怎么选哈希算法在项目里主要用于密码存储和文件完整性校验。DCPcrypt2提供的选择很多MD4/MD5速度极快但碰撞攻击早已可行只适合做非安全场景的校验码。SHA-1曾经的主力现在也已被证实存在理论攻击风险不建议新项目使用。SHA-2家族SHA-256/384/512目前的主流选择安全性和性能均衡密码存储和文件校验我都推荐SHA-256。RIPEMD系列比较小众在特定互操作场景里有需求时才会用到。密码存储的实际做法绝不仅是把密码丢进哈希函数就行而是要做加盐哈希。我会为每个用户生成一段随机盐值Salt将盐值和密码拼在一起计算哈希最后把盐和哈希一起存库。这样可以有效对抗彩虹表攻击就算是数据库泄露攻击者也很难通过预计算表反查出原始密码。2.3 分组模式和填充机制对称分组算法光有基本加解密函数不够实际使用还要考虑分组模式和填充方式。DCPcrypt2通过TDCP_cipher的继承类实现了ECB、CBC、CFB、OFB、CTR等常见模式。重点说说我在项目中反复使用的CBC模式CBC模式要求每个明文块先和前一个密文块做异或然后用密钥加密。第一个块没有前一个密文块可用所以需要初始化向量IV。CBC的优点在于相同明文块在密文中呈现不同形态比ECB安全得多缺点是不能并行加密。真正容易忽略的是IV的随机性。IV不需要保密但对一次加密会话来说必须是随机的而且每个加密过程要生成不同的IV。如果IV固定不变CBC模式实际上会退化成类似ECB的性质相同明文前缀会产生相同密文前缀攻击者就能从密文中推断出明文数据结构。DCPcrypt2使用CBC时调SetIV方法来设置初始化向量。我在实战中的写法是// 生成16字节随机IV一般用随机数发生器填充 SetLength(IV, 16); for i : 0 to 15 do IV[i] : Random(256);填充机制方面因为分组加密要求明文长度必须是块大小的整数倍不足的地方就需要填充。DCPcrypt2默认处理了填充逻辑但要注意不同系统间互操作时双方使用的填充标准必须一致。最常见的是PKCS#7填充比如AES的16字节分组差3字节就补3个0x03差1字节就补1个0x01。3. 环境接入从源码到跑通第一个加解密Demo3.1 拿到源码并加入编译路径DCPcrypt2以源码形式发布你需要从开源社区渠道获取完整源码包。解压后核心文件是DCPcrypt.pas抽象基类、DCPblockciphers.pas分组密码框架、DCPhash.pas哈希框架以及各个算法对应单元比如DCPrijndael.pas、DCPsha256.pas、DCPblowfish.pas等。接入方式有两条路方案A直接放进你的项目目录。把需要用到的DCP_*.pas文件复制到工程目录下Delphi编译时会自动找到它。方案B配置全局Search Path。在Tools - Options - Delphi Options - Library - Library Path里加入DCPcrypt2源码目录。这样所有项目都能共享一套源码后续升级控件版本也方便。我比较推荐方案B尤其是当手上有多个项目同时使用DCPcrypt2时单独维护每份拷贝会很痛苦。3.2 初识控件和非可视组件写法DCPcrypt2虽然是控件但它不是那种可以拖到窗体上的可视控件。它有两种使用形态组件形态通过uses引入算法单元后在运行时动态创建TDCP_rijndael等对象设置好密钥和模式后直接调用加密方法。流式形态通过TDCP_rijndael配合流对象TStream对文件或内存块进行加解密。实际项目中我几乎都是用运行时创建对象的方式不用在设计期拖组件这样代码更清晰也方便封装成统一的加密服务类。3.3 跑通第一个AES加解密Demo下面是一个最经典的AES-128加密字符串的完整示例你可以直接复制到Delphi的Form或控制台工程里测试uses SysUtils, Classes, DCPcrypt2, DCPrijndael; procedure TForm1.ButtonEncryptClick(Sender: TObject); var Cipher: TDCP_rijndael; Key: array[0..15] of byte; IV: array[0..15] of byte; PlainBytes, CipherBytes: TBytes; i: Integer; begin // 初始化密钥和IV for i : 0 to 15 do begin Key[i] : i; // 实际项目中请使用安全的随机密钥生成方式 IV[i] : 15 - i; end; Cipher : TDCP_rijndael.Create(nil); try // 设置密钥和CBC模式 Cipher.Init(Key, 128, nil); Cipher.SetIV(IV); // 准备需要加密的数据 PlainBytes : TEncoding.UTF8.GetBytes(Edit1.Text); // 加密 SetLength(CipherBytes, Length(PlainBytes)); Cipher.EncryptCBC(PlainBytes[0], CipherBytes[0], Length(PlainBytes)); // 输出密文这里可以转成Base64便于显示和传输 Memo1.Lines.Add(TEncoding.UTF8.GetString(CipherBytes)); finally Cipher.Free; end; end;解密过程对称只要把EncryptCBC改成DecryptCBC即可。但这里有一个关键的坑EncryptCBC要求数据长度必须是16字节的整数倍。上面的示例在数据长度不满足时会出错或越界。实际处理方式是自行实现填充逻辑function GetPaddedData(const Data: TBytes; BlockSize: Integer): TBytes; var PadLen, i: Integer; begin PadLen : BlockSize - (Length(Data) mod BlockSize); SetLength(Result, Length(Data) PadLen); Move(Data[0], Result[0], Length(Data)); for i : Length(Data) to Length(Result) - 1 do Result[i] : PadLen; end;对应解密后需要根据最后一个字节的值去掉填充字节。这块逻辑建议封装成独立的加密辅助单元不要在每个调用处重复写。3.4 官方Demo之外的注意事项我跑通第一个Demo后踩了一个跟字符串类型有关的坑。在Delphi 2009之前的版本里string默认是AnsiString字节语义比较直观但在Delphi 2009之后string变成了UnicodeString直接对字符串做字节操作很容易出现编码混乱。解决办法是统一使用TEncoding.UTF8.GetBytes和TEncoding.UTF8.GetString来处理编码转换不要直接Move字符串内存到字节数组。跨语言互操作时也建议统一走UTF-8避免ANSI代码页导致中文乱码。4. 高频实战场景的完整代码与设计思路4.1 场景一用户密码加盐哈希存储密码不能明文存储这是基本的安全常识。我用DCPcrypt2实现密码哈希的步骤uses DCPsha256, DCPmd5; function HashPassword(const Password, Salt: string): string; var Hash: TDCP_sha256; Digest: array[0..31] of byte; i: Integer; begin Hash : TDCP_sha256.Create(nil); try Hash.Init; Hash.UpdateStr(Password Salt); // 密码与盐拼接 Hash.Final(Digest); Result : ; for i : 0 to 31 do Result : Result IntToHex(Digest[i], 2); finally Hash.Free; end; end;盐值的生成我一般用系统随机数加强度高一些的方式至少16字节。每个用户独立盐值不要全局固定。虽然SHA-256加盐已经能挡住绝大多数攻击但如果项目对安全要求更高建议引入bcrypt或PBKDF2这类慢哈希算法。DCPcrypt2本身不带慢哈希需要时我会配合其他库实现或者用多次迭代SHA-256的方式变相增加计算代价。4.2 场景二配置文件整体加解密很多桌面软件需要保存本地配置文件里面可能含有数据库连接串、接口密钥等敏感信息。直接明文存储风险极大用DCPcrypt2整体加密即可。这里需要考虑的是文件加解密不能一次性把整个文件加载进内存尤其文件体积比较大时。正确做法是分块读取function DecryptFile(const InputFile, OutputFile: string; const Key: TBytes): Boolean; var Src, Dst: TFileStream; Cipher: TDCP_rijndael; IV: array[0..15] of byte; Buffer: array[0..4095] of byte; BytesRead: Integer; begin Result : False; Src : nil; Dst : nil; Cipher : nil; try Src : TFileStream.Create(InputFile, fmOpenRead); Dst : TFileStream.Create(OutputFile, fmCreate); Cipher : TDCP_rijndael.Create(nil); Cipher.Init(Key[0], 128, nil); // 文件中先读取IV这和加密时保持对应 Src.ReadBuffer(IV[0], 16); Cipher.SetIV(IV); repeat BytesRead : Src.Read(Buffer, SizeOf(Buffer)); if BytesRead 0 then begin // 分块处理时需要保证每块长度对齐这里简化写法示意 Cipher.DecryptCBC(Buffer[0], Buffer[0], BytesRead); Dst.WriteBuffer(Buffer, BytesRead); end; until BytesRead SizeOf(Buffer); Result : True; finally Src.Free; Dst.Free; Cipher.Free; end; end;但细心的读者会发现一个问题CBC模式要求每块解密数据必须是16字节的倍数文件大小不确定时最后一块可能不满足。这个问题我在4.4节里专门说明这里先不展开。4.3 场景三网络通信报文的哈希校验在网络传输场景中DCPcrypt2经常用来做报文的完整性校验。做法是对报文的主体内容计算HMAC或简单哈希然后将哈希值附在报文尾部或头部接收方重新计算比对。如果担心报文被篡改单纯MD5或SHA-256不够因为攻击者可以同时修改报文和哈希值。更稳妥的方案是使用密钥参与计算的HMACDCPcrypt2本身没有直接提供HMAC封装但可以通过哈希更新加盐的方式近似实现或者自己封装一个简单的HMAC逻辑把密钥和报文按特定顺序做两次哈希计算。我的经验是在加密通道已经建立的场景里用简单SHA-256校验码已经能解决大部分问题在数据需要对抗主动篡改的场景里一定要用真HMAC方案。4.4 文件加密最后一组数据的边界解决这个问题容易被忽视我单独拿出来说。使用CBC或ECB模式做文件分块加密时文件大小往往不是16字节的整数倍最后一块数据不足16字节时直接调用EncryptCBC会报错。实践中有两种通用解法解法一自定义PKCS#7填充后再加密。读取文件时把最后一块留到内存不足16字节就补足解密后根据最后一个字节的值去掉填充。这种方案需要在文件末尾额外记录原始长度或填充长度。解法二使用CFB或OFB这类流式模式。CFB/OFB模式可以把分组算法当作流密码使用无需填充即可处理任意长度的数据。DCPcrypt2同样支持这两种模式只是数据块内部是按16字节生成的密钥流加解密长度和明文长度完全一致。我在文件加密场景里的经验是能选CFB模式就不要在CBC模式里手动补填充。虽然填充逻辑不算复杂但在多端互操作时只要有一端实现不对就会全军覆没。CFB模式免填充的特性让加解密逻辑更简单代码量也更少。5. RSA、DH等非对称算法的配合使用建议5.1 正视DCPcrypt2的边界非对称算法需要另找方案DCPcrypt2本身没有内置RSA、DH这类非对称算法组件。这一点必须先说明清楚很多新手以为装了DCPcrypt2就能直接调用RSA加密用了半天找不到类才意识到问题。但现实中部署系统往往既要对称加密的高速性能又要非对称加密的密钥管理便利。标准做法是混合加密方案用RSA加密一份随机生成的AES会话密钥用这个AES密钥对实际业务数据进行加解密这种方案的好处很实际AES加解密速度远快于RSA适合大量数据RSA只加密一份短小的会话密钥既安全又可控。DCPcrypt2负责AES这部分RSA部分可以结合其他开源库或平台的加密API实现。5.2 DH算法在密钥协商中的定位DHDiffie-Hellman算法用于双方在不安全的通道上协商出一个共同密钥不直接加密数据而是解决密钥怎么安全地发给对方这个前提问题。在我做过的客户端-服务器项目中密钥分发方案通常是客户端和服务端先通过DH或者RSA密钥交换协议生成一个共享密钥种子。双方基于共享种子派生出一份AES密钥。后续通信数据全部用AES密钥加解密DH或RSA只负责在最开始时协商密钥。DCPcrypt2在这些方案里的角色就是第二步之后的对称加解密实现。DH/RSA协议本身我倾向于用成熟库封装不自己从零实现。现在网上搜索RSA加密算法相关热词时经常会出现Delphi项目中如何使用RSA的问题如果你手头的非对称库只支持裸RSA加解密而没有完善的填充处理建议在数据进RSA之前先用随机密钥生成器去掉可预测前缀或采用OAEP填充思想的变体否则RSA的确定性特征会泄露部分明文信息。5.3 混合加解密的设计参考下面是一个我实际项目中使用过的混合加密流程供参考客户端生成随机16字节AES密钥和16字节IV。用DCPcrypt2的AES算法加密业务数据得到密文。用服务器公钥RSA加密AES密钥和IV得到密钥密文。发送给服务器的数据结构包含密钥密文 密文数据。服务器用RSA私钥解出AES密钥和IV。服务器用DCPcrypt2的AES算法解出明文。这种结构的好处是每次通信的AES密钥都不同即使攻击者截获了某一次通信数据也无法推导出其他通信的密钥。6. 踩坑经验与性能调优记录6.1 密钥生成方式的坑早期我在项目里图省事直接用字符串的字符码作为密钥字节比如KeyBytes[i] : Ord(KeyStr[i])。这种做法存在严重问题密钥空间被压缩到了可打印字符范围大大降低暴力破解的难度。正确做法是使用随机数发生器生成二进制密钥或者用PBKDF2算法从密码短语派生密钥。DCPcrypt2配套的单元里包含了TDCP_sha512这类强哈希可以用它做密钥的初步混淆但更专业的做法还是走加密库里的KDF接口。在实际项目中我一般结合两部分生成密钥一部分来源于本地硬件指纹或固定配置文件另一部分来源于随机种子两者做散列混合后得到的字节串作为AES密钥。这样可以保证密钥既稳定不因重启改变又不可预测。6.2 性能对比该用哪类算法的时机把握我在日常开发中做过简单的性能实测算法加密1MB数据耗时相对适用场景RC4极快非安全混淆格式保护Blowfish快老系统兼容AES-128较快通用安全加密推荐Twofish中等安全性要求更高的场景SHA-256快文件校验、密码哈希这里的核心结论是在绝大多数桌面应用场景中AES-128/256的加解密速度完全够用1MB数据块加密耗时通常是毫秒级无需刻意追求RC4的速度。如果加密大量小文件创建和释放TDCP_rijndael对象的开销反而比加解密本身更大。这时我习惯采用复用Cipher对象的方式程序启动时创建一次加解密时重置状态即可。但必须注意公用的Cipher对象要做好线程同步Delphi的DCPcrypt2组件本身不是线程安全的多线程环境需要为每个线程创建独立实例。6.3 版本间的兼容性陷阱DCPcrypt2在不同分支版本里的接口有细微差别。比如某些版本要求Init方法里传密钥指针某些版本直接接受字节数组EncryptCBC等方法在参数数量和类型上也有差异。我的建议是锁定一个稳定版本不要频繁升级。在项目里废弃旧版改用新版时一定先跑一遍现有的加解密测试用例确保新旧版本加密结果一致。加密数据的兼容性问题一旦出现往往是灾难性的因为已经落盘的密文无法再用旧代码解开。同时要注意用默认参数时不同算法对密钥长度的处理方式不同超过密钥长度上限的密钥会被截断或直接报错。编码时应对所有输入密钥做长度校验提前暴露问题而不是等运行时崩溃。6.4 多线程环境下的并发加密现代应用很少有单线程场景DCPcrypt2不保证线程安全这点务必注意。我在服务端项目里使用过线程池并发加密多个文件一开始直接用了全局Cipher实例结果出现随机性解密失败排查了很久才定位到是Cipher内部状态被多个线程同时写坏。解决方案有两种方案一线程局部变量。每个线程创建自己的Cipher实例用完释放互不干扰。方案二加锁串行化。对加解密操作统一加互斥锁实现简单但牺牲并发性能。方案一适合加密操作频繁的场景方案二适合调用量不大但需要保证共享唯一的场景。我个人推荐方案一因为DCPcrypt2对象的创建成本很低没必要为了省一点创建开销引入复杂的并发控制。6.5 密钥管理和算法迁移准备最后想提醒的是加密项目不能说有了加密就一劳永逸。行业内的大量实践表明算法本身可能会随着时间暴露出弱点项目里的加解密模块一定要提前做好版本标记和可扩展性设计。我在系统中的做法是在加密数据的文件头或报文头部加上版本号字段表明这块密文用的是哪套算法、哪个密钥索引。这样将来升级AES密钥长度或更换哈希算法时旧数据仍然可以按照版本号找到对应的解密逻辑完成迁移。同时密钥管理上建议把密钥和加密逻辑分离密钥存放在独立的配置模块中定期轮换。DCPcrypt2只是帮我们做算法运算密钥的生命周期管理始终是整个加密设计里最需要人力投入的部分。本文还有配套的精品资源点击获取 Delphi加密实战：DCPcrypt2纯Pascal控件详解与踩坑指南
简介这是一套面向 Delphi 开发者的加密算法控件包 DCPcrypt v2.0集中实现了 Blowfish、Twofish、Serpent、Mars、CAST128 等对称加密算法以及 SHA、RIPEMD 系列散列算法可帮助开发者在桌面应用中快速加入数据加密、校验和完整性验证功能适合文件加密、网络报文加密、口令散列存储等常见场景也适合中高级 Delphi 程序员作为算法实现的学习蓝本。压缩包共 178 个文件约 652KB以 Pascal 源文件.pas为核心同时包含预编译单元.ppu/.o、备份文件.bak、头文件.inc、资源文件.res/.dcr、Delphi 包工程.dpk以及 HTML 文档既能直接查看底层实现细节也方便重新编译安装到 IDE 中并随时对照备份文件排查改动问题。已有 222 人学习下载。通过这份资源可获得一整套经过整理的加密组件源码与工程配置免去自行收集散落代码的麻烦还能借助帮助文档和备份文件深入理解每个算法的结构、参数与典型用法适合作为 Delphi 加密开发的工具库或教学参考。 加密算法这块很多Delphi老开发者在项目里需要加解密功能时第一反应是翻OpenSSL封装或Windows CryptoAPI但真正落地时往往会发现环境配置复杂、跨版本兼容头疼。而我个人在多个实际项目中最终都选择了DCPcrypt2这套纯Pascal实现的加密算法控件用它完成了从简单字符串加密到文件分块加密再到哈希校验的一整套需求。这篇文章就针对DCPcrypt2控件结合我实际踩过的坑和调优经验讲清楚它到底能做什么、怎么接入、怎么写代码以及和RSA、DH这类非对称算法配合时的选型思路。不管是刚接触Delphi加密开发的新手还是需要在老项目里快速集成加密功能的熟手这篇内容都值得收藏参考。1. 为什么我在Delphi项目里最终选了DCPcrypt21.1 先说说市面上那几类加密方案的痛点早些年我在做Delphi项目时加密需求第一个想到的是调用Windows的CryptoAPI。这个方案的问题是接口太底层光是理解CSP上下文、密钥句柄、数据块转换就能折腾一整天而且代码量庞大调试起来很不直观。后来用过一段Indy自带的加密组件最大的问题在于它和网络IO绑定得太紧很多时候我只想对一个字符串做哈希或加解密却要被迫理解整个IO流框架。商业控件如SecureBlackbox功能确实强大但授权费用不低对中小型项目来说性价比不够而且一升级就面临重新授权的问题。还有一些国产的加密模块文档缺失严重、接口风格各异真要集成到Delphi的老项目里常常是C/C#还行到Pascal环境下各种水土不服。1.2 DCPcrypt2的核心优势纯Pascal、开箱即用、跨编译器版本DCPcrypt2是David Barton早年开发的DCPcrypt控件的改进版一直在开源社区活跃维护。它最大的特点是整套实现都是Delphi Pascal代码不依赖外部DLL也不需要额外安装运行库。这意味着什么我把DCP_*.pas这些单元扔进项目里就能直接用发布EXE时不必附带一堆动态链接库也不存在目标机器上缺C运行时导致加密功能起不来的情况。这一点在给客户做本地化部署时极其重要尤其是那些已经多年没更新系统补丁的老Windows服务器纯静态编译的Delphi程序反而最稳。另外DCPcrypt2对Delphi各版本的兼容性做得相当好。我分别在Delphi 7、XE8、10.3上用过基本就是调整一下Search Path的事代码层面不需要大的改动。对还在维护老项目的团队来说不用为了用加密功能去升级整个IDE。1.3 它能解决什么问题DCPcrypt2覆盖了两大类核心需求对称加密支持Blowfish、Twofish、RijndaelAES、Cast-128/256、DES/3DES等主流分组算法以及RC4这种流加密算法。哈希摘要支持MD4、MD5、RIPEMD-128/160/256/320、SHA-1、SHA-256/SHA-384/SHA-512等常用哈希算法。实际项目中我用它干过这些事登录密码的加盐哈希存储、网络通信中的报文摘要校验、配置文件的整体加密保存、上传下载文件的AES加密、导出数据包的完整性校验。只要不涉及非对称加密这个控件基本都能覆盖。注意DCPcrypt2定位是对称加密和哈希它本身不含RSA、DH这类非对称算法组件。但在第5节我会讲它和第三方非对称库的配合思路这在真实场景里非常常见。2. DCPcrypt2的算法家族先搞清楚你能用什么2.1 对称加密算法的分类和选型DCPcrypt2支持的对称加密算法按结构可分为分组加密和流加密两类。分组加密算法会把明文切成固定大小的数据块来加密常见块大小是64位或128位。控件里比较常用的几个算法块大小密钥长度范围特点Blowfish64位32~448位老牌算法速度快密钥长度灵活Twofish128位128/192/256位Blowfish的后续设计安全性更高RijndaelAES128位128/192/256位现代标准算法推荐优先使用CAST-12864位40~128位PGP中常用兼容性不错DES/3DES64位56/112/168位老旧算法除非兼容遗留系统否则不推荐流加密算法方面DCPcrypt2提供了RC4。RC4实现极其简单、速度飞快但安全性在现代标准下已显不足目前我一般只用于非敏感数据的混淆真正需要保护的数据不走RC4。选型时我的建议很直接新项目一律用RijndaelAES这是目前行业公认的安全标准没有理由再用别的。Blowfish适合需要兼容国外老旧接口的系统Twofish适合喜欢它的设计但在实际互操作场景中比较少见的项目。2.2 哈希算法怎么选哈希算法在项目里主要用于密码存储和文件完整性校验。DCPcrypt2提供的选择很多MD4/MD5速度极快但碰撞攻击早已可行只适合做非安全场景的校验码。SHA-1曾经的主力现在也已被证实存在理论攻击风险不建议新项目使用。SHA-2家族SHA-256/384/512目前的主流选择安全性和性能均衡密码存储和文件校验我都推荐SHA-256。RIPEMD系列比较小众在特定互操作场景里有需求时才会用到。密码存储的实际做法绝不仅是把密码丢进哈希函数就行而是要做加盐哈希。我会为每个用户生成一段随机盐值Salt将盐值和密码拼在一起计算哈希最后把盐和哈希一起存库。这样可以有效对抗彩虹表攻击就算是数据库泄露攻击者也很难通过预计算表反查出原始密码。2.3 分组模式和填充机制对称分组算法光有基本加解密函数不够实际使用还要考虑分组模式和填充方式。DCPcrypt2通过TDCP_cipher的继承类实现了ECB、CBC、CFB、OFB、CTR等常见模式。重点说说我在项目中反复使用的CBC模式CBC模式要求每个明文块先和前一个密文块做异或然后用密钥加密。第一个块没有前一个密文块可用所以需要初始化向量IV。CBC的优点在于相同明文块在密文中呈现不同形态比ECB安全得多缺点是不能并行加密。真正容易忽略的是IV的随机性。IV不需要保密但对一次加密会话来说必须是随机的而且每个加密过程要生成不同的IV。如果IV固定不变CBC模式实际上会退化成类似ECB的性质相同明文前缀会产生相同密文前缀攻击者就能从密文中推断出明文数据结构。DCPcrypt2使用CBC时调SetIV方法来设置初始化向量。我在实战中的写法是// 生成16字节随机IV一般用随机数发生器填充 SetLength(IV, 16); for i : 0 to 15 do IV[i] : Random(256);填充机制方面因为分组加密要求明文长度必须是块大小的整数倍不足的地方就需要填充。DCPcrypt2默认处理了填充逻辑但要注意不同系统间互操作时双方使用的填充标准必须一致。最常见的是PKCS#7填充比如AES的16字节分组差3字节就补3个0x03差1字节就补1个0x01。3. 环境接入从源码到跑通第一个加解密Demo3.1 拿到源码并加入编译路径DCPcrypt2以源码形式发布你需要从开源社区渠道获取完整源码包。解压后核心文件是DCPcrypt.pas抽象基类、DCPblockciphers.pas分组密码框架、DCPhash.pas哈希框架以及各个算法对应单元比如DCPrijndael.pas、DCPsha256.pas、DCPblowfish.pas等。接入方式有两条路方案A直接放进你的项目目录。把需要用到的DCP_*.pas文件复制到工程目录下Delphi编译时会自动找到它。方案B配置全局Search Path。在Tools - Options - Delphi Options - Library - Library Path里加入DCPcrypt2源码目录。这样所有项目都能共享一套源码后续升级控件版本也方便。我比较推荐方案B尤其是当手上有多个项目同时使用DCPcrypt2时单独维护每份拷贝会很痛苦。3.2 初识控件和非可视组件写法DCPcrypt2虽然是控件但它不是那种可以拖到窗体上的可视控件。它有两种使用形态组件形态通过uses引入算法单元后在运行时动态创建TDCP_rijndael等对象设置好密钥和模式后直接调用加密方法。流式形态通过TDCP_rijndael配合流对象TStream对文件或内存块进行加解密。实际项目中我几乎都是用运行时创建对象的方式不用在设计期拖组件这样代码更清晰也方便封装成统一的加密服务类。3.3 跑通第一个AES加解密Demo下面是一个最经典的AES-128加密字符串的完整示例你可以直接复制到Delphi的Form或控制台工程里测试uses SysUtils, Classes, DCPcrypt2, DCPrijndael; procedure TForm1.ButtonEncryptClick(Sender: TObject); var Cipher: TDCP_rijndael; Key: array[0..15] of byte; IV: array[0..15] of byte; PlainBytes, CipherBytes: TBytes; i: Integer; begin // 初始化密钥和IV for i : 0 to 15 do begin Key[i] : i; // 实际项目中请使用安全的随机密钥生成方式 IV[i] : 15 - i; end; Cipher : TDCP_rijndael.Create(nil); try // 设置密钥和CBC模式 Cipher.Init(Key, 128, nil); Cipher.SetIV(IV); // 准备需要加密的数据 PlainBytes : TEncoding.UTF8.GetBytes(Edit1.Text); // 加密 SetLength(CipherBytes, Length(PlainBytes)); Cipher.EncryptCBC(PlainBytes[0], CipherBytes[0], Length(PlainBytes)); // 输出密文这里可以转成Base64便于显示和传输 Memo1.Lines.Add(TEncoding.UTF8.GetString(CipherBytes)); finally Cipher.Free; end; end;解密过程对称只要把EncryptCBC改成DecryptCBC即可。但这里有一个关键的坑EncryptCBC要求数据长度必须是16字节的整数倍。上面的示例在数据长度不满足时会出错或越界。实际处理方式是自行实现填充逻辑function GetPaddedData(const Data: TBytes; BlockSize: Integer): TBytes; var PadLen, i: Integer; begin PadLen : BlockSize - (Length(Data) mod BlockSize); SetLength(Result, Length(Data) PadLen); Move(Data[0], Result[0], Length(Data)); for i : Length(Data) to Length(Result) - 1 do Result[i] : PadLen; end;对应解密后需要根据最后一个字节的值去掉填充字节。这块逻辑建议封装成独立的加密辅助单元不要在每个调用处重复写。3.4 官方Demo之外的注意事项我跑通第一个Demo后踩了一个跟字符串类型有关的坑。在Delphi 2009之前的版本里string默认是AnsiString字节语义比较直观但在Delphi 2009之后string变成了UnicodeString直接对字符串做字节操作很容易出现编码混乱。解决办法是统一使用TEncoding.UTF8.GetBytes和TEncoding.UTF8.GetString来处理编码转换不要直接Move字符串内存到字节数组。跨语言互操作时也建议统一走UTF-8避免ANSI代码页导致中文乱码。4. 高频实战场景的完整代码与设计思路4.1 场景一用户密码加盐哈希存储密码不能明文存储这是基本的安全常识。我用DCPcrypt2实现密码哈希的步骤uses DCPsha256, DCPmd5; function HashPassword(const Password, Salt: string): string; var Hash: TDCP_sha256; Digest: array[0..31] of byte; i: Integer; begin Hash : TDCP_sha256.Create(nil); try Hash.Init; Hash.UpdateStr(Password Salt); // 密码与盐拼接 Hash.Final(Digest); Result : ; for i : 0 to 31 do Result : Result IntToHex(Digest[i], 2); finally Hash.Free; end; end;盐值的生成我一般用系统随机数加强度高一些的方式至少16字节。每个用户独立盐值不要全局固定。虽然SHA-256加盐已经能挡住绝大多数攻击但如果项目对安全要求更高建议引入bcrypt或PBKDF2这类慢哈希算法。DCPcrypt2本身不带慢哈希需要时我会配合其他库实现或者用多次迭代SHA-256的方式变相增加计算代价。4.2 场景二配置文件整体加解密很多桌面软件需要保存本地配置文件里面可能含有数据库连接串、接口密钥等敏感信息。直接明文存储风险极大用DCPcrypt2整体加密即可。这里需要考虑的是文件加解密不能一次性把整个文件加载进内存尤其文件体积比较大时。正确做法是分块读取function DecryptFile(const InputFile, OutputFile: string; const Key: TBytes): Boolean; var Src, Dst: TFileStream; Cipher: TDCP_rijndael; IV: array[0..15] of byte; Buffer: array[0..4095] of byte; BytesRead: Integer; begin Result : False; Src : nil; Dst : nil; Cipher : nil; try Src : TFileStream.Create(InputFile, fmOpenRead); Dst : TFileStream.Create(OutputFile, fmCreate); Cipher : TDCP_rijndael.Create(nil); Cipher.Init(Key[0], 128, nil); // 文件中先读取IV这和加密时保持对应 Src.ReadBuffer(IV[0], 16); Cipher.SetIV(IV); repeat BytesRead : Src.Read(Buffer, SizeOf(Buffer)); if BytesRead 0 then begin // 分块处理时需要保证每块长度对齐这里简化写法示意 Cipher.DecryptCBC(Buffer[0], Buffer[0], BytesRead); Dst.WriteBuffer(Buffer, BytesRead); end; until BytesRead SizeOf(Buffer); Result : True; finally Src.Free; Dst.Free; Cipher.Free; end; end;但细心的读者会发现一个问题CBC模式要求每块解密数据必须是16字节的倍数文件大小不确定时最后一块可能不满足。这个问题我在4.4节里专门说明这里先不展开。4.3 场景三网络通信报文的哈希校验在网络传输场景中DCPcrypt2经常用来做报文的完整性校验。做法是对报文的主体内容计算HMAC或简单哈希然后将哈希值附在报文尾部或头部接收方重新计算比对。如果担心报文被篡改单纯MD5或SHA-256不够因为攻击者可以同时修改报文和哈希值。更稳妥的方案是使用密钥参与计算的HMACDCPcrypt2本身没有直接提供HMAC封装但可以通过哈希更新加盐的方式近似实现或者自己封装一个简单的HMAC逻辑把密钥和报文按特定顺序做两次哈希计算。我的经验是在加密通道已经建立的场景里用简单SHA-256校验码已经能解决大部分问题在数据需要对抗主动篡改的场景里一定要用真HMAC方案。4.4 文件加密最后一组数据的边界解决这个问题容易被忽视我单独拿出来说。使用CBC或ECB模式做文件分块加密时文件大小往往不是16字节的整数倍最后一块数据不足16字节时直接调用EncryptCBC会报错。实践中有两种通用解法解法一自定义PKCS#7填充后再加密。读取文件时把最后一块留到内存不足16字节就补足解密后根据最后一个字节的值去掉填充。这种方案需要在文件末尾额外记录原始长度或填充长度。解法二使用CFB或OFB这类流式模式。CFB/OFB模式可以把分组算法当作流密码使用无需填充即可处理任意长度的数据。DCPcrypt2同样支持这两种模式只是数据块内部是按16字节生成的密钥流加解密长度和明文长度完全一致。我在文件加密场景里的经验是能选CFB模式就不要在CBC模式里手动补填充。虽然填充逻辑不算复杂但在多端互操作时只要有一端实现不对就会全军覆没。CFB模式免填充的特性让加解密逻辑更简单代码量也更少。5. RSA、DH等非对称算法的配合使用建议5.1 正视DCPcrypt2的边界非对称算法需要另找方案DCPcrypt2本身没有内置RSA、DH这类非对称算法组件。这一点必须先说明清楚很多新手以为装了DCPcrypt2就能直接调用RSA加密用了半天找不到类才意识到问题。但现实中部署系统往往既要对称加密的高速性能又要非对称加密的密钥管理便利。标准做法是混合加密方案用RSA加密一份随机生成的AES会话密钥用这个AES密钥对实际业务数据进行加解密这种方案的好处很实际AES加解密速度远快于RSA适合大量数据RSA只加密一份短小的会话密钥既安全又可控。DCPcrypt2负责AES这部分RSA部分可以结合其他开源库或平台的加密API实现。5.2 DH算法在密钥协商中的定位DHDiffie-Hellman算法用于双方在不安全的通道上协商出一个共同密钥不直接加密数据而是解决密钥怎么安全地发给对方这个前提问题。在我做过的客户端-服务器项目中密钥分发方案通常是客户端和服务端先通过DH或者RSA密钥交换协议生成一个共享密钥种子。双方基于共享种子派生出一份AES密钥。后续通信数据全部用AES密钥加解密DH或RSA只负责在最开始时协商密钥。DCPcrypt2在这些方案里的角色就是第二步之后的对称加解密实现。DH/RSA协议本身我倾向于用成熟库封装不自己从零实现。现在网上搜索RSA加密算法相关热词时经常会出现Delphi项目中如何使用RSA的问题如果你手头的非对称库只支持裸RSA加解密而没有完善的填充处理建议在数据进RSA之前先用随机密钥生成器去掉可预测前缀或采用OAEP填充思想的变体否则RSA的确定性特征会泄露部分明文信息。5.3 混合加解密的设计参考下面是一个我实际项目中使用过的混合加密流程供参考客户端生成随机16字节AES密钥和16字节IV。用DCPcrypt2的AES算法加密业务数据得到密文。用服务器公钥RSA加密AES密钥和IV得到密钥密文。发送给服务器的数据结构包含密钥密文 密文数据。服务器用RSA私钥解出AES密钥和IV。服务器用DCPcrypt2的AES算法解出明文。这种结构的好处是每次通信的AES密钥都不同即使攻击者截获了某一次通信数据也无法推导出其他通信的密钥。6. 踩坑经验与性能调优记录6.1 密钥生成方式的坑早期我在项目里图省事直接用字符串的字符码作为密钥字节比如KeyBytes[i] : Ord(KeyStr[i])。这种做法存在严重问题密钥空间被压缩到了可打印字符范围大大降低暴力破解的难度。正确做法是使用随机数发生器生成二进制密钥或者用PBKDF2算法从密码短语派生密钥。DCPcrypt2配套的单元里包含了TDCP_sha512这类强哈希可以用它做密钥的初步混淆但更专业的做法还是走加密库里的KDF接口。在实际项目中我一般结合两部分生成密钥一部分来源于本地硬件指纹或固定配置文件另一部分来源于随机种子两者做散列混合后得到的字节串作为AES密钥。这样可以保证密钥既稳定不因重启改变又不可预测。6.2 性能对比该用哪类算法的时机把握我在日常开发中做过简单的性能实测算法加密1MB数据耗时相对适用场景RC4极快非安全混淆格式保护Blowfish快老系统兼容AES-128较快通用安全加密推荐Twofish中等安全性要求更高的场景SHA-256快文件校验、密码哈希这里的核心结论是在绝大多数桌面应用场景中AES-128/256的加解密速度完全够用1MB数据块加密耗时通常是毫秒级无需刻意追求RC4的速度。如果加密大量小文件创建和释放TDCP_rijndael对象的开销反而比加解密本身更大。这时我习惯采用复用Cipher对象的方式程序启动时创建一次加解密时重置状态即可。但必须注意公用的Cipher对象要做好线程同步Delphi的DCPcrypt2组件本身不是线程安全的多线程环境需要为每个线程创建独立实例。6.3 版本间的兼容性陷阱DCPcrypt2在不同分支版本里的接口有细微差别。比如某些版本要求Init方法里传密钥指针某些版本直接接受字节数组EncryptCBC等方法在参数数量和类型上也有差异。我的建议是锁定一个稳定版本不要频繁升级。在项目里废弃旧版改用新版时一定先跑一遍现有的加解密测试用例确保新旧版本加密结果一致。加密数据的兼容性问题一旦出现往往是灾难性的因为已经落盘的密文无法再用旧代码解开。同时要注意用默认参数时不同算法对密钥长度的处理方式不同超过密钥长度上限的密钥会被截断或直接报错。编码时应对所有输入密钥做长度校验提前暴露问题而不是等运行时崩溃。6.4 多线程环境下的并发加密现代应用很少有单线程场景DCPcrypt2不保证线程安全这点务必注意。我在服务端项目里使用过线程池并发加密多个文件一开始直接用了全局Cipher实例结果出现随机性解密失败排查了很久才定位到是Cipher内部状态被多个线程同时写坏。解决方案有两种方案一线程局部变量。每个线程创建自己的Cipher实例用完释放互不干扰。方案二加锁串行化。对加解密操作统一加互斥锁实现简单但牺牲并发性能。方案一适合加密操作频繁的场景方案二适合调用量不大但需要保证共享唯一的场景。我个人推荐方案一因为DCPcrypt2对象的创建成本很低没必要为了省一点创建开销引入复杂的并发控制。6.5 密钥管理和算法迁移准备最后想提醒的是加密项目不能说有了加密就一劳永逸。行业内的大量实践表明算法本身可能会随着时间暴露出弱点项目里的加解密模块一定要提前做好版本标记和可扩展性设计。我在系统中的做法是在加密数据的文件头或报文头部加上版本号字段表明这块密文用的是哪套算法、哪个密钥索引。这样将来升级AES密钥长度或更换哈希算法时旧数据仍然可以按照版本号找到对应的解密逻辑完成迁移。同时密钥管理上建议把密钥和加密逻辑分离密钥存放在独立的配置模块中定期轮换。DCPcrypt2只是帮我们做算法运算密钥的生命周期管理始终是整个加密设计里最需要人力投入的部分。本文还有配套的精品资源点击获取