3DES源代码实战：从DES轮函数到CBC模式与PKCS7填充

简介：这是一套面向密码学初学者、计算机相关专业学生及安全开发者的3DES对称加密实现资源包，适用于课程设计、安全实验、算法原理讲解等场景。资源围绕3DES核心算法，提供可编译的C++源文件、可直接运行的exe程序，并配有多个txt示例文本，用于呈现加密前、加密中、解密后的文字内容，从而便于对照输入输出；同时附有解密后的doc文档，帮助完整验证加解密结果与算法正确性。压缩包共11个文件，除cpp源文件负责核心逻辑外，还包含cbp工程配置、layout布局、depend依赖说明等工程文件，方便在Code::Blocks环境中直接打开、编译与调试，整体仅84KB，结构紧凑、阅读成本低。当前已有173人学习浏览，覆盖从运行演示到源码研读的完整闭环。借助该资源，读者既能快速掌握3DES密钥生成、分组处理、加解密迭代等关键环节，也可基于示例数据自行修改测试，加深对对称加密算法工程实现的直观理解。 现在还在翻3DES源代码的人，多半不是图新鲜，而是被遗留系统、金融接口或者嵌入式环境逼的。我最近整理了一套带完整加解密文本的3DES源码，从底层DES轮函数到CBC模式调度、PKCS7填充、Base64输出全部都有，顺手把它做成了命令行工具，Linux和Windows上都能编译运行。这篇直接把实现思路、关键代码和踩过的坑写出来，给正在做老系统对接、嵌入式加密，或者纯粹想搞懂3DES的人参考。

3DES这个算法听着老，但现实里它还在大量服役。金融POS交易报文里的PIN加密、MAC计算，医保卡、社保卡的读写流程，甚至不少工业控制系统的固件升级包，都在用3DES。新项目当然推荐直接上AES，但当你碰上必须跟前端设备、旧服务端对齐的场景时，手里有一套能看懂、能改、能调试的3DES源码，比什么都有用。

1. 3DES源代码在真实项目中的价值定位

1.1 算法原理回顾：三次DES叠加出来的安全收益

3DES并不是新算法，它是在DES的基础上做了三次加解密操作。密钥长度可以是16字节或24字节，对应两个或三个独立子密钥。16字节密钥时，K1和K3相同；24字节密钥时，K1、K2、K3各自独立。加密过程是C = E_K1(D_K2(E_K3(P)))，先加密、再解密、再加密，这个结构称为EDE。这里的“中间解密”不是多余动作，它让3DES能向下兼容DES：当K1=K2=K3时，加密两次、解密一次，效果等同于DES本身。

从抗攻击角度看，3DES把有效安全强度从DES的56位提升到了大约112位。虽然密钥长度标称168位或112位，但由于中间相遇攻击的存在，实际安全强度只有112位左右。对比AES-128，3DES在性能上明显吃亏，一个分组要做16轮Feistel变换乘以3，速度大约是AES的三分之一以下。可为什么还用它？因为很多协议和接口在十几年前就定死了，报文格式、密钥管理体系全基于3DES改造，端到端迁移成本高到根本没人愿意动。

1.2 这份源代码的定位与适用场景

这套源代码是我按工程化思路整理的，不是那种只贴一个main函数的演示代码。整个工程包含：完整的DES核心实现（初始置换、16轮迭代、子密钥生成、S盒替换、逆置换）、3DES加解密封装、ECB和CBC两种分组模式、PKCS7填充逻辑，以及一个能直接操作的命令行入口。

适合谁用？第一类是嵌入式开发者，MCU上没有现成的加密库，或者芯片厂商提供的库是闭源的，需要自己把加密逻辑编进固件；第二类是做系统对接的工程师，对方只给了密钥和“3DES加密”几个字，所有细节都要自己试；第三类是安全或逆向方向的初学者，想弄明白这个经典分组密码内部到底怎么运转的。对于最后这类人，我建议把DES的S盒和置换表打印出来，对着数据一步一步走一遍，比看十篇文章都管用。

2. 源代码结构设计与实现思路

2.1 文件模块划分与关键数据结构

整个源码分成了几个独立文件，每个文件职责单一。des_core.c放DES算法本体，des3_mode.c处理ECB和CBC模式调度，pkcs7_padding.c专门做填充与去填充，main.c是命令行交互层。这样划分的好处是核心算法不依赖任何平台库，方便移植到RTOS或裸机环境。

对外统一暴露一个上下文结构体，把密钥、IV、分组模式都收进去：

#ifndef DES3_TOOL_H #define DES3_TOOL_H #include <stddef.h> #include <stdint.h> typedef enum { DES3_ECB = 0, DES3_CBC = 1 } des3_mode_t; typedef struct { uint8_t key[24]; uint8_t iv[8]; des3_mode_t mode; } des3_ctx_t; int des3_encrypt(des3_ctx_t *ctx, const uint8_t *in, size_t in_len, uint8_t *out, size_t *out_len, int base64_flag); int des3_decrypt(des3_ctx_t *ctx, const uint8_t *in, size_t in_len, uint8_t *out, size_t *out_len, int base64_flag); #endif

用结构体统一管理上下文的做法，在工程里很常见。它让加解密函数不需要传一堆参数，也避免用全局变量带来重入问题。多线程环境下，每个线程维护一个独立的des3_ctx_t实例，就能安全并行处理不同密钥的数据块。

2.2 为什么默认选CBC模式加PKCS7填充

ECB模式实现最简单，但存在一个致命弱点：相同的明文块必然产生相同的密文块。对文本加密来说，如果原文有重复的模式，密文会直接暴露这些规律，攻击者不需要解密就能看出结构。CBC模式通过把前一个密文块与当前明文块做异或，打散了这种规律，所以工程实现里我默认走CBC。

CBC加密的公式是C_n = E_K(P_n XOR C_{n-1})，第一块用IV参与异或，所以IV必须由加解密双方约定好。解密是对应的P_n = D_K(C_n) XOR C_{n-1}，这个过程要求密文必须是8字节的整数倍，因此明文最后一块不足8字节时就要填充。

PKCS7填充规则很简单：需要填充几个字节，就填几个相同值。明文差5字节满8字节，就补五个0x05；恰好是8字节的整数倍，也要补一个完整的块，每字节都是0x08。这样设计是为了让解密端能确定地知道哪里是填充尾部，同时不影响恰好对齐的明文还原。

2.3 密钥与IV的输入约定

3DES的密钥，我建议统一按24字节处理。如果外部只给了16字节密钥，就把前8字节复制一份作为K3，这是最常见的2TDES用法。密钥来源通常是一串Hex字符串，因为二进制密钥没法直接手抄或打印。源码里专门写了一个hex2bytes函数，把"0123456789ABCDEF..."这类字符串还原成字节数组，同时也处理了大小写字母混用的输入。

这里有个隐藏坑：明文和密钥的字符编码问题。密钥字符串必须按ASCII或UTF-8解析后再做Hex解码，不能直接强转成char数组，否则遇到非ASCII字符就会出现密钥错位。IV没有特殊要求时默认全0，但同一个密钥做CBC加密时，IV每次变更都会得到完全不同的密文，这是正常现象，不要以为是程序出错了。

3. 加解密核心流程的代码级解析

3.1 加密主流程：从明文到Base64的四步转换

加密功能走的是“读取文本 -> 转字节数组 -> PKCS7填充 -> 3DES-CBC加密 -> Base64编码 -> 输出文本”这条链路。先把明文按UTF-8转成字节流，统计出长度，然后做填充。填充函数会把长度对齐到8字节的整数倍，并返回填充后的总长度。

static size_t pkcs7_pad(uint8_t *buf, size_t len, size_t block_size) { size_t pad = block_size - (len % block_size); for (size_t i = 0; i < pad; i++) { buf[len + i] = (uint8_t)pad; } return len + pad; }

CBC模式的核心循环体是异或、加密、再异或。关键点在于每处理完一个8字节块，必须把该块的密文拷贝到prev缓冲区，作为下一轮异或的输入。这个步骤漏掉，整个密文序列就会全部错位。

static void xor_block(uint8_t *dst, const uint8_t *a, const uint8_t *b) { for (int i = 0; i < 8; i++) { dst[i] = a[i] ^ b[i]; } } int des3_cbc_encrypt(des3_ctx_t *ctx, const uint8_t *in, size_t in_len, uint8_t *out) { uint8_t block[8]; uint8_t prev[8]; memcpy(prev, ctx->iv, 8); for (size_t i = 0; i < in_len; i += 8) { xor_block(block, in + i, prev); des3_encrypt_block(ctx->key, block, out + i); memcpy(prev, out + i, 8); } return 0; }

加密完成后拿到的是一串二进制密文，直接打印到终端会显示成乱码，甚至可能把控制台搞坏。所以统一走Base64编码，转成可读文本。Base64会让数据膨胀约33%，但对文本传输场景完全可接受。

3.2 解密主流程与去填充校验

解密是加密的逆过程，但有个顺序陷阱：必须先做Base64解码，再按8字节块做3DES解密，最后才能去掉PKCS7填充。如果把顺序搞反，Base64解码会因为字节数不对直接报错。

解密循环体里，每个密文块先做DES逆变换，再与上一个密文块异或。第一个块用的是IV，必须与加密端完全一致，一个比特都不能差。IV不同会导致解出来的第一块完全是乱码，后续块因为CBC链式结构受损，也会全部受影响。

去填充是安全性要求很高的环节，必须校验填充值的合法性。填充值应该在1到8之间，而且末尾的所有填充字节都必须相等。只校验长度不校验内容，会留下填充预言攻击的风险，这在正规的安全审计里一查就出来。

static int pkcs7_unpad(const uint8_t *buf, size_t len, size_t block_size, size_t *out_len) { if (len == 0 || len % block_size != 0) { return -1; } uint8_t pad = buf[len - 1]; if (pad == 0 || pad > block_size) { return -1; } for (size_t i = len - pad; i < len; i++) { if (buf[i] != pad) { return -1; } } *out_len = len - pad; return 0; }

3.3 文本编码与Base64输出的坑

这套源码默认明文按UTF-8处理，这是当前最通用的选择。但碰到中文环境时要格外留意：同样一句中文，UTF-8编码下占3字节，GBK编码下占2字节。如果加密端用UTF-8，解密端用GBK，两边拿到的字节流根本不同，密文必然对不上。这不是算法问题，是编码约定问题。

我在实际项目里遇到过几次这种糟心事，特征是两边密钥、模式、IV全都对，解密出来就是乱码。最后排查半天，发现是服务端Java默认用的UTF-8，客户端C++老代码用的GBK。解决方式是在密钥协商文档里明确约定：所有参与加密的字符串统一转UTF-8后再处理。

Base64这块也有一个细节：有些加密库输出的Base64默认带换行，每76个字符插一个回车换行。如果直接用字符串比较或做参数传递，换行符会被带进去，导致解密端解码失败。我这里统一输出不带换行的标准Base64，并在文档里标注清楚，避免联调时踩坑。

4. 联调过程中的高频问题与排查实录

4.1 A系统加密B系统解不开

这是被问得最多的问题。两边密钥看着一样、算法都叫3DES，但结果就是解不开。我一般按顺序排查：先核对密钥到底是多少字节，是否按同样的方式做了Hex解码；再看分组模式是ECB还是CBC；然后确认IV值是否一致；最后看填充方式。四个环节里，密钥和填充出问题的概率最高。

给个真实例子：某系统对接文档里写“密钥为32位Hex字符串”，客户端直接把字符串每个字符的ASCII码当成密钥字节用了，服务端却做了Hex解码。两边算出来的实际密钥完全不同，自然加解密失败。碰到这种问题，第一步永远是在两侧打印同一段明文加密后的Base64结果，一对比就能看出差异。

4.2 CBC模式解密串位与IV错误

CBC解密的一个特点是：如果某一块密文在传输中被破坏，只影响当前块和下一块的解密结果，再往后的块不受影响。这个特性在排查时很有用。如果解出来的明文只有开头几字节是乱码，后面都正常，基本可以认定IV不一致。如果所有内容都是乱码，优先怀疑密钥或模式。

另一个容易被忽略的情况是密文在传输过程中混入了空格或换行。Base64本来没有空格，但有些日志系统会自动对长行断行，复制的时候就可能混入看不见的换行符。拿到密文后先做一次去空白处理，能省很多排查时间。

4.3 内存越界与填充残留

C语言实现3DES，内存越界是最常见的崩溃源。加密前需要先计算填充后的长度，然后确保输出缓冲区至少能装下这么多字节。很多人在调用加密函数时分配了输入等长的缓冲区，结果正好8字节对齐的明文经过PKCS7填充后会多出一个块，直接踩坏了栈。

我习惯在代码里保留一个SAFE_OUT_LEN宏，统一按“输入长度加16字节”分配缓冲，宁可多分配，不要不够用。解密端同样要注意，因为PKCS7去填充后明文会短于密文长度，输出缓冲区按密文长度分配即可，但返回值必须使用去填充后的实际长度。

4.4 自测用例：一套快速验证的对照表

我把自己常用的验证用例整理成了表格，每份源码到手先按这个跑一遍，能过就说明核心链路基本没毛病。第一组用固定密钥加固定IV测试标准向量，第二组验证填充边界，第三组验证中文字符编码。

建议把这组用例编成自动化测试脚本，每次改动源码后跑一遍。我见过不少项目因为改了一个子密钥生成逻辑，导致所有密文无法与旧系统互通，正是没做回归测试的后果。

4.5 几个值得注意的弱密钥问题

DES和3DES都存在弱密钥，表现为子密钥在16轮迭代中重复出现，加密两次就回到原文。全0、全1、以及0x0101010101010101这类特殊密钥都属于弱密钥范围。虽然现代应用中遇到巧合弱密钥的概率极低，但在金融安全审计中，“是否检测并拒绝弱密钥”会被当作一项检查点。

我在源码里加了一个弱密钥检查函数，密钥加载时扫一遍，命中就直接报错退出。看似多此一举，但在对接合规要求严格的项目时，这一点能为后面的测试验收省不少口舌。

5. 顺着这套代码继续扩展的方向

3DES这套源码改起来非常灵活，想往其他方向扩展也很方便。把des3_encrypt_block和des3_decrypt_block这两个底层函数换成AES或SM4的实现，上层模式调度和填充逻辑几乎不用动。这也是我坚持把代码分层的原因，分组加密的模式层和核心算法层本来就是正交的两件事。

如果你只是对接一个临时接口，用OpenSSL或者各语言加密库都能搞定，不必重复造轮子。但如果你需要静态编译到嵌入式固件、需要通过FIPS风格安全审计、或者想在老设备上实现标准加密协议，手里的这套完整可读的源代码就是最大的底牌。我在实际部署中还发现一个实用技巧：把命令行工具编译成静态链接版本，扔到内网服务器上不依赖任何动态库，排查问题的时候直接在服务器上一行命令就能验证密文，比写单元测试快得多。

这份代码的后续维护也很简单，核心的DES表项全部静态声明，不占堆内存，跑在STM32F103这种只有64KB RAM的芯片上也没有压力。如果你正在被某个老系统的3DES联调折磨，可以考虑把我这种“分层实现+命令行验证+回归测试列表”的方式复制过去，效率会高很多。

本文还有配套的精品资源，点击获取