OpenSSL加解密验证实战：AES/SM4/DES/3DES/RSA参数与避坑指南

做加解密验证最容易踩的坑，不是算法本身难，而是同一套参数在不同模式下结果天差地别，命令行能解开的东西，写成代码却总是差一位。我最近整理了一个 SKE（Symmetric Key Encryption，对称密钥加密）加解密验证项目，把 AES、SM4、DES、RSA、3DES_EDE、3DES_EEE 六类算法全部跑通，命令行和 OpenSSL API 两条路都验证了一遍。这篇文章就把整个过程拆开讲，重点说清楚参数怎么选、命令怎么写、代码怎么封装，以及哪些坑是文档里不会写的。不管你是刚接触密码学的学生，还是要在项目里接入国密算法的工程师，这套验证流程都能直接照着抄。

1. 这个 SKE 验证项目到底在验证什么

1.1 为什么要把六种算法放进同一个验证程序

很多教程只教你调一个算法，比如单独跑一遍 AES，能加能解就算完事。但真实项目里往往需要面对历史遗留系统、第三方平台、国密改造等场景，同一个业务数据可能需要用不同算法加解密。这个项目名为 SKE，本质上是一套“算法验证脚手架”，它要回答的问题很朴素：给定任意一种算法、一组参数、一段明文，我的工具能不能正确加密，并且用正确的密钥完整解密回来。

把 AES、SM4、DES、RSA、3DES_EDE、3DES_EEE 放在一起，是为了统一验证标准。对称加密部分全部走 EVP 接口，非对称的 RSA 走 EVP_PKEY 接口，这样每次新增算法时只需要换一个 cipher 名字，其他逻辑完全复用。项目跑通之后，你会得到一张非常直观的对照表：块大小、密钥长度、IV 长度、填充方式、OpenSSL 命令和 API 调用形式，全部一目了然。这个东西最有价值的地方，是帮你建立“参数敏感性”的直觉，你会清楚知道哪些参数必须严格匹配，哪些参数丢了也能解开。

1.2 AES、SM4、DES、3DES、RSA 的定位与选型逻辑

六种算法放在一起，首先要理解它们的“辈分”和适用场景。

AES 是当前国际通用的对称加密标准，块大小 16 字节，密钥支持 16、24、32 字节，对应 AES-128、AES-192、AES-256。安全性高、硬件加速普遍，是绝大多数新系统的默认选择。SM4 是国密对称算法，同样 16 字节块，密钥固定 16 字节，在政务、金融、能源等有合规要求的行业里必须支持。DES 是早期分组算法，块大小 8 字节，密钥 8 字节，存在大量已知弱点，现实中通常只出现在老系统的兼容接口里。3DES 是 DES 的强化版，本质是用三个 DES 密钥对数据做三次变换，块大小仍是 8 字节，密钥长度 24 字节，其中 3DES_EDE 是加密-解密-加密结构，3DES_EEE 是加密-加密-加密结构，后者在部分硬件加密机和支付终端里还在用。RSA 则属于非对称算法，用来加密对称密钥或小数据块，不参与大数据量加密。

选型逻辑很简单：新项目优先 AES，如果需要国密合规就 SM4，遇到老协议只能用 DES 或 3DES，密钥交换和数字信封场景用 RSA。这个验证项目把六种都放进来，不是为了让你在生产环境里滥用 DES，而是确保你“知道怎么用、也知道为什么不用”。

1.3 手工验证与库调用的本质区别

有人会问，直接用 OpenSSL 命令行加解密不就行了，为什么还要写代码验证？两方面原因。第一，命令行只能验证算法本身，验证不了你的应用层逻辑，比如密钥从哪来、IV 怎么传输、密文用什么编码存储，这些才是工程里最容易出错的地方。第二，很多系统要求在特定语言环境里嵌入加解密能力，比如 C 程序调用 OpenSSL 库，或者通过中间件调用底层密码模块，这时候你必须有代码层面的验证结果作为依据。

我个人的做法是“双轨验证”：先用命令行把一条已知明文跑通，拿到密文；再用代码对同一条明文、同一个密钥、同一个 IV 加密，对比密文是否一致。两者一致，说明代码和命令行的参数语义完全匹配；不一致，说明某个环节理解偏了，这是定位问题最快的方式。后面每一个算法我都会按这个套路讲。

2. 环境准备与命令行快速验证

2.1 检查 OpenSSL 版本与算法支持

动手前先确认环境。不同 OpenSSL 版本支持算法差异很大，尤其是 SM4，OpenSSL 1.1.1 才开始原生支持，更早的版本要么没有，要么需要编译时指定。我使用的是 3.x 版本，命令如下：

openssl version

输出类似OpenSSL 3.0.13 30 Jan 2024。接着检查算法列表：

openssl list -cipher-algorithms | grep -E "AES|SM4|DES" openssl list -public-key-algorithms | grep RSA

这一步很重要。如果你的 OpenSSL 里连SM4-CBC都搜不到，后面所有国密验证都会失败，这时候不要继续往下走，先升级 OpenSSL 或者重新编译启用相关模块。编译参数通常涉及enable-sm4之类的开关，但这属于另一个话题，我在后面常见问题部分再提。

2.2 五种对称算法的命令行加解密示例

命令行验证统一用openssl enc。我建议直接指定-K（密钥）和-iv（初始向量），不要用口令派生，这样可以完全控制参数，避免-pass和-salt引入额外的密钥派生逻辑。

先准备一段明文：

echo -n "SKE verification with OpenSSL" > plain.txt xxd plain.txt

AES-128-CBC 示例：

openssl enc -aes-128-cbc -K 00112233445566778899aabbccddeeff -iv 102030405060708090a0b0c0d0e0f0102 -in plain.txt -out aes_cipher.bin openssl enc -aes-128-cbc -d -K 00112233445566778899aabbccddeeff -iv 102030405060708090a0b0c0d0e0f0102 -in aes_cipher.bin -out aes_dec.txt cmp plain.txt aes_dec.txt && echo "AES-CBC OK"

注意-K和-iv后面跟的是十六进制字符串，不带0x前缀，长度要求精确匹配。AES-128 密钥 32 个 hex 字符，IV 也是 32 个 hex 字符。

SM4-CBC 示例：

openssl enc -sm4-cbc -K 00112233445566778899aabbccddeeff -iv 102030405060708090a0b0c0d0e0f0102 -in plain.txt -out sm4_cipher.bin openssl enc -sm4-cbc -d -K 00112233445566778899aabbccddeeff -iv 102030405060708090a0b0c0d0e0f0102 -in sm4_cipher.bin -out sm4_dec.txt cmp plain.txt sm4_dec.txt && echo "SM4-CBC OK"

SM4 的密钥和 IV 长度恰好和 AES-128 一样，都是 16 字节，代码层很容易复用同一套逻辑。

DES-CBC 示例：

openssl enc -des-cbc -K 0011223344556677 -iv 1020304050607080 -in plain.txt -out des_cipher.bin openssl enc -des-cbc -d -K 0011223344556677 -iv 1020304050607080 -in des_cipher.bin -out des_dec.txt cmp plain.txt des_dec.txt && echo "DES-CBC OK"

DES 密钥 8 字节，IV 也是 8 字节，对应 16 个 hex 字符。这里踩过坑的是明文长度，DES 块大小 8 字节，明文如果不是 8 的倍数，默认 PKCS#7 填充会补足，解密时自动去掉，所以cmp能通过。

3DES-EDE-CBC 示例：

openssl enc -des-ede3-cbc -K 00112233445566778899aabbccddeeff1020304050607080 -iv 1020304050607080 -in plain.txt -out des3_ede_cipher.bin openssl enc -des-ede3-cbc -d -K 00112233445566778899aabbccddeeff1020304050607080 -iv 1020304050607080 -in des3_ede_cipher.bin -out des3_ede_dec.txt cmp plain.txt des3_ede_dec.txt && echo "3DES-EDE-CBC OK"

des-ede3-cbc在 OpenSSL 里就是标准的 3DES EDE 模式，密钥 24 字节，IV 8 字节。注意，这里没有直接的des-eee3-cbc这种命令行名称，3DES_EEE 需要走低级接口，我在第 4 部分专门讲。

2.3 RSA 命令行加解密与密钥准备

RSA 不是分组算法，没有 IV 和块填充的概念，但需要先生成密钥对。我用 2048 位密钥做演示：

openssl genrsa -out rsa_private.pem 2048 openssl rsa -in rsa_private.pem -pubout -out rsa_public.pem

然后加密：

echo -n "RSA with OpenSSL" > rsa_plain.txt openssl pkeyutl -encrypt -pubin -inkey rsa_public.pem -in rsa_plain.txt -out rsa_cipher.bin -pkeyopt rsa_padding_mode:oaep openssl pkeyutl -decrypt -inkey rsa_private.pem -in rsa_cipher.bin -out rsa_dec.txt -pkeyopt rsa_padding_mode:oaep cmp rsa_plain.txt rsa_dec.txt && echo "RSA-OAEP OK"

RSA 直接加密数据长度受限，2048 位密钥配合 OAEP 填充最多只能加密 190 字节左右（256 - 42，具体取决于哈希长度）。所以日常工程里 RSA 只用来加密对称密钥，真正的数据用 AES/SM4 加密，这就是数字信封，也是这个验证项目把 RSA 和对称算法放在一起的原因。

3. 核心参数拆解：模式、填充、密钥长度

3.1 分组工作模式怎么选

对称分组算法加密时，每个块固定长度独立处理，但直接独立处理同一明文块会得到同一密文块，这叫 ECB 模式，容易被猜出数据规律，生产环境不推荐。CBC 模式让每个明文块先跟前一个密文块异或再加密，同样明文块在不同位置会得到不同密文，解决了一部分问题，但必须保证 IV 唯一性和完整性。CTR 模式把计数器加密后与明文异或，可以并行、不需要填充，流式传输友好。GCM 模式在 CTR 基础上增加认证标签，能同时保证机密性和完整性，是当前最推荐的选择。

这个验证项目里我把 CBC 作为默认模式，原因是它最通用、兼容性最好，也能最直观地演示填充逻辑。CTR 和 GCM 的代码结构完全一样，只是 EVP cipher 名称不同，比如EVP_aes_128_ctr()和EVP_aes_128_gcm()。你在做验证时，建议先把 CBC 跑通，再对照跑一遍 CTR，体会一下“为什么 CTR 不需要 PKCS#7 填充但仍可能要求数据长度对齐”的区别。

3.2 填充方式 PKCS#7 与 NoPadding

分组密码要求明文长度必须是块大小的整数倍，不是时就要填充。OpenSSL EVP 默认启用 PKCS#7 填充：缺 N 字节就补 N 个值为 N 的字节，解密时根据最后一个字节判断去掉多少。这种方式很巧妙，因为即使明文本来就对齐，也会额外补满一整个块，解密时能明确区分。命令行里不指定-nopad就默认 PKCS#7。

NoPadding 模式适合数据本来就对齐、或者上层协议自己处理填充的场景。命令行加-nopad后，如果明文长度不是块大小整数倍，加密会直接报错，比如 DES 的 8 字节块明文写了 10 字节，会提示bad decrypt或直接失败。API 里可以用EVP_CIPHER_CTX_set_padding(ctx, 0)关闭填充。

这里有个非常经典的坑：解密时如果填充校验失败，OpenSSL 会返回bad decrypt，但这不一定代表密钥错误，也可能是密文被截断、密钥正确但密文中途损坏、或者明明用 NoPadding 加密却用默认 PKCS#7 解密。排查的顺序应该是先确认数据长度、再确认填充方式、最后才怀疑密钥。

3.3 密钥长度、IV 与 3DES_EDE/EEE 的差异

我把这些参数整理成一张表，验证时直接对照，省得每次翻文档。

注意 3DES_EDE 和 3DES_EEE 的密钥长度都是 24 字节，因为都是三组 8 字节密钥。两者的区别在于三次 DES 变换的顺序：EDE 是“加密-解密-加密”，EEE 是“加密-加密-加密”。解密时 EDE 变成“解密-加密-解密”，EEE 变成“解密-解密-解密”。在 OpenSSL 高层 EVP 接口里只有 EDE 实现，没有直接暴露 EEE，所以 EEE 必须用 DES 低级接口手动组合三次 DES 操作。这一点是这个项目最有价值的地方，很多人在网上搜半天也找不到现成答案。

3.4 3DES_EDE 与 3DES_EEE 的兼容性思考

有人会问，既然 OpenSSL 只提供 EDE，为什么还要单独验证 EEE？因为现实里确实存在需要 EEE 的硬件加密机和金融终端，它们的硬件逻辑固定为三把钥匙连续加密，不支持解密穿插。有些老协议文档里写“3DES”但没明确是 EDE 还是 EEE，这时候如果你默认用 EDE 去联调，会出现两边结果不一致，定位半天才发现是变换序的问题。

验证 EEE 时，如果同一份密钥既用于 EDE 也用于 EEE，两者得到的密文完全不同，这不是算法 bug，而是结构差异。所以在验证项目里，我给 EDE 和 EEE 分别定义密钥结构体，并且打印密钥编排后的 schedule，方便肉眼对比。

4. 用 OpenSSL API 封装统一加解密

4.1 对称算法的统一封装思路

命令行验证过了，接下来写代码。我用的是 OpenSSL EVP（Envelope）接口，这层抽象统一了算法调用方式，好处是代码主体不用变，只需传入不同EVP_CIPHER指针。核心函数大概是这样：

#include <openssl/evp.h> #include <openssl/rand.h> #include <stdio.h> #include <string.h> static int crypt_block(const EVP_CIPHER *cipher, const unsigned char *key, const unsigned char *iv, const unsigned char *in, int in_len, unsigned char *out, int enc) { EVP_CIPHER_CTX *ctx = NULL; int out_len = 0, final_len = 0; int ret = 0; ctx = EVP_CIPHER_CTX_new(); if (!ctx) return -1; /* enc=1 加密, enc=0 解密 */ if (EVP_CipherInit_ex(ctx, cipher, NULL, key, iv, enc) != 1) goto done; /* 显式开启 PKCS#7 填充 */ if (EVP_CIPHER_CTX_set_padding(ctx, 1) != 1) goto done; if (EVP_CipherUpdate(ctx, out, &out_len, in, in_len) != 1) goto done; if (EVP_CipherFinal_ex(ctx, out + out_len, &final_len) != 1) goto done; ret = out_len + final_len; done: EVP_CIPHER_CTX_free(ctx); return ret; }

这个封装可以直接在 AES、SM4、DES、3DES-EDE 上调。注意EVP_CipherFinal_ex失败时，已经写出的部分数据仍然有效，但结果不可信，调用方必须检查返回值。我在实际验证里遇到过解密尾块填充错误的情况，就是因为没检查返回值，拿到一段半截明文还以为自己写对了。

4.2 AES-CBC 代码实操与参数计算

AES-128-CBC 调用示例：

unsigned char key[16] = {0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77, 0x88,0x99,0xaa,0xbb,0xcc,0xdd,0xee,0xff}; unsigned char iv[16] = {0x10,0x20,0x30,0x40,0x50,0x60,0x70,0x80, 0x90,0xa0,0xb0,0xc0,0xd0,0xe0,0xf0,0x01}; unsigned char plain[32] = "SKE verification with AES-CBC"; unsigned char cipher[128], dec[128]; int clen = crypt_block(EVP_aes_128_cbc(), key, iv, plain, strlen((char*)plain), cipher, 1); int dlen = crypt_block(EVP_aes_128_cbc(), key, iv, cipher, clen, dec, 0); /* 验证 dec 和 plain 的 hex 是否一致 */

参数计算上，这里明文长度是 30 字节，AES 块 16 字节，PKCS#7 填充后密文长度为 32 字节，即30 + (16 - 30 % 16) % 16。写成公式就是：

pad_len = block_size - (data_len % block_size) cipher_len = data_len + pad_len

当data_len % block_size == 0时，pad_len等于整个块大小 16，所以密文比明文多 16 字节，这符合 PKCS#7 的规则。验证时可以用这个公式先手算一遍，再对比代码输出的clen。

4.3 SM4-CBC 代码实操与国密注意事项

SM4 的代码几乎不用改，只需要把 cipher 从EVP_aes_128_cbc()换成EVP_sm4_cbc()：

unsigned char sm4_key[16] = {0x01,0x23,0x45,0x67,0x89,0xab,0xcd,0xef, 0xfe,0xdc,0xba,0x98,0x76,0x54,0x32,0x10}; unsigned char sm4_iv[16] = {0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77, 0x88,0x99,0xaa,0xbb,0xcc,0xdd,0xee,0xff}; int clen = crypt_block(EVP_sm4_cbc(), sm4_key, sm4_iv, plain, strlen((char*)plain), cipher, 1);

国密场景有几个特有注意事项。一是 SM4 对密钥和 IV 的十六进制长度要求极其严格，多一位少一位都会直接报错。二是 OpenSSL 3.x 里 SM4 默认可能不在某些发行版的编译选项里，但openssl list -cipher-algorithms | grep SM4能查到就说明可用。三是合规要求通常是 SM4 加密敏感数据、SM2/SM3 做签名和摘要，所以验证项目里最好把 SM4 和 RSA 拆开，不要让非对称逻辑干扰对称验证。

我在实际验证中还测过 ECB 模式的 SM4，命令是openssl enc -sm4-ecb。ECB 模式不需要 IV，但 OpenSSL 要求你调用时传入一个空 IV 指针或全零 IV，否则会报参数错误。这个细节容易忽略，我把iv在 ECB 模式下传成NULL，结果底层EVP_CipherInit_ex能通过，但某些封装库内部会对 IV 长度做校验，反而失败，最稳妥的方式是仍然传一个长度正确的空 buffer。

4.4 RSA 代码实操与密钥管理

RSA 部分不能用上面那个对称封装，需要走EVP_PKEY。我用 OpenSSL 3.x 推荐的方式，先生成密钥，再通过EVP_PKEY_encrypt和EVP_PKEY_decrypt完成加解密：

#include <openssl/evp.h> #include <openssl/rsa.h> #include <openssl/pem.h> EVP_PKEY *pkey = NULL; EVP_PKEY_CTX *gctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL); EVP_PKEY_keygen_init(gctx); EVP_PKEY_CTX_set_rsa_keygen_bits(gctx, 2048); EVP_PKEY_keygen(gctx, &pkey); EVP_PKEY_CTX_free(gctx);

加密：

EVP_PKEY_CTX *ectx = EVP_PKEY_CTX_new(pkey, NULL); EVP_PKEY_encrypt_init(ectx); EVP_PKEY_CTX_set_rsa_padding(ectx, RSA_PKCS1_OAEP_PADDING); size_t outlen = 0; EVP_PKEY_encrypt(ectx, NULL, &outlen, msg, msglen); unsigned char *cipher = OPENSSL_malloc(outlen); EVP_PKEY_encrypt(ectx, cipher, &outlen, msg, msglen);

解密对称：

EVP_PKEY_CTX *dctx = EVP_PKEY_CTX_new(pkey, NULL); EVP_PKEY_decrypt_init(dctx); EVP_PKEY_CTX_set_rsa_padding(dctx, RSA_PKCS1_OAEP_PADDING); size_t doutlen = 0; EVP_PKEY_decrypt(dctx, NULL, &doutlen, cipher, outlen); unsigned char *dec = OPENSSL_malloc(doutlen); EVP_PKEY_decrypt(dctx, dec, &doutlen, cipher, outlen);

RSA 加解密核心是密钥管理，不是算法本身。验证项目里建议这样组织：私钥留本地，公钥分发给联调方，加解密时用PEM_read_PrivateKey和PEM_read_PUBKEY读取，避免在代码里硬编码密钥。命令行生成的两个 pem 文件可以直接读，代码和命令行之间也能互相验证，这也是第 2 节命令行验证的意义。

5. 常见问题排查与避坑实录

5.1 命令行和代码结果不一致

最典型的场景：命令行openssl enc -sm4-cbc -K ... -iv ...能解密，代码里用EVP_sm4_cbc()加密后再解密却报错。排查步骤先打印密钥和 IV 的 hex，确认没有字节序问题。我遇到过因为从配置文件读取密钥时把换行符吃进去，导致密钥变长，命令行粘贴时看不到，但代码一跑就出错。解决方案是在读取后打印长度，强制校验 16 字节。

另一种不一致是填充规则理解错了。命令行默认就是 PKCS#7，代码里如果某个环节不小心调了EVP_CIPHER_CTX_set_padding(ctx, 0)，两边结果必然不同。建议统一走默认填充，除非你明确知道自己在做什么。

5.2 填充错误与数据长度问题

解密时报bad decrypt，首先要看数据长度。CBC 模式如果密文不是块大小整数倍，OpenSSL 会直接拒绝。出现这种情况通常是加密侧把原始密文截断了，或者用的 NoPadding 但明文没有对齐。我提供一个自查清单：

5.3 密钥和 IV 编码导致解密失败

命令行传-K是十六进制字符串，代码里如果是 C 数组，两者表示的是同一串字节。最容易出错的是把 ASCII 字符串直接当成密钥用，比如用"1234567890abcdef"当作 16 字节密钥，实际上这 16 个字符每个占 1 字节，不是想把"12"当成 0x12。两者密文完全不同。验证项目里我写了一个小工具函数，把 hex 字符串转成字节数组，确保命令行和代码用的是同一套字节流。

IV 也一样，CBC 模式 IV 必须和加密时保持一致。解密时 IV 错误不会直接报错，但解出来的明文前 16 字节会变成乱码，后面字节可能正常，这个特征非常典型，看到这种模式基本可以断定是 IV 匹配问题。

5.4 3DES_EEE 的正确打开方式

OpenSSL 高层 EVP 没有 3DES_EEE 的 cbc 实现，只能通过 DES 低级接口手动组合三次加密。下面这段是我验证 EEE-CBC 时用的核心逻辑：先按 CBC 规则把每个块和前一个密文块异或，然后对它连续做三次 DES 加密，也就是 K1 加密、K2 加密、K3 加密。

#include <openssl/des.h> DES_cblock key1, key2, key3; DES_key_schedule ks1, ks2, ks3; unsigned char block[8], prev[8], tmp1[8], tmp2[8]; int i; memset(prev, 0, 8); for (i = 0; i < len; i += 8) { /* CBC：当前明文块与前一密文块异或 */ for (int j = 0; j < 8; j++) block[j] = in[i + j] ^ prev[j]; /* 三次加密：K1 -> K2 -> K3 */ DES_ecb_encrypt((DES_cblock *)block, (DES_cblock *)tmp1, &ks1, DES_ENCRYPT); DES_ecb_encrypt((DES_cblock *)tmp1, (DES_cblock *)tmp2, &ks2, DES_ENCRYPT); DES_ecb_encrypt((DES_cblock *)tmp2, (DES_cblock *)out + i, &ks3, DES_ENCRYPT); memcpy(prev, out + i, 8); }

解密时颠倒顺序：K3 解密、K2 解密、K1 解密，同时 CBC 部分要把前一密文块取出来做异或。这里最容易出错的是临时变量复用，我第一次写的时候直接把out + i传给下一次DES_ecb_encrypt的输入，结果覆盖了还没用的数据。老老实实用三个临时缓冲区，就不会有这个问题。

另外要注意，DES_ecb_encrypt一次只能处理 8 字节，循环里的len必须保证是 8 的倍数。所以在调用这段代码之前，先用 PKCS#7 规则手动补好填充，或者提前保证明文对齐。我建议在项目里单独封装一个des3_eee_pad()类似函数，跟 OpenSSL 的填充解耦，这样调试起来更容易。

5.5 命令行无法直接验证 3DES_EEE 的替代方案

命令行没有des-eee3-cbc这种名称，但可以借助低级接口写出一个小工具，把 EEE-CBC 的加解密结果导出成文件，再用xxd对比。如果你想用命令行快速验证某个已知密文是不是 EEE，一个间接办法是先用手工写好的代码算出密文 hex，再在代码里断言memcmp(out, expected, len) == 0。这比硬找命令行参数更靠谱。

我个人在这个项目里把 EDE 和 EEE 各跑了一组向量，用同一份明文、同一个密钥，得到两份完全不同的密文，然后写进验证脚本，以后任何人改代码都能立刻发现是不是把结构弄混了。这一步看起来简单，但能防止后续联调时被“同样密钥为什么解不开”的问题折磨。

写在最后的实操体会

这套验证项目做下来，我最大的感受是：加解密算法本身不难，难的是参数语义的一致性。命令行、代码、硬件设备之间，任何一个环节对“密钥长度”“填充方式”“变换顺序”的理解出现偏差，结果就是对不上。所以我的建议是，每个算法都保留一份固定测试向量，包括密钥 hex、IV hex、明文、期望密文 hex，然后用命令行验证一次、代码验证一次，两边产出完全一致后再交给下游使用。另外，3DES_EEE 这种冷门模式，文档少、踩坑多，最好在代码注释里写清楚三次变换的顺序和 CBC 异或的位置，不然三个月后再看，自己都会懵。加解密验证不是一次性的活，参数表、测试向量、排查清单，都是这个项目最该沉淀下来的资产。