简介这份资源面向计算机专业学生与Windows平台C开发者提供基于MFC框架实现AES加解密功能的完整工程实例帮助读者在掌握AES算法原理的同时学会将加密能力落地到实际桌面应用中。压缩包共39个文件、约4.13MB以h头文件与cpp源文件为核心配合rc资源脚本、ico图标、dsp/dsw工程文件及exe可执行程序另附测试数据、密钥、明文与加密要求输出结果等txt文档便于直接编译运行与对照验证。资源已有433人学习下载内容覆盖AES分组加密原理、密钥扩展、状态矩阵与S盒变换、字节操作以及ECB、CBC等加密模式与PKCS#7填充的选型思路并涉及Crypto或CNG接口封装、错误处理与AES-NI性能优化等实践要点。读者可据此获得一套可复用的MFC加解密代码骨架与测试向量用于课程设计、项目开发或算法学习中的动手实践。1. 一个对话框背后的加密引擎AES 加解密在 MFC 里到底怎么落地接手一个老项目的维护任务时最常遇到的场景是界面上就两个按钮、一个输入框、一个输出框点一下“加密”字符串变了再点“解密”又变回来。看着简单但真正要把它做稳密钥长度、分组模式、填充方式、字符编码这四件事只要有一件没对齐加出来就是乱码解出来就是空串。这份 AES 加解密算法实现MFC资源做的就是把这套逻辑封装进一个 Windows 桌面程序里用 MFC 的对话框框架承载交互底层跑标准 AES 分组密码。它适合两类人一类是想搞懂对称加密在 C 工程里怎么组织的新手另一类是需要在 MFC 老系统里补一个加解密模块的熟手。下面按“能干什么、怎么跑、怎么改”的顺序拆开讲。2. 工程结构与技术选型MFC 对话框 AES 核心的分层设计2.1 为什么用 MFC 承载加解密界面MFC 是微软那套基于 C 的窗口框架虽然年头久但在大量存量 Windows 工具、工业上位机、内部管理软件里仍然是主力。选它做加解密 Demo 的理由很实际对话框资源用可视化编辑器拖控件消息映射用ON_BN_CLICKED一行宏就能把按钮和函数绑上不需要引入 Qt 那种额外的运行时依赖编译出来就是一个能双击运行的 exe。对于“输入明文、选密钥、点按钮、看密文”这种交互密度极低的工具MFC 的笨重反而是优点——没有事件循环的复杂度没有跨平台抽象层代码路径短出问题好定位。需要提前说清楚的是MFC 本身不提供加密能力。它只负责窗口、控件、消息。真正的 AES 运算要么调用 Windows 自带的 CryptoAPICryptAcquireContext/CryptEncrypt那一套要么自己实现或引入一份 AES 核心源码。这份资源走的是后者把 AES 的轮函数、密钥扩展、S 盒变换写成独立的 C 类和界面层解耦。这样做的直接好处是核心算法可以单独拿出去做单元测试也可以在没有窗口环境的命令行里跑不被 MFC 的消息泵绑死。2.2 目录结构长什么样一个典型的 MFC AES 工程文件组织大致如下。不同人建工程时命名会有差异但分层逻辑基本一致AesMfcDemo/ ├── AesMfcDemo.sln # 解决方案文件 ├── AesMfcDemo/ │ ├── AesMfcDemo.h/.cpp # 应用类InitInstance 里创建主对话框 │ ├── AesDlg.h/.cpp # 主对话框类按钮消息处理都在这里 │ ├── AesDlg.rc # 对话框资源控件布局 │ ├── resource.h # 控件 ID 定义 │ ├── AES.h/.cpp # AES 核心密钥扩展、加解密轮函数 │ ├── Base64.h/.cpp # 密文转 Base64方便显示和传输 │ └── stdafx.h # 预编译头 └── ...这个结构里最关键的一条边界是AesDlg.cpp和AES.cpp之间。对话框类只负责三件事从控件读字符串、调用 AES 接口、把结果写回控件。它不应该知道 S 盒长什么样也不应该关心轮数。AES 类只负责字节数组进、字节数组出不碰CString不碰控件句柄。这条边界守住了后面换界面框架或者换加密库都只是局部改动。2.3 核心接口设计AES 类的公开接口通常收敛成两个函数参数用std::vectorunsigned char或裸指针加长度。下面是一个常见的声明形态// AES.h class CAES { public: // key: 16/24/32 字节分别对应 AES-128/192/256 // input: 明文或密文字节 // output: 结果字节长度按 PKCS7 填充后为 16 的整数倍 static bool Encrypt(const std::vectorunsigned char key, const std::vectorunsigned char input, std::vectorunsigned char output); static bool Decrypt(const std::vectorunsigned char key, const std::vectorunsigned char input, std::vectorunsigned char output); private: static void KeyExpansion(const unsigned char* key, int keyLen, unsigned char* roundKey); static void Cipher(const unsigned char* in, unsigned char* out, const unsigned char* roundKey); static void InvCipher(const unsigned char* in, unsigned char* out, const unsigned char* roundKey); };key的长度决定走哪条分支16 字节走 10 轮24 字节走 12 轮32 字节走 14 轮。input在加密前要先做 PKCS7 填充把长度补齐到 16 的倍数解密后要去掉填充。这两个动作放在Encrypt/Decrypt内部做调用方不用操心。返回值用bool而不是抛异常是因为 MFC 老工程里异常处理链经常不完整用返回值判断更稳。提示密钥长度必须严格校验。传进来 15 字节或 17 字节时直接返回 false不要“自动补齐”补齐规则一旦隐式化调用方就再也对不上了。3. 从明文到密文的完整链路填充、分组、编码三步走3.1 PKCS7 填充与去填充AES 是分组密码分组固定 16 字节。明文长度不是 16 的倍数时必须填充。PKCS7 的规则很直白缺 n 个字节就补 n 个值为 n 的字节如果明文刚好是 16 的倍数也要额外补一整组 16 个 0x10。这条“刚好整除也要补”的规则是新手最容易漏的漏了之后解密端无法区分“末尾的 0x10 是数据还是填充”。// 加密前填充 static void PKCS7Pad(std::vectorunsigned char data) { int padLen 16 - (data.size() % 16); // 1..16整除时为 16 data.insert(data.end(), padLen, (unsigned char)padLen); } // 解密后去填充 static bool PKCS7Unpad(std::vectorunsigned char data) { if (data.empty() || data.size() % 16 ! 0) return false; unsigned char padLen data.back(); if (padLen 0 || padLen 16) return false; // 非法填充值 if (padLen data.size()) return false; for (int i 0; i padLen; i) { // 校验每个填充字节 if (data[data.size() - 1 - i] ! padLen) return false; } data.resize(data.size() - padLen); return true; }PKCS7Pad里padLen的取值范围是 1 到 16data.size() % 16 0时算出 16正好补一整组。PKCS7Unpad做了三重校验填充值范围、填充长度不超过数据长度、每个填充字节都等于填充值。第三重校验不能省否则攻击者篡改密文末尾时解密端可能静默返回错误数据而不是报错。这种“填充预言”类的攻击在真实系统里出过事工具类程序虽然风险低但校验习惯要养好。3.2 分组加密主循环填充完成后数据按 16 字节一组切分逐组调用Cipher。这里用的是 ECB 模式——每组独立加密相同明文组产生相同密文组。ECB 的缺点很明确它不隐藏明文的重复模式同一段文字加密两次结果完全一样。对于“演示 AES 怎么算”这个目标ECB 足够但如果要加密真实业务数据应该换成 CBC 并引入随机 IV。这一点在改造章节会展开。bool CAES::Encrypt(const std::vectorunsigned char key, const std::vectorunsigned char input, std::vectorunsigned char output) { if (key.size() ! 16 key.size() ! 24 key.size() ! 32) return false; unsigned char roundKey[240]; // 最大 14 轮 1每轮 16 字节 KeyExpansion(key.data(), (int)key.size(), roundKey); std::vectorunsigned char buf input; PKCS7Pad(buf); output.resize(buf.size()); for (size_t off 0; off buf.size(); off 16) { Cipher(buf.data() off, output.data() off, roundKey); } return true; }roundKey开 240 字节是 AES-256 的上限15 组轮密钥 × 16 字节。KeyExpansion根据keyLen决定扩展出多少组。主循环用off做偏移每次前进 16 字节Cipher内部只处理一个分组不关心总长度。这种“外层管分组、内层管单组”的写法比把所有逻辑塞进一个函数里好调试得多——单组加密出错时可以单独拿一组 16 字节的测试向量去对。3.3 密文的 Base64 编码与界面回显AES 输出的是二进制字节直接往CString里塞会遇到 0x00 截断和不可打印字符。所以界面层在拿到密文后先做 Base64 编码再显示。解密时反过来先把 Base64 字符串解码成字节再送进Decrypt。void CAesDlg::OnBnClickedBtnEncrypt() { CString strPlain, strKey; GetDlgItemText(IDC_EDIT_PLAIN, strPlain); GetDlgItemText(IDC_EDIT_KEY, strKey); // CString 转 UTF-8 字节避免中文按 ANSI 截断 int len WideCharToMultiByte(CP_UTF8, 0, strPlain, -1, NULL, 0, NULL, NULL); std::vectorunsigned char plain(len - 1); WideCharToMultiByte(CP_UTF8, 0, strPlain, -1, (char*)plain.data(), len, NULL, NULL); std::vectorunsigned char key((unsigned char*)strKey.GetBuffer(), (unsigned char*)strKey.GetBuffer() strKey.GetLength()); strKey.ReleaseBuffer(); std::vectorunsigned char cipher; if (!CAES::Encrypt(key, plain, cipher)) { AfxMessageBox(_T(密钥长度必须为 16/24/32 字节)); return; } CString strB64 Base64Encode(cipher).c_str(); SetDlgItemText(IDC_EDIT_CIPHER, strB64); }这段代码里有两个容易翻车的点。第一是CString到字节数组的转换MFC 工程默认可能是 Unicode 字符集CString存的是wchar_t直接GetBuffer()强转成unsigned char*会把宽字符的低字节当数据中文必然乱。正确做法是先WideCharToMultiByte(CP_UTF8, ...)转成 UTF-8 字节。第二是密钥的读取密钥框里输入的通常是 ASCII 可见字符按字节取没问题但如果用户输入了中文当密钥同样要走 UTF-8 转换并且转换后长度可能不是 16/24/32需要提示用户。注意WideCharToMultiByte的len包含结尾的\0所以plain开len - 1大小转换时目标缓冲区大小传len但只取前len - 1字节。这个差一错误在调试时表现为“密文末尾多一个字节”很难一眼看出来。4. 编译运行与调试把 exe 跑起来并验证结果4.1 环境准备与工程配置这份工程依赖 Visual Studio 的 MFC 组件。安装 VS 时如果只勾了“使用 C 的桌面开发”而没勾“MFC 和 ATL 支持”打开工程会报afxwin.h找不到。补装的方法是在 Visual Studio Installer 里点“修改”在单个组件里搜 MFC 勾上。工程属性里有两处要确认字符集设为“使用 Unicode 字符集”和上面的WideCharToMultiByte逻辑对应运行库按需选/MD或/MT如果要把 exe 拷到没装 VC 运行库的机器上选/MT静态链接更省事。编译时如果报LNK2019 unresolved external symbol先看是不是AES.cpp没加入工程——从别处拷文件进来但忘了在解决方案资源管理器里“添加现有项”是高频失误。另外Base64.cpp如果用了std::string而工程里没包含string也会在链接期或编译期报错检查预编译头里有没有漏。4.2 用标准测试向量验证正确性程序能跑起来不等于算对了。验证 AES 实现是否正确最可靠的办法是拿 NIST 公布的标准测试向量对一遍。AES-128 的一组经典向量是密钥000102030405060708090a0b0c0d0e0f明文00112233445566778899aabbccddeeff密文应为69c4e0d86a7b0430d8cdb78070b4c55a。在工程里临时加一个测试函数把十六进制字符串转成字节数组喂给Cipher比对输出。void RunSelfTest() { unsigned char key[16] {0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07, 0x08,0x09,0x0a,0x0b,0x0c,0x0d,0x0e,0x0f}; unsigned char plain[16] {0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77, 0x88,0x99,0xaa,0xbb,0xcc,0xdd,0xee,0xff}; unsigned char expect[16] {0x69,0xc4,0xe0,0xd8,0x6a,0x7b,0x04,0x30, 0xd8,0xcd,0xb7,0x80,0x70,0xb4,0xc5,0x5a}; unsigned char roundKey[240], out[16]; CAES::KeyExpansion(key, 16, roundKey); CAES::Cipher(plain, out, roundKey); // 逐字节比对 out 与 expect }如果这组对不上问题一定在KeyExpansion或Cipher内部和界面、编码、填充都无关。常见错因有三个S 盒表抄错一个值、列混合的 GF(2^8) 乘法写错、轮密钥异或的轮次偏移差一。用测试向量定位比在界面上反复点按钮快得多因为界面层还叠着编码转换变量太多。4.3 界面联调时的观察点界面跑通后按这个顺序验证先输入纯 ASCII 短串比如hello密钥用 16 个字符加密看密文是否为合法 Base64再解密看是否还原成hello然后输入中文确认 UTF-8 转换没丢字节最后输入长度刚好 16 的倍数的明文确认填充逻辑补了整组。每一步失败对应的排查方向不同ASCII 短串失败多半是算法本身中文失败多半是编码转换整倍数长度失败多半是填充规则。把这几步做成固定的自测清单比每次凭感觉点要靠谱。5. 避坑与常见问题那些让密文对不上的细节5.1 加密解密结果不一致现象是同一段明文、同一个密钥加密后再解密得到的字符串末尾多出几个乱码字符或者干脆解不出来。原因通常出在填充上加密端补了 PKCS7解密端没去填充或者去填充时没校验填充值直接按最后一个字节截断。解决方法是确认Decrypt内部调用了PKCS7Unpad并且PKCS7Unpad的校验逻辑完整。另一个可能是密钥在两次调用间被改了——比如界面上密钥框被用户误编辑加密时用 A 密钥、解密时用 B 密钥这种情况加个密钥回显或校验提示就能避免。5.2 中文加密后解密变问号现象是英文正常中文加密再解密后变成???或乱码。原因是CString在 Unicode 工程里是宽字符直接按字节取会把每个汉字拆成两个不完整的字节。解决方法是统一走 UTF-8加密前WideCharToMultiByte(CP_UTF8, ...)解密后MultiByteToWideChar(CP_UTF8, ...)转回CString。注意两次转换的代码页必须一致一边 UTF-8 一边 ANSI 是另一个高频错误。5.3 密文里出现换行或截断现象是 Base64 密文显示到编辑框里中间断了或者末尾少了字符。原因是 Base64 编码后如果按固定列宽插入了换行符有些实现默认 76 列换行而编辑框是单行或者解码端没处理换行就会错位。解决方法是在Base64Encode里关掉换行输出或者在解码前先过滤掉\r\n。另外编辑框如果设了ES_MULTILINE但没设滚动条长密文会显示不全看起来像截断实际数据是完整的读的时候用GetWindowTextLength确认长度。5.4 换台机器就编译不过现象是在自己机器上能编译拷到同事机器上报fatal error C1083: 无法打开包括文件: afxwin.h。原因是对方 VS 没装 MFC 组件。解决方法是让对方在 Visual Studio Installer 里补装“MFC 和 ATL 支持”或者把工程改成不依赖 MFC 的 Win32 程序工作量大不推荐。还有一种情况是平台工具集版本不一致工程属性里“平台工具集”要选对方装了的版本比如v143对应 VS2022v142对应 VS2019。5.5 密钥长度传错导致静默失败现象是点了加密没反应也没弹提示。原因是Encrypt返回了 false但界面代码没检查返回值直接拿空的output去编码得到空串写回控件。解决方法是在每个调用点都判断返回值失败时AfxMessageBox给出具体原因密钥长度不对、输入为空等。这类静默失败在调试期最耗时间因为界面上什么线索都没有只能靠断点。6. 二次开发改造从 ECB 演示到可用的加密模块如果要把这个 Demo 往真实项目里用第一件该改的事是把 ECB 换成 CBC 模式。ECB 下相同明文块产生相同密文块加密一段有重复结构的文本时密文里能看出模式安全性不够。CBC 的做法是引入一个 16 字节的随机 IV第一组明文先和 IV 异或再加密后续每组和前一组密文异或。IV 不需要保密但要随密文一起存或传解密端拿它做反向操作。改造点在Encrypt的主循环里加一个prevBlock缓冲Decrypt里对应加反向异或接口上多传一个 IV 参数。// CBC 加密主循环示意 std::vectorunsigned char iv(16); // 调用方用随机源填充 std::vectorunsigned char prev iv; for (size_t off 0; off buf.size(); off 16) { for (int i 0; i 16; i) buf[off i] ^ prev[i]; // 与前一密文块异或 Cipher(buf.data() off, output.data() off, roundKey); prev.assign(output.begin() off, output.begin() off 16); }第二件该改的是密钥管理。Demo 里密钥从编辑框读真实系统里密钥不能硬编码在源码里也不该让用户手输。常见做法是从配置文件或系统凭据存储读取程序启动时加载到内存用完及时清零SecureZeroMemory。如果要做多用户每个用户一个密钥密钥本身用主密钥加密后存库这是另一层设计但至少别把明文密钥写进const char*常量里——反编译一眼就能看到。第三件是错误处理的粒度。现在Encrypt只返回 bool调用方不知道是密钥长度错还是输入为空。可以改成返回一个枚举错误码界面层根据码值给不同提示。这个改动不大但对后续排查帮助明显。验证改造是否成功除了跑标准测试向量还要加一组 CBC 的向量NIST SP 800-38A 里有现成的以及一组“篡改密文后解密应失败”的负向测试——CBC 下篡改中间某组密文解密后该组和下一组都会乱配合填充校验能检测出来。我自己的习惯是每次动加密相关代码不管改动多小都先把那几组标准向量跑一遍再提交。有一次图省事跳过了结果一个 S 盒的索引写反界面上短字符串看着正常长文本解密到中间才崩排查花了半天。从那以后测试向量这一步我强制走一遍不给自己留后悔药。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/4 9:15:37 · 阅读 1.2k AES加解密在MFC中的实现与避坑指南
简介这份资源面向计算机专业学生与Windows平台C开发者提供基于MFC框架实现AES加解密功能的完整工程实例帮助读者在掌握AES算法原理的同时学会将加密能力落地到实际桌面应用中。压缩包共39个文件、约4.13MB以h头文件与cpp源文件为核心配合rc资源脚本、ico图标、dsp/dsw工程文件及exe可执行程序另附测试数据、密钥、明文与加密要求输出结果等txt文档便于直接编译运行与对照验证。资源已有433人学习下载内容覆盖AES分组加密原理、密钥扩展、状态矩阵与S盒变换、字节操作以及ECB、CBC等加密模式与PKCS#7填充的选型思路并涉及Crypto或CNG接口封装、错误处理与AES-NI性能优化等实践要点。读者可据此获得一套可复用的MFC加解密代码骨架与测试向量用于课程设计、项目开发或算法学习中的动手实践。1. 一个对话框背后的加密引擎AES 加解密在 MFC 里到底怎么落地接手一个老项目的维护任务时最常遇到的场景是界面上就两个按钮、一个输入框、一个输出框点一下“加密”字符串变了再点“解密”又变回来。看着简单但真正要把它做稳密钥长度、分组模式、填充方式、字符编码这四件事只要有一件没对齐加出来就是乱码解出来就是空串。这份 AES 加解密算法实现MFC资源做的就是把这套逻辑封装进一个 Windows 桌面程序里用 MFC 的对话框框架承载交互底层跑标准 AES 分组密码。它适合两类人一类是想搞懂对称加密在 C 工程里怎么组织的新手另一类是需要在 MFC 老系统里补一个加解密模块的熟手。下面按“能干什么、怎么跑、怎么改”的顺序拆开讲。2. 工程结构与技术选型MFC 对话框 AES 核心的分层设计2.1 为什么用 MFC 承载加解密界面MFC 是微软那套基于 C 的窗口框架虽然年头久但在大量存量 Windows 工具、工业上位机、内部管理软件里仍然是主力。选它做加解密 Demo 的理由很实际对话框资源用可视化编辑器拖控件消息映射用ON_BN_CLICKED一行宏就能把按钮和函数绑上不需要引入 Qt 那种额外的运行时依赖编译出来就是一个能双击运行的 exe。对于“输入明文、选密钥、点按钮、看密文”这种交互密度极低的工具MFC 的笨重反而是优点——没有事件循环的复杂度没有跨平台抽象层代码路径短出问题好定位。需要提前说清楚的是MFC 本身不提供加密能力。它只负责窗口、控件、消息。真正的 AES 运算要么调用 Windows 自带的 CryptoAPICryptAcquireContext/CryptEncrypt那一套要么自己实现或引入一份 AES 核心源码。这份资源走的是后者把 AES 的轮函数、密钥扩展、S 盒变换写成独立的 C 类和界面层解耦。这样做的直接好处是核心算法可以单独拿出去做单元测试也可以在没有窗口环境的命令行里跑不被 MFC 的消息泵绑死。2.2 目录结构长什么样一个典型的 MFC AES 工程文件组织大致如下。不同人建工程时命名会有差异但分层逻辑基本一致AesMfcDemo/ ├── AesMfcDemo.sln # 解决方案文件 ├── AesMfcDemo/ │ ├── AesMfcDemo.h/.cpp # 应用类InitInstance 里创建主对话框 │ ├── AesDlg.h/.cpp # 主对话框类按钮消息处理都在这里 │ ├── AesDlg.rc # 对话框资源控件布局 │ ├── resource.h # 控件 ID 定义 │ ├── AES.h/.cpp # AES 核心密钥扩展、加解密轮函数 │ ├── Base64.h/.cpp # 密文转 Base64方便显示和传输 │ └── stdafx.h # 预编译头 └── ...这个结构里最关键的一条边界是AesDlg.cpp和AES.cpp之间。对话框类只负责三件事从控件读字符串、调用 AES 接口、把结果写回控件。它不应该知道 S 盒长什么样也不应该关心轮数。AES 类只负责字节数组进、字节数组出不碰CString不碰控件句柄。这条边界守住了后面换界面框架或者换加密库都只是局部改动。2.3 核心接口设计AES 类的公开接口通常收敛成两个函数参数用std::vectorunsigned char或裸指针加长度。下面是一个常见的声明形态// AES.h class CAES { public: // key: 16/24/32 字节分别对应 AES-128/192/256 // input: 明文或密文字节 // output: 结果字节长度按 PKCS7 填充后为 16 的整数倍 static bool Encrypt(const std::vectorunsigned char key, const std::vectorunsigned char input, std::vectorunsigned char output); static bool Decrypt(const std::vectorunsigned char key, const std::vectorunsigned char input, std::vectorunsigned char output); private: static void KeyExpansion(const unsigned char* key, int keyLen, unsigned char* roundKey); static void Cipher(const unsigned char* in, unsigned char* out, const unsigned char* roundKey); static void InvCipher(const unsigned char* in, unsigned char* out, const unsigned char* roundKey); };key的长度决定走哪条分支16 字节走 10 轮24 字节走 12 轮32 字节走 14 轮。input在加密前要先做 PKCS7 填充把长度补齐到 16 的倍数解密后要去掉填充。这两个动作放在Encrypt/Decrypt内部做调用方不用操心。返回值用bool而不是抛异常是因为 MFC 老工程里异常处理链经常不完整用返回值判断更稳。提示密钥长度必须严格校验。传进来 15 字节或 17 字节时直接返回 false不要“自动补齐”补齐规则一旦隐式化调用方就再也对不上了。3. 从明文到密文的完整链路填充、分组、编码三步走3.1 PKCS7 填充与去填充AES 是分组密码分组固定 16 字节。明文长度不是 16 的倍数时必须填充。PKCS7 的规则很直白缺 n 个字节就补 n 个值为 n 的字节如果明文刚好是 16 的倍数也要额外补一整组 16 个 0x10。这条“刚好整除也要补”的规则是新手最容易漏的漏了之后解密端无法区分“末尾的 0x10 是数据还是填充”。// 加密前填充 static void PKCS7Pad(std::vectorunsigned char data) { int padLen 16 - (data.size() % 16); // 1..16整除时为 16 data.insert(data.end(), padLen, (unsigned char)padLen); } // 解密后去填充 static bool PKCS7Unpad(std::vectorunsigned char data) { if (data.empty() || data.size() % 16 ! 0) return false; unsigned char padLen data.back(); if (padLen 0 || padLen 16) return false; // 非法填充值 if (padLen data.size()) return false; for (int i 0; i padLen; i) { // 校验每个填充字节 if (data[data.size() - 1 - i] ! padLen) return false; } data.resize(data.size() - padLen); return true; }PKCS7Pad里padLen的取值范围是 1 到 16data.size() % 16 0时算出 16正好补一整组。PKCS7Unpad做了三重校验填充值范围、填充长度不超过数据长度、每个填充字节都等于填充值。第三重校验不能省否则攻击者篡改密文末尾时解密端可能静默返回错误数据而不是报错。这种“填充预言”类的攻击在真实系统里出过事工具类程序虽然风险低但校验习惯要养好。3.2 分组加密主循环填充完成后数据按 16 字节一组切分逐组调用Cipher。这里用的是 ECB 模式——每组独立加密相同明文组产生相同密文组。ECB 的缺点很明确它不隐藏明文的重复模式同一段文字加密两次结果完全一样。对于“演示 AES 怎么算”这个目标ECB 足够但如果要加密真实业务数据应该换成 CBC 并引入随机 IV。这一点在改造章节会展开。bool CAES::Encrypt(const std::vectorunsigned char key, const std::vectorunsigned char input, std::vectorunsigned char output) { if (key.size() ! 16 key.size() ! 24 key.size() ! 32) return false; unsigned char roundKey[240]; // 最大 14 轮 1每轮 16 字节 KeyExpansion(key.data(), (int)key.size(), roundKey); std::vectorunsigned char buf input; PKCS7Pad(buf); output.resize(buf.size()); for (size_t off 0; off buf.size(); off 16) { Cipher(buf.data() off, output.data() off, roundKey); } return true; }roundKey开 240 字节是 AES-256 的上限15 组轮密钥 × 16 字节。KeyExpansion根据keyLen决定扩展出多少组。主循环用off做偏移每次前进 16 字节Cipher内部只处理一个分组不关心总长度。这种“外层管分组、内层管单组”的写法比把所有逻辑塞进一个函数里好调试得多——单组加密出错时可以单独拿一组 16 字节的测试向量去对。3.3 密文的 Base64 编码与界面回显AES 输出的是二进制字节直接往CString里塞会遇到 0x00 截断和不可打印字符。所以界面层在拿到密文后先做 Base64 编码再显示。解密时反过来先把 Base64 字符串解码成字节再送进Decrypt。void CAesDlg::OnBnClickedBtnEncrypt() { CString strPlain, strKey; GetDlgItemText(IDC_EDIT_PLAIN, strPlain); GetDlgItemText(IDC_EDIT_KEY, strKey); // CString 转 UTF-8 字节避免中文按 ANSI 截断 int len WideCharToMultiByte(CP_UTF8, 0, strPlain, -1, NULL, 0, NULL, NULL); std::vectorunsigned char plain(len - 1); WideCharToMultiByte(CP_UTF8, 0, strPlain, -1, (char*)plain.data(), len, NULL, NULL); std::vectorunsigned char key((unsigned char*)strKey.GetBuffer(), (unsigned char*)strKey.GetBuffer() strKey.GetLength()); strKey.ReleaseBuffer(); std::vectorunsigned char cipher; if (!CAES::Encrypt(key, plain, cipher)) { AfxMessageBox(_T(密钥长度必须为 16/24/32 字节)); return; } CString strB64 Base64Encode(cipher).c_str(); SetDlgItemText(IDC_EDIT_CIPHER, strB64); }这段代码里有两个容易翻车的点。第一是CString到字节数组的转换MFC 工程默认可能是 Unicode 字符集CString存的是wchar_t直接GetBuffer()强转成unsigned char*会把宽字符的低字节当数据中文必然乱。正确做法是先WideCharToMultiByte(CP_UTF8, ...)转成 UTF-8 字节。第二是密钥的读取密钥框里输入的通常是 ASCII 可见字符按字节取没问题但如果用户输入了中文当密钥同样要走 UTF-8 转换并且转换后长度可能不是 16/24/32需要提示用户。注意WideCharToMultiByte的len包含结尾的\0所以plain开len - 1大小转换时目标缓冲区大小传len但只取前len - 1字节。这个差一错误在调试时表现为“密文末尾多一个字节”很难一眼看出来。4. 编译运行与调试把 exe 跑起来并验证结果4.1 环境准备与工程配置这份工程依赖 Visual Studio 的 MFC 组件。安装 VS 时如果只勾了“使用 C 的桌面开发”而没勾“MFC 和 ATL 支持”打开工程会报afxwin.h找不到。补装的方法是在 Visual Studio Installer 里点“修改”在单个组件里搜 MFC 勾上。工程属性里有两处要确认字符集设为“使用 Unicode 字符集”和上面的WideCharToMultiByte逻辑对应运行库按需选/MD或/MT如果要把 exe 拷到没装 VC 运行库的机器上选/MT静态链接更省事。编译时如果报LNK2019 unresolved external symbol先看是不是AES.cpp没加入工程——从别处拷文件进来但忘了在解决方案资源管理器里“添加现有项”是高频失误。另外Base64.cpp如果用了std::string而工程里没包含string也会在链接期或编译期报错检查预编译头里有没有漏。4.2 用标准测试向量验证正确性程序能跑起来不等于算对了。验证 AES 实现是否正确最可靠的办法是拿 NIST 公布的标准测试向量对一遍。AES-128 的一组经典向量是密钥000102030405060708090a0b0c0d0e0f明文00112233445566778899aabbccddeeff密文应为69c4e0d86a7b0430d8cdb78070b4c55a。在工程里临时加一个测试函数把十六进制字符串转成字节数组喂给Cipher比对输出。void RunSelfTest() { unsigned char key[16] {0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07, 0x08,0x09,0x0a,0x0b,0x0c,0x0d,0x0e,0x0f}; unsigned char plain[16] {0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77, 0x88,0x99,0xaa,0xbb,0xcc,0xdd,0xee,0xff}; unsigned char expect[16] {0x69,0xc4,0xe0,0xd8,0x6a,0x7b,0x04,0x30, 0xd8,0xcd,0xb7,0x80,0x70,0xb4,0xc5,0x5a}; unsigned char roundKey[240], out[16]; CAES::KeyExpansion(key, 16, roundKey); CAES::Cipher(plain, out, roundKey); // 逐字节比对 out 与 expect }如果这组对不上问题一定在KeyExpansion或Cipher内部和界面、编码、填充都无关。常见错因有三个S 盒表抄错一个值、列混合的 GF(2^8) 乘法写错、轮密钥异或的轮次偏移差一。用测试向量定位比在界面上反复点按钮快得多因为界面层还叠着编码转换变量太多。4.3 界面联调时的观察点界面跑通后按这个顺序验证先输入纯 ASCII 短串比如hello密钥用 16 个字符加密看密文是否为合法 Base64再解密看是否还原成hello然后输入中文确认 UTF-8 转换没丢字节最后输入长度刚好 16 的倍数的明文确认填充逻辑补了整组。每一步失败对应的排查方向不同ASCII 短串失败多半是算法本身中文失败多半是编码转换整倍数长度失败多半是填充规则。把这几步做成固定的自测清单比每次凭感觉点要靠谱。5. 避坑与常见问题那些让密文对不上的细节5.1 加密解密结果不一致现象是同一段明文、同一个密钥加密后再解密得到的字符串末尾多出几个乱码字符或者干脆解不出来。原因通常出在填充上加密端补了 PKCS7解密端没去填充或者去填充时没校验填充值直接按最后一个字节截断。解决方法是确认Decrypt内部调用了PKCS7Unpad并且PKCS7Unpad的校验逻辑完整。另一个可能是密钥在两次调用间被改了——比如界面上密钥框被用户误编辑加密时用 A 密钥、解密时用 B 密钥这种情况加个密钥回显或校验提示就能避免。5.2 中文加密后解密变问号现象是英文正常中文加密再解密后变成???或乱码。原因是CString在 Unicode 工程里是宽字符直接按字节取会把每个汉字拆成两个不完整的字节。解决方法是统一走 UTF-8加密前WideCharToMultiByte(CP_UTF8, ...)解密后MultiByteToWideChar(CP_UTF8, ...)转回CString。注意两次转换的代码页必须一致一边 UTF-8 一边 ANSI 是另一个高频错误。5.3 密文里出现换行或截断现象是 Base64 密文显示到编辑框里中间断了或者末尾少了字符。原因是 Base64 编码后如果按固定列宽插入了换行符有些实现默认 76 列换行而编辑框是单行或者解码端没处理换行就会错位。解决方法是在Base64Encode里关掉换行输出或者在解码前先过滤掉\r\n。另外编辑框如果设了ES_MULTILINE但没设滚动条长密文会显示不全看起来像截断实际数据是完整的读的时候用GetWindowTextLength确认长度。5.4 换台机器就编译不过现象是在自己机器上能编译拷到同事机器上报fatal error C1083: 无法打开包括文件: afxwin.h。原因是对方 VS 没装 MFC 组件。解决方法是让对方在 Visual Studio Installer 里补装“MFC 和 ATL 支持”或者把工程改成不依赖 MFC 的 Win32 程序工作量大不推荐。还有一种情况是平台工具集版本不一致工程属性里“平台工具集”要选对方装了的版本比如v143对应 VS2022v142对应 VS2019。5.5 密钥长度传错导致静默失败现象是点了加密没反应也没弹提示。原因是Encrypt返回了 false但界面代码没检查返回值直接拿空的output去编码得到空串写回控件。解决方法是在每个调用点都判断返回值失败时AfxMessageBox给出具体原因密钥长度不对、输入为空等。这类静默失败在调试期最耗时间因为界面上什么线索都没有只能靠断点。6. 二次开发改造从 ECB 演示到可用的加密模块如果要把这个 Demo 往真实项目里用第一件该改的事是把 ECB 换成 CBC 模式。ECB 下相同明文块产生相同密文块加密一段有重复结构的文本时密文里能看出模式安全性不够。CBC 的做法是引入一个 16 字节的随机 IV第一组明文先和 IV 异或再加密后续每组和前一组密文异或。IV 不需要保密但要随密文一起存或传解密端拿它做反向操作。改造点在Encrypt的主循环里加一个prevBlock缓冲Decrypt里对应加反向异或接口上多传一个 IV 参数。// CBC 加密主循环示意 std::vectorunsigned char iv(16); // 调用方用随机源填充 std::vectorunsigned char prev iv; for (size_t off 0; off buf.size(); off 16) { for (int i 0; i 16; i) buf[off i] ^ prev[i]; // 与前一密文块异或 Cipher(buf.data() off, output.data() off, roundKey); prev.assign(output.begin() off, output.begin() off 16); }第二件该改的是密钥管理。Demo 里密钥从编辑框读真实系统里密钥不能硬编码在源码里也不该让用户手输。常见做法是从配置文件或系统凭据存储读取程序启动时加载到内存用完及时清零SecureZeroMemory。如果要做多用户每个用户一个密钥密钥本身用主密钥加密后存库这是另一层设计但至少别把明文密钥写进const char*常量里——反编译一眼就能看到。第三件是错误处理的粒度。现在Encrypt只返回 bool调用方不知道是密钥长度错还是输入为空。可以改成返回一个枚举错误码界面层根据码值给不同提示。这个改动不大但对后续排查帮助明显。验证改造是否成功除了跑标准测试向量还要加一组 CBC 的向量NIST SP 800-38A 里有现成的以及一组“篡改密文后解密应失败”的负向测试——CBC 下篡改中间某组密文解密后该组和下一组都会乱配合填充校验能检测出来。我自己的习惯是每次动加密相关代码不管改动多小都先把那几组标准向量跑一遍再提交。有一次图省事跳过了结果一个 S 盒的索引写反界面上短字符串看着正常长文本解密到中间才崩排查花了半天。从那以后测试向量这一步我强制走一遍不给自己留后悔药。希望帮到你。本文还有配套的精品资源点击获取