简介：TMS Cryptography Pack 3.4.0.1 是面向 Delphi XE10.2 开发者的加密组件库，适合需要在桌面与移动应用中集成数据保护、安全通信的中高级开发者。它覆盖 AES、DES、3DES、Blowfish、Twofish、RC4、RSA 等对称与非对称算法，并提供 MD5、SHA 系列哈希、HMAC 消息认证、数字签名、X.509 证书管理、加密级随机数生成及 PKCS#7 兼容支持，可满足文件加密、密钥交换、S/MIME 邮件等场景。资源包共 210 个文件，约 71.54MB，以 dcu 编译单元、o 目标文件、dcp 包缓存、bpl 运行时包和 dpk/dproj 工程文件为主，另含 bmp 图标位图、res 资源、a 静态库、dylib 动态库及 pdf 说明文档，便于直接编译集成。目前已有 270 人学习下载，可帮助读者快速掌握该加密库的 API 设计与跨平台使用方式。
1. 当老 Delphi 项目撞上加密库：这个包到底解决什么问题
手里维护着一套跑了快十年的 Delphi 老系统，某天安全审计提了一条：客户端与服务端之间的报文是明文，必须上加密。你打开工程一看，代码里散落着几处自研的异或混淆，连个像样的哈希都没有。这时候去翻社区，大概率会翻到一个名字里带 Cryptography Pack 的组件包——标题里这串TMS_Cryptography_Pack_3.4.0.1_for_XE10.2说的就是它：一套面向 Delphi/C++Builder 的加密组件库，版本 3.4.0.1，适配 XE10.2 这个 IDE 版本。
它解决的不是"从零实现 AES"这种学术问题，而是"在既有 VCL/FMX 工程里，用最少的胶水代码把对称加密、非对称加密、哈希、编码这几件事接进去"。适合谁？适合手上有一坨 Delphi 遗留代码、又不想自己手撸密码学原语的工程师。密码学这东西，自己写等于给自己埋雷，用成熟封装才是正路。这一篇就按"它是什么、怎么接、参数怎么调、哪里会翻车"的顺序，把这条路走一遍。
2. 拆开这个包：组件构成与选型理由
2.1 它到底封装了哪几类能力
这类组件包通常按密码学用途分成几大块，理解这个分类比记 API 名字重要得多，因为选错类别是新手最常见的翻车点。
第一类是对称加密，代表算法是 AES，用来加密大批量数据，比如整个报文体、本地缓存文件。特点是快，但密钥分发是难题。第二类是非对称加密，代表是 RSA 和 ECC，用来做密钥交换和数字签名，慢但解决了"密钥怎么安全送到对方手里"。第三类是哈希与消息认证，SHA-256、SHA-512、HMAC 这些，用来做完整性校验和口令存储。第四类是编码与格式，Base64、Hex 这类，严格说不算加密，但实际工程里天天和加密混着用。
一个成熟的包会把这几类都覆盖，并且提供统一的流式接口——这点很关键，因为加密大文件时你不能把整个文件读进内存再处理，必须支持分块。
2.2 为什么在 XE10.2 上要挑版本匹配的包
Delphi 的组件包对 IDE 版本极其敏感，这是血泪经验。XE10.2 用的是特定的编译器版本和运行时库（RTL）接口，一个为更老版本编译的.bpl直接装进去，轻则组件面板不显示，重则 IDE 启动就崩。
判断版本是否匹配，看三个地方：包文件名里的版本号（这里就是 3.4.0.1）、安装包内.dpk工程声明的{$R *.res}与 requires 列表、以及编译产物是 32 位还是 64 位。XE10.2 同时支持 Win32 和 Win64，如果你的目标程序是 64 位，就必须用 64 位编译出来的包，混用会报"单元找不到"或者运行时访问冲突。
提示：拿到任何 Delphi 组件包，先别急着装。把
.dpk用记事本打开，看requires段里引用的 RTL 单元名，和你的 IDE 版本对得上再动手。
2.3 安装到 IDE 的标准步骤
假设你拿到的是源码分发形式（这类包通常给源码而非纯二进制），安装流程大致如下。先解压到一个不含中文和空格的路径，中文路径是 Delphi 编译器的老毛病，会在编译资源时莫名报错。
# 假设解压到 D:\Components\CryptoPack # 目录结构通常是： # D:\Components\CryptoPack\source\ 源码单元 # D:\Components\CryptoPack\packages\ .dpk 包工程 # D:\Components\CryptoPack\demo\ 示例然后在 IDE 里操作：File > Open Project，打开packages目录下对应你 IDE 版本的.dpk。右键工程节点选Build，编译通过后再右键选Install。安装成功后，组件面板上会出现新的页签，里面是各个加密组件。
如果Install是灰的，说明编译没真正成功，去看Messages窗口的报错。最常见的是引用了某个你没装的第三方单元，或者路径没加到Tools > Options > Library的搜索路径里。
2.4 最小可用示例：一次 AES 加解密
装好之后，先别碰复杂的。用最少的代码验证"能跑通"，这一步过了再谈别的。下面是一个典型的对称加密调用骨架，具体类名以你包里的实际命名为准，但调用逻辑是通用的。
uses CryptoPack.Symmetric; // 假设的单元名，按实际替换 procedure TForm1.DemoAES; var Cipher: TSymmetricCipher; Key, IV, Plain, CipherText, Decrypted: TBytes; begin // 密钥长度决定 AES 强度：16 字节=AES-128，32 字节=AES-256 Key := TEncoding.UTF8.GetBytes('0123456789abcdef0123456789abcdef'); // 32 字节 // IV 必须和块大小一致，AES 块固定 16 字节 IV := TEncoding.UTF8.GetBytes('abcdef0123456789'); // 16 字节 Plain := TEncoding.UTF8.GetBytes('需要保护的报文内容'); Cipher := TSymmetricCipher.Create; try Cipher.Algorithm := saAES; Cipher.Mode := cmCBC; // 分组模式，见 2.5 Cipher.Padding := cpPKCS7; // 填充方式 Cipher.SetKey(Key, IV); CipherText := Cipher.Encrypt(Plain); Decrypted := Cipher.Decrypt(CipherText); // 验证往返一致 Assert(TEncoding.UTF8.GetString(Decrypted) = '需要保护的报文内容'); finally Cipher.Free; end; end;逻辑说明：先构造密钥和 IV，再设置算法、模式、填充三个核心参数，然后调用Encrypt/Decrypt。参数说明上，Key的长度直接决定 AES 强度，别用短密钥然后自己补零，那是自欺欺人；IV在 CBC 模式下每次加密都应该是随机且唯一的，上面为了演示写死了，生产环境必须改。
2.5 分组模式与填充：两个最容易被忽略的参数
很多人调通了加密就以为完事，结果上线后出各种诡异问题，根子都在模式和填充上。
分组模式里，ECB 绝对不要用。它对相同明文块产生相同密文块，一张图加密完还能看出轮廓，这是经典翻车案例。CBC是兼容性最好的选择，但需要 IV 且不能并行。CTR/GCM更现代，GCM 还自带认证，但老版本组件包不一定支持。选型上，如果对方系统是老古董，用 CBC；如果双方都能升级，优先 GCM。
填充方式上，PKCS7 是标准做法。只有当明文长度恰好是块大小整数倍时，某些实现会出问题，PKCS7 会额外补一整块，这是正确行为，别以为是 bug 去改。
3. 把加密接进真实工程：密钥、哈希与签名
3.1 密钥管理：别把密钥写死在代码里
演示代码里把密钥写成字符串常量，这在生产环境是重大隐患。反编译一下字符串表就全暴露了。常见做法是：密钥不落代码，从配置或环境变量读；更稳妥的是用非对称加密保护对称密钥——服务端生成一个随机 AES 密钥，用客户端的 RSA 公钥加密后传过去，客户端用私钥解开。
// 用 RSA 公钥加密一个临时 AES 密钥（密钥交换的典型用法） procedure TForm1.WrapSessionKey; var RSA: TAsymmetricCipher; SessionKey, Wrapped: TBytes; begin // 生成 32 字节随机会话密钥 SetLength(SessionKey, 32); // 用系统随机源填充，不要用 Random() RandomBytes(SessionKey); RSA := TAsymmetricCipher.Create; try RSA.Algorithm := aaRSA; RSA.LoadPublicKey('public_key.pem'); // 从文件加载，不硬编码 Wrapped := RSA.Encrypt(SessionKey); // 只有持有私钥的一方能解开 finally RSA.Free; end; end;参数说明：RSA 密钥长度至少 2048 位，1024 位现在已被认为不安全。注意 RSA 能加密的数据长度受密钥长度限制（2048 位大约只能加密 245 字节），所以它只用来包裹短密钥，不能直接加密业务数据——这是新手常犯的错，拿 RSA 去加密整个文件，直接报长度超限。
3.2 哈希与 HMAC：完整性校验的正确姿势
哈希用来验证数据没被篡改。但单纯对数据做 SHA-256 有个漏洞：攻击者可以同时改数据和哈希。解决办法是 HMAC——用密钥参与哈希计算，攻击者没有密钥就伪造不出正确的 HMAC。
procedure TForm1.DemoHMAC; var Hasher: THash; Mac: TBytes; begin Hasher := THash.Create; try Hasher.Algorithm := haSHA256; // HMAC 需要密钥，普通哈希不需要 Mac := Hasher.HMAC(TEncoding.UTF8.GetBytes('报文内容'), TEncoding.UTF8.GetBytes('共享密钥')); // 发送方把 Mac 附在报文后，接收方用同样密钥重算并比对 finally Hasher.Free; end; end;比对 HMAC 时要用恒定时间比较，别用普通的字符串相等。普通比较在第一个不同字节就返回，攻击者能通过测量响应时间逐字节猜出正确值，这叫时序攻击。成熟的包会提供SecureCompare之类的函数，没有的话自己写一个逐字节异或累加的版本。
3.3 口令存储：为什么不能用裸 SHA-256
如果这个包用来存用户口令，记住一条：裸哈希存口令是不合格的。SHA-256 太快了，攻击者用 GPU 每秒能算几十亿次，弱口令瞬间被彩虹表或暴力破解。
正确做法是用专门的慢哈希算法，比如 PBKDF2、bcrypt、scrypt、Argon2。这类算法通过迭代和加盐，把单次计算成本拉高到毫秒级，让暴力破解变得不划算。如果组件包只提供 SHA 系列，那就用 PBKDF2 模式（很多包的哈希组件带这个），迭代次数至少 10 万次起步，并且每个用户用独立的随机盐。
// PBKDF2 派生口令哈希，盐必须每个用户独立且随机 procedure TForm1.StorePassword(const UserPwd: string); var Salt, Derived: TBytes; begin SetLength(Salt, 16); RandomBytes(Salt); // 16 字节随机盐，和哈希一起存库 Derived := PBKDF2(TEncoding.UTF8.GetBytes(UserPwd), Salt, 100000, // 迭代次数 32, // 输出长度 haSHA256); // 存库：salt 和 Derived 都要存，验证时用同样的盐和次数重算 end;参数说明：迭代次数是安全性和性能的平衡点，10 万次在现代 CPU 上大约几十毫秒，用户无感，但攻击者成本翻了几万倍。盐不需要保密，但要唯一。
4. 避坑与排查：那些让加密"看起来能用其实不安全"的细节
4.1 现象：加密后数据变长，解密却报填充错误
原因通常是加密端和解密端的填充方式不一致，或者传输过程中字节被改动。CBC 模式下如果密文被截断或篡改，解密时最后一个块的填充校验会失败。解决：确认两端Padding设置一致；传输时对密文做 Base64 编码，避免二进制字节在文本协议里被转义破坏。
4.2 现象：同样的明文每次加密结果不同，以为坏了
这是正常且正确的行为，前提是你用了随机 IV。CBC/GCM 每次加密都应该用新的随机 IV，并把 IV 附在密文前面一起传。如果每次结果都一样，说明 IV 写死了，这恰恰是安全隐患。解决：加密时生成随机 IV，解密时从密文头部取出 IV。
4.3 现象：64 位程序运行时报"单元找不到"或访问冲突
原因是装了 32 位的包，却编译 64 位目标。Delphi 的包分平台，Win32 和 Win64 是两套编译产物。解决：在 IDE 的Project Manager里切换目标平台，确认对应平台的包已编译安装；或者干脆用源码方式把单元直接加进工程，绕开包安装的平台问题。
4.4 现象：加密大文件时内存暴涨甚至崩溃
原因是用了"一次性加密整个字节数组"的接口，把几百 MB 文件全读进内存。解决：改用流式接口，分块读写。典型模式是开一个输入流和一个输出流，循环读固定大小（比如 64KB）的块，逐块加密写出。注意最后一块要正确处理填充。
4.5 现象：换了台机器解密就失败
排查顺序：密钥是否一致（大小写、编码）、IV 是否随密文一起传了、字符编码是否统一（UTF-8 vs ANSI）。最常见的是密钥字符串在不同代码页下GetBytes结果不同。解决：密钥和 IV 统一用字节数组或 Base64 字符串传递，不要用带中文或特殊字符的字符串直接转字节。
5. 进阶：用测试向量验证你的加密实现是否正确
调通不代表正确。密码学实现有个黄金标准：已知答案测试（KAT）。用标准测试向量喂进去，比对输出。NIST 对 AES、SHA 都有公开的测试向量，拿几组来跑，能立刻发现实现或参数配置的错误。
下面是一个验证 AES-128 ECB 的测试向量用法（ECB 仅用于验证算法本身，生产别用）：
procedure TForm1.VerifyAESVector; var Cipher: TSymmetricCipher; Key, Plain, Expected, Actual: TBytes; begin // NIST 公开测试向量：AES-128, key=000102...0f, plain=00112233...ff Key := HexToBytes('000102030405060708090a0b0c0d0e0f'); Plain := HexToBytes('00112233445566778899aabbccddeeff'); Expected := HexToBytes('69c4e0d86a7b0430d8cdb78070b4c55a'); Cipher := TSymmetricCipher.Create; try Cipher.Algorithm := saAES; Cipher.Mode := cmECB; // 测试向量用 ECB，仅为验证算法 Cipher.Padding := cpNone; // 明文恰好 16 字节，无填充 Cipher.SetKey(Key, nil); Actual := Cipher.Encrypt(Plain); Assert(BytesToHex(Actual) = BytesToHex(Expected), 'AES 实现不正确'); finally Cipher.Free; end; end;逻辑说明：测试向量是密码学界的"后悔药"，任何实现只要对不上标准向量，就是错的，不用怀疑向量。参数上注意 ECB 模式不需要 IV，明文长度恰好等于块大小时填充设为 None。跑通这个，说明算法核心没问题，剩下的就是模式、填充、密钥管理的工程问题了。
再补一个习惯：每次升级组件包版本后，重跑一遍测试向量。版本升级可能改了默认参数，比如默认模式从 CBC 变成 GCM，或者默认填充变了，这些静默变更会让老代码行为漂移。我一般会在工程里留一个CryptoSmokeTest单元，专门跑几组向量和一次往返加解密，CI 里带上，比事后排查省心得多。
最后一句实在话：加密这块，能不自研就不自研，能用标准向量验证就别靠"跑起来没报错"下结论。我踩过最深的坑，就是当年觉得"加密完能解密回来就是对的"，结果模式选错、IV 复用，安全性等于没有。希望帮到你。
本文还有配套的精品资源，点击获取
