从零实现AES：深入理解对称加密核心原理与C++工程实践

1. 项目缘起：为什么需要自己动手实现AES？

在C++开发中，尤其是涉及数据安全、网络通信、本地配置存储的场景，加密是一个绕不开的话题。AES（Advanced Encryption Standard）作为目前全球最主流的对称加密算法，其重要性不言而喻。你可能在项目中直接调用过OpenSSL、Crypto++等库的AES接口，一行代码就完成了加密解密，感觉非常方便。但不知道你有没有遇到过这样的困惑：当加密结果和另一个系统（比如Java后端、Python脚本）对不上时，排查起来异常痛苦；或者当需要一些非标准用法（比如混合编码输入输出）时，发现库的接口不够灵活。

这就是我决定动手从头实现一个AES加密解密工具的原因。知其然，更要知其所以然。通过亲手实现一遍AES的ECB、CBC两种模式，支持128/192/256三种密钥长度，并处理字符串、十六进制、二进制文件等多种输入输出格式，你不仅能彻底掌握AES的工作机制，更能获得一种“底层掌控感”。以后遇到任何加密相关的疑难杂症，你都能从原理层面快速定位，而不是在黑盒API面前束手无策。这个项目不是要替代成熟的加密库，而是为你打造一把理解对称加密的“万能钥匙”。

2. AES核心原理快速透视：从状态矩阵到轮密钥加

在开始写代码之前，我们必须先打破对AES的“黑盒”印象。AES加密的本质，是对一个16字节（128位）的“状态（State）”矩阵进行多轮的可逆变换。理解这个“状态”的流转过程，是看懂一切代码的基础。

2.1 状态矩阵与初始回合

AES将明文数据块视为一个4x4的字节矩阵，称为状态（State）。例如，明文字节序列 P0, P1, ..., P15 按列优先顺序填充到矩阵中：

| P0 P4 P8 P12 | | P1 P5 P9 P13 | | P2 P6 P10 P14 | | P3 P7 P11 P15 |

加密过程就是对这个State矩阵进行Nr轮（Nr取决于密钥长度：AES-128为10轮，192为12轮，256为14轮）的迭代运算。每一轮包含四个基本步骤：字节替换（SubBytes）、行移位（ShiftRows）、列混合（MixColumns）、轮密钥加（AddRoundKey）。第一轮开始前，会先进行一次AddRoundKey（使用第0个轮密钥），最后一轮则省略MixColumns步骤。

2.2 四大核心变换详解

字节替换（SubBytes）：这是一个非线性变换，通过一个预定义的S盒（S-Box）完成。State中的每一个字节都被替换为S盒中对应位置的新字节。例如，State[i][j] = S_box[State[i][j]]。S盒的设计基于有限域GF(2^8)上的乘法逆元运算和仿射变换，是AES提供混淆（Confusion）特性的关键，让输出和输入之间不存在简单的线性关系。在代码实现上，我们直接用一个256字节的查找表来实现，效率最高。

行移位（ShiftRows）：这是一个线性变换，对State的每一行进行循环左移。第0行不移位，第1行左移1个字节，第2行左移2个字节，第3行左移3个字节。这个操作增加了扩散（Diffusion）特性，使得一个字节的变化能在多轮后影响到整个状态矩阵的多个字节。 移位后的状态矩阵示意（箭头表示移动方向）：

原行0: [a00, a01, a02, a03] -> 不变 原行1: [a10, a11, a12, a13] -> [a11, a12, a13, a10] 原行2: [a20, a21, a22, a23] -> [a22, a23, a20, a21] 原行3: [a30, a31, a32, a33] -> [a33, a30, a31, a32]

列混合（MixColumns）：这是最复杂的一步，将State的每一列视为GF(2^8)上的一个四项多项式，与一个固定的多项式 c(x) = {03}x^3 + {01}x^2 + {01}x + {02} 进行模 x^4+1 乘法。这个运算可以表示为矩阵乘法：

| b0 | | 02 03 01 01 | | a0 | | b1 | = | 01 02 03 01 | * | a1 | | b2 | | 01 01 02 03 | | a2 | | b3 | | 03 01 01 02 | | a3 |

这里的乘法和加法都是定义在GF(2^8)上的。在实际代码中，我们同样可以通过查表（列混合表）或直接计算来实现。它极大地增强了扩散效果。

轮密钥加（AddRoundKey）：这是最简单的一步，将当前的状态矩阵与当前轮的轮密钥（也是一个4x4矩阵）进行逐字节的异或（XOR）操作。State[i][j] ^= RoundKey[i][j]。轮密钥是从原始密钥通过密钥扩展算法派生出来的。

2.3 密钥扩展算法：一把钥匙开多把锁

原始的密钥（16/24/32字节）并不直接用于每一轮。密钥扩展算法（Key Expansion）的作用是生成一个长度为4*(Nr+1)字的扩展密钥数组（一个字=4字节），其中每一轮使用连续4个字作为该轮的轮密钥。 以AES-128为例，原始密钥为16字节（4个字：w[0], w[1], w[2], w[3]）。扩展算法递归地生成后续的w[i]：

• 如果 i 不是4的倍数，则 w[i] = w[i-4] ^ w[i-1]。
• 如果 i 是4的倍数，则 w[i] = w[i-4] ^ T(w[i-1])。其中T函数包含：将w[i-1]循环左移一个字节、字节替换（用S盒）、再与轮常数Rcon[j]（j为轮数）进行异或。 这个算法确保了轮密钥之间具有足够的非线性关系，避免了从部分轮密钥推导出原始密钥。

解密过程就是加密过程的逆序，依次执行逆变换：逆轮密钥加、逆列混合（InvMixColumns）、逆行移位（InvShiftRows）、逆字节替换（InvSubBytes）。逆列混合对应的固定多项式为 d(x) = {0b}x^3 + {0d}x^2 + {09}x + {0e}。

注意：理解这些数学原理对于调试至关重要。当你的加密结果与标准库不一致时，可以逐步对比每一轮变换后的状态矩阵，从而精准定位是S盒、行移位、列混合还是密钥扩展出了错。我建议在开发初期，为每一个变换函数编写独立的单元测试，用标准测试向量（如NIST发布的FIPS-197附录C的示例）进行验证。

3. 工程架构与核心类设计

理解了原理，我们开始搭建代码骨架。一个好的架构能让支持六种模式（ECB/CBC x 128/192/256）和多种IO格式变得清晰可控。我将项目核心分为三个部分：核心算法模块（AESCore）、模式控制器（AESMode）、输入输出处理器（IOHandler）。

3.1 AESCore类：算法的纯粹实现

这个类只关心最纯粹的AES变换，不涉及分组模式，也不关心数据从哪里来到哪里去。它的接口非常干净。

class AESCore { public: enum KeySize { AES_128 = 16, AES_192 = 24, AES_256 = 32 }; AESCore(KeySize size); bool setKey(const unsigned char* key); // 设置密钥并执行密钥扩展 void encryptBlock(unsigned char* inout); // 原地加密一个16字节块 void decryptBlock(unsigned char* inout); // 原地解密一个16字节块 // ... 内部实现细节：SubBytes, ShiftRows, MixColumns, KeyExpansion 等私有函数 private: KeySize m_keySize; int m_nr; // 轮数 unsigned char m_roundKey[240]; // 最大扩展密钥空间 (AES-256: 15轮 * 16字节) // S盒、逆S盒、列混合表等静态查找表 };

为什么这样设计？将算法核心隔离出来，使得单元测试变得极其容易。你可以单独测试encryptBlock对一个已知明文和密钥的输出是否正确。这也是软件设计中“单一职责原则”的体现。

3.2 AESModeController类：组织加密模式

这个类负责管理分组密码模式（ECB、CBC）和填充（Padding）。它是用户主要交互的接口之一。

class AESModeController { public: enum Mode { ECB, CBC }; enum Padding { PKCS7, ZERO }; // 常见的填充方式 AESModeController(AESCore::KeySize keySize, Mode mode); void setKey(const unsigned char* key, int length); void setIV(const unsigned char* iv); // CBC模式需要初始化向量IV std::vector<unsigned char> encrypt(const std::vector<unsigned char>& plaintext, Padding pad = PKCS7); std::vector<unsigned char> decrypt(const std::vector<unsigned char>& ciphertext, Padding pad = PKCS7); // ... 处理CBC模式的链式操作，以及填充的添加与移除 private: AESCore m_aesCore; Mode m_mode; std::vector<unsigned char> m_iv; // 内部方法：applyPadding, removePadding, ecbEncrypt, cbcEncrypt等 };

关键点分析：填充（Padding）。因为AES是分组密码，一次处理16字节。如果明文长度不是16的整数倍，就需要填充。PKCS#7是最常用的标准：缺n个字节，就填充n个值为n的字节。例如，如果最后缺3字节，则填充0x03 0x03 0x03。解密后需要准确移除这些填充字节。ZERO填充则用0x00填充，但需要额外记录原始数据长度，否则无法区分末尾的0是填充还是有效数据。

3.3 IOHandler命名空间：灵活应对各种数据源

这是让工具变得好用的关键。我们需要处理字符串（UTF-8？）、十六进制字符串（“A1B2C3”）、二进制文件。我将它们设计为一组独立的函数，而不是类，因为它们是无状态的工具。

namespace IOHandler { // 字符串 -> 字节向量 (默认UTF-8) std::vector<unsigned char> stringToBytes(const std::string& str); std::string bytesToString(const std::vector<unsigned char>& bytes); // 十六进制字符串 <-> 字节向量 std::vector<unsigned char> hexStringToBytes(const std::string& hex); std::string bytesToHexString(const std::vector<unsigned char>& bytes, bool uppercase = false); // 文件 <-> 字节向量 bool readFile(const std::string& filepath, std::vector<unsigned char>& content); bool writeFile(const std::string& filepath, const std::vector<unsigned char>& content); // 自动检测输入类型（简单启发式：是否全是0-9a-fA-F且长度为偶数？） enum InputType { BINARY, HEX_STRING, PLAIN_STRING }; InputType detectInputType(const std::string& input); }

十六进制处理的坑：hexStringToBytes函数要处理用户可能输入的空白字符（空格、换行）、大小写混用，甚至“0x”前缀。一个健壮的实现需要先清理字符串，再逐两个字符用sscanf或查表转换为一个字节。反之，bytesToHexString则要确保输出格式统一，便于复制和比对。

4. 六种模式的具体实现与对比

“六种模式”实质是2种分组模式 x 3种密钥长度的排列组合。我们分别看看ECB和CBC的实现差异。

4.1 ECB模式：最简单的电子密码本

ECB（Electronic Codebook）模式最简单：将明文分割成独立的16字节块，每个块用相同的密钥独立加密。

std::vector<unsigned char> AESModeController::ecbEncrypt(const std::vector<unsigned char>& plaintext) { std::vector<unsigned char> padded = applyPadding(plaintext, m_padding); std::vector<unsigned char> ciphertext(padded.size()); for (size_t i = 0; i < padded.size(); i += 16) { unsigned char block[16]; memcpy(block, &padded[i], 16); m_aesCore.encryptBlock(block); // 核心加密调用 memcpy(&ciphertext[i], block, 16); } return ciphertext; }

ECB的致命弱点：相同的明文块必然产生相同的密文块。这对于图像、音频等具有重复模式的数据是灾难性的。即使加密了，数据的模式依然可见。因此，在绝大多数实际应用中，不推荐使用ECB模式。但作为学习和测试基准，它不可或缺。

4.2 CBC模式：带反馈的链式加密

CBC（Cipher Block Chaining）模式解决了ECB的模式重复问题。它在加密前，先将当前明文块与前一个密文块进行异或，然后再加密。第一个块则与一个初始化向量（IV）进行异或。

std::vector<unsigned char> AESModeController::cbcEncrypt(const std::vector<unsigned char>& plaintext) { std::vector<unsigned char> padded = applyPadding(plaintext, m_padding); std::vector<unsigned char> ciphertext(padded.size()); unsigned char prevBlock[16]; memcpy(prevBlock, m_iv.data(), 16); // 使用IV作为第一个“前驱密文块” for (size_t i = 0; i < padded.size(); i += 16) { unsigned char block[16]; memcpy(block, &padded[i], 16); // XOR with previous ciphertext block (or IV) for (int j = 0; j < 16; ++j) { block[j] ^= prevBlock[j]; } m_aesCore.encryptBlock(block); memcpy(&ciphertext[i], block, 16); memcpy(prevBlock, block, 16); // 更新前驱块为当前密文块 } return ciphertext; }

解密过程则是逆过程：先解密当前块，再与前一个密文块（或IV）异或得到明文。CBC模式的关键：

1. IV必须是随机的、不可预测的，且不需要保密，但每次加密都应更换。一个常见的错误是使用固定IV或全零IV，这会削弱安全性。
2. 错误传播：CBC模式中，一个密文块在传输中损坏，会导致对应明文块以及下一个明文块的解密失败（因为下一个块解密需要用到当前损坏的密文块做异或）。但这在某些场景下被视为一种“完整性”的弱验证。

实操心得：在测试CBC模式时，务必验证其“链式”特性。你可以尝试修改密文中间的某一个字节，观察解密后对应明文块及后续一个块都变成了乱码，而ECB模式下只会影响一个块。这是理解分组模式差异最直观的实验。

5. 从字符串到文件：输入输出处理的实战细节

工具的好用与否，很大程度上取决于IO处理的鲁棒性和便利性。我们的目标是让用户可以通过命令行轻松指定输入是字符串、十六进制文本还是文件，并指定输出格式。

5.1 命令行参数解析设计

一个典型的用法可能是：

./aes_tool -m cbc -k 256 -i "Hello World" --iv random -o hex ./aes_tool -m ecb -k 128 -f input.bin -o output.enc

我们需要一个灵活的解析器。我推荐使用getopt（POSIX）或argparse（第三方库），但对于自包含项目，一个简单的循环也能胜任。关键是要清晰定义参数：

• -m, --mode:ecb或cbc
• -k, --keylength:128,192,256
• -i, --input: 直接输入字符串
• -f, --file: 输入文件路径
• --iv: 指定IV（十六进制字符串），或使用random生成
• --key: 密钥（字符串或十六进制）。注意：实际项目中密钥应从安全渠道获取，这里仅为演示。
• -o, --output-format:bin(二进制),hex(十六进制文本),base64(可选扩展)
• -d, --decrypt: 解密模式

5.2 密钥与IV的生成与管理

密钥输入：支持直接输入字符串（如-k "mySecretKey"），程序内部将其转换为字节序列（注意字符编码）。更安全的方式是输入十六进制密钥（如-k "2b7e151628aed2a6abf7158809cf4f3c"）。对于AES-128，十六进制字符串长度应为32字符（16字节）。

IV的生成：对于CBC加密，如果用户未提供IV，必须生成一个密码学安全的随机IV。在C++11及以上，可以使用<random>库中的std::random_device和std::uniform_int_distribution来生成随机字节。切勿使用rand()或时间戳作为IV，它们不具备密码学安全性。

std::vector<unsigned char> generateRandomIV() { std::vector<unsigned char> iv(16); std::random_device rd; std::uniform_int_distribution<unsigned short> dist(0, 255); for (auto& byte : iv) { byte = static_cast<unsigned char>(dist(rd)); } return iv; }

一个重要提示：IV需要随密文一起存储或传输，因为解密时需要同样的IV。通常的做法是将IV拼接在密文前面（例如前16字节是IV，后面是真正的密文）。

5.3 文件操作与大数据处理

对于大文件，不能一次性读入内存。我们的工具虽然演示了完整流程，但在处理大文件时应采用流式处理。

bool encryptFile(const std::string& inputPath, const std::string& outputPath, AESModeController& aes) { std::ifstream inFile(inputPath, std::ios::binary); std::ofstream outFile(outputPath, std::ios::binary); if (!inFile || !outFile) return false; // 如果是CBC模式，生成并写入IV std::vector<unsigned char> iv; if (aes.getMode() == AESModeController::CBC) { iv = generateRandomIV(); outFile.write(reinterpret_cast<const char*>(iv.data()), iv.size()); aes.setIV(iv.data()); } const size_t bufferSize = 1024 * 16; // 16KB缓冲区，保持是16字节的倍数 std::vector<unsigned char> buffer(bufferSize); std::vector<unsigned char> plainBlock(16); size_t plainBlockPos = 0; while (inFile.read(reinterpret_cast<char*>(buffer.data()), bufferSize) || inFile.gcount() > 0) { size_t bytesRead = inFile.gcount(); for (size_t i = 0; i < bytesRead; ++i) { plainBlock[plainBlockPos++] = buffer[i]; if (plainBlockPos == 16) { // 加密一个完整块 aes.encryptBlockInPlace(plainBlock.data()); // 假设有原地加密接口 outFile.write(reinterpret_cast<const char*>(plainBlock.data()), 16); plainBlockPos = 0; } } } // 处理最后的不完整块（填充） if (plainBlockPos > 0) { // ... 应用PKCS7填充到最后一个块 aes.encryptBlockInPlace(plainBlock.data()); outFile.write(reinterpret_cast<const char*>(plainBlock.data()), 16); } return true; }

这种流式处理方式可以加密任意大小的文件，内存占用恒定。

6. 完整代码走读与关键函数剖析

由于篇幅限制，这里无法贴出全部上千行代码，但我会剖析几个最核心、最容易出错的函数，并解释其实现要点。完整的代码工程建议采用模块化文件组织：aes_core.cpp,aes_modes.cpp,io_handler.cpp,main.cpp。

6.1 密钥扩展（KeyExpansion）的实现

这是AES正确性的基石。以AES-128为例：

void AESCore::keyExpansion(const unsigned char* key) { unsigned char temp[4]; // 拷贝原始密钥到扩展密钥数组的前4个字 for (int i = 0; i < 4; ++i) { m_roundKey[i*4] = key[i*4]; m_roundKey[i*4+1] = key[i*4+1]; m_roundKey[i*4+2] = key[i*4+2]; m_roundKey[i*4+3] = key[i*4+3]; } // 生成后续的轮密钥 for (int i = 4; i < 4 * (m_nr + 1); ++i) { // 临时变量 = 前一个字 for (int j = 0; j < 4; ++j) { temp[j] = m_roundKey[(i-1)*4 + j]; } if (i % 4 == 0) { // 对前一个字进行T函数变换：RotWord + SubWord + Rcon // 1. 循环左移一个字节 unsigned char k = temp[0]; temp[0] = temp[1]; temp[1] = temp[2]; temp[2] = temp[3]; temp[3] = k; // 2. 字节替换（S盒） for (int j = 0; j < 4; ++j) { temp[j] = sbox[temp[j]]; } // 3. 与轮常数异或 temp[0] ^= rcon[i/4]; } // 生成当前字：w[i] = w[i-4] ^ temp for (int j = 0; j < 4; ++j) { m_roundKey[i*4 + j] = m_roundKey[(i-4)*4 + j] ^ temp[j]; } } }

关键点：

• rcon是轮常数数组，定义在别处：rcon[1] = 0x01, rcon[2] = 0x02, rcon[3] = 0x04, ...，后续每个值是前一个值在GF(2)上乘以{02}。
• 对于AES-192和AES-256，密钥扩展的逻辑略有不同，主要体现在i % Nk == 0的判断上（Nk是原始密钥的字数，128为4，192为6，256为8），并且AES-256在i % Nk == 4时也需要进行一次SubWord操作。必须严格按照标准实现。

6.2 列混合（MixColumns）的查表优化

直接计算列混合涉及大量的有限域乘法和异或，性能较差。工业级实现都采用查表法。我们可以预先计算好一个“列混合表”（也称为T表）。 原理是将列混合的矩阵乘法运算，转化为对状态矩阵每个字节的查表与异或。具体来说，对于状态矩阵的一列[a0, a1, a2, a3]^T，结果列[b0, b1, b2, b3]^T可以通过四个查找表T0, T1, T2, T3计算得出：

b0 = T0[a0] ^ T1[a1] ^ T2[a2] ^ T3[a3] b1 = T0[a1] ^ T1[a2] ^ T2[a3] ^ T3[a0] b2 = T0[a2] ^ T1[a3] ^ T2[a0] ^ T3[a1] b3 = T0[a3] ^ T1[a0] ^ T2[a1] ^ T3[a2]

每个T表有256个项，每个项是一个32位字。这样，原本需要16次有限域乘法和12次异或的一列运算，变成了4次查表和4次异或，性能提升巨大。在代码中，这些表是静态常量数组。解密时使用对应的逆表Td0, Td1, Td2, Td3。

6.3 PKCS7填充的添加与移除

这是一个看似简单但容易出错的细节。

std::vector<unsigned char> applyPadding(const std::vector<unsigned char>& data, PaddingType type) { if (type != PKCS7) { /* 处理其他填充 */ } size_t blockSize = 16; size_t padLen = blockSize - (data.size() % blockSize); if (padLen == 0) padLen = blockSize; // 如果刚好对齐，额外填充一个完整块 std::vector<unsigned char> padded(data); padded.insert(padded.end(), padLen, static_cast<unsigned char>(padLen)); return padded; } std::vector<unsigned char> removePadding(const std::vector<unsigned char>& paddedData, PaddingType type) { if (type != PKCS7) { /* 处理其他填充 */ } if (paddedData.empty()) return paddedData; unsigned char padLen = paddedData.back(); // 安全检查：padLen必须在1到16之间，且最后padLen个字节的值都必须等于padLen if (padLen == 0 || padLen > 16) { throw std::runtime_error("Invalid PKCS7 padding."); } for (size_t i = paddedData.size() - padLen; i < paddedData.size(); ++i) { if (paddedData[i] != padLen) { throw std::runtime_error("Invalid PKCS7 padding."); } } return std::vector<unsigned char>(paddedData.begin(), paddedData.end() - padLen); }

踩坑提醒：解密后移除填充时，必须进行严格的有效性检查。恶意构造的密文可能导致padLen值超出范围，如果不检查就直接截断，可能会造成数据损坏或安全漏洞（如Padding Oracle Attack的潜在前提）。

7. 测试、验证与性能考量

自己实现的加密算法，必须经过严苛的测试才能让人放心使用。

7.1 使用标准测试向量验证

NIST FIPS-197文档的附录C提供了完整的测试向量，包括AES-128/192/256的加密解密示例。这是验证我们算法实现正确性的黄金标准。你需要编写测试函数，将标准密钥、明文输入你的算法，逐字节比对输出密文是否一致。同样，用密文和密钥解密，看是否能还原明文。

一个实用的调试技巧：当测试失败时，不要只对比最终结果。应该编写一个“中间状态输出”函数，在每一轮加密后打印出State矩阵的内容，与标准文档中提供的中间值进行比对。这样可以快速定位是哪个变换（SubBytes, ShiftRows, MixColumns, AddRoundKey）出了问题。

7.2 与OpenSSL结果交叉比对

除了标准测试向量，还可以用OpenSSL命令行工具作为参照。例如：

# 使用OpenSSL ECB模式加密 echo -n "Hello World123456" | openssl enc -aes-128-ecb -K $(echo -n "my16bytekey...." | xxd -p) -nosalt | xxd -p # 使用我们自己的工具加密 ./aes_tool -m ecb -k 128 -i "Hello World123456" --key "my16bytekey...." -o hex

确保两者的输出（密文的十六进制表示）完全一致。对于CBC模式，还需要保证IV一致。这个过程能验证整个流程，包括填充处理是否正确。

7.3 性能分析与优化思路

一个纯教育实现的AES，性能通常远低于高度优化的库（如Intel AES-NI指令集加速）。但我们可以做一些优化：

1. 查表法：如前所述，使用T表实现MixColumns和SubBytes的合并运算，是最大的性能提升点。
2. 循环展开：在加密/解密的主循环中，手动展开几轮循环，可以减少循环开销。因为AES轮数是固定的（10,12,14），完全可以展开。
3. 内存对齐：确保状态矩阵和轮密钥在内存中对齐到16字节边界，某些平台下能提升内存访问速度。
4. 避免动态内存分配：在核心的encryptBlock函数内部，使用栈上数组而非new或vector，减少开销。

你可以使用简单的计时函数来对比优化前后的速度。但请记住，安全永远比性能更重要。在未经过充分审计和测试之前，切勿将自实现的加密算法用于生产环境。这个项目的首要目标是教育和理解。

8. 常见问题排查与安全警示

在实现和使用过程中，你肯定会遇到各种“坑”。这里总结几个典型问题。

8.1 密文比对失败：编码与填充的陷阱

问题描述：你的程序加密“Hello World”，得到的十六进制结果，和网上某个在线工具的结果不一样。排查步骤：

1. 确认密钥和IV：确保双方使用的密钥字节序列完全一致。你是将字符串“key”直接转换为ASCII字节，还是进行了其他哈希处理？在线工具可能默认进行了某种转换。
2. 确认明文：“Hello World”是否包含末尾的换行符？字符串编码是UTF-8还是GBK？对于中文字符，差异会更大。最稳妥的方式是使用十六进制明文进行测试。
3. 确认模式与填充：双方都是ECB模式吗？都是PKCS7填充吗？有些旧工具可能使用ZeroPadding或NoPadding。
4. 确认数据块：对于CBC模式，IV是否一致？IV是否被拼接在密文前？建议：始终先用标准测试向量（纯十六进制表示的密钥、明文、IV）验证核心算法的正确性，排除算法实现本身的问题。然后再处理字符串编码等外围问题。

8.2 解密后出现乱码或多余字符

这几乎肯定是填充移除环节出了问题。

1. 检查填充验证逻辑：你的removePadding函数是否严格执行了有效性检查？如果直接信任padLen并从末尾截断，当密文被篡改或解密密钥错误时，解出的“明文”的最后一个字节可能是任意值（比如0x23），程序会错误地截断最后35个字节，导致大量乱码。
2. 区分二进制与文本：如果你加密的是文本，解密后得到字节序列，需要正确转换为字符串。如果加密时输入的是带BOM的UTF-8文本，解密后也要按相同方式解读。
3. CBC模式的IV：解密时使用的IV必须和加密时完全一致。如果IV是随机的并保存在文件头，解密时你是否正确读取了前16字节作为IV？

8.3 关于安全性的重要警示

请务必理解以下几点：

1. 本实现用于学习：这个自己实现的AES库，目的是教学和深入理解。它没有经过专业密码学家的审计，可能包含微妙的实现漏洞（如侧信道攻击），绝对不应用于任何真实的生产系统、网络通信或敏感数据保护。
2. 使用权威库：在实际项目中，请使用经过长期实战检验的库，如OpenSSL, libsodium, Crypto++等。它们经过了优化和安全性审查。
3. 密钥管理是关键：加密系统的安全性很大程度上取决于密钥如何生成、存储、分发和销毁。算法公开且坚固，但密钥泄露则全盘皆输。
4. 模式选择：如无特殊兼容性要求，避免使用ECB。对于新项目，更推荐使用认证加密模式，如GCM（Galois/Counter Mode），它在提供保密性的同时还能提供完整性认证。

通过这个从零实现AES的项目，你获得的不只是一段能运行的代码，而是对对称加密筋骨脉络的深刻认知。下次当你再调用AES_encrypt这样的函数时，你脑海中将清晰地浮现出字节在S盒中替换、矩阵在行间移位、列在有限域中混合的场景。这种理解，是单纯调用API永远无法给予的。