如果你点进来说明你至少听过 AES 这个名字。AES 是使用最广泛的对称加密算法通信加密、文件加密、物联网设备固件里几乎都有它的影子。项目标题是“AES 的代码实现 C 版”听起来就是老生常谈但真正动手写过的人都知道一轮轮变换、状态矩阵存储顺序、密钥扩展边界条件每一个环节都能把人绕晕。这篇博文就是围绕“用 C 从零实现 AES”这个主题把算法骨架、核心变换、密钥扩展、模式调用和调试经验完整讲透适合密码学刚入门、正在做嵌入式通信协议、或者想在项目中轻量集成 AES 的开发者参考。耐心看完你会得到一套能跑通标准测试向量的 C 实现也能避开我当年踩过的那些坑。1. 动手前先捋清楚AES 的算法骨架和数据结构选型1.1 从需求出发到底想要一套什么样的 AES 实现先说结论这套实现的目标不是追求极致性能而是“正确、可读、可移植”。AES 本质上是迭代分组密码分组长度固定 128 位也就是 16 字节密钥长度支持 128 位、192 位、256 位对应 AES-128、AES-192、AES-256。密钥越长轮数越多AES-128 是 10 轮AES-192 是 12 轮AES-256 是 14 轮。写代码之前我给自己列了几个硬性要求不依赖 OpenSSL 等第三方库纯 C 标准库实现方便移植到嵌入式环境支持 ECB 和 CBC 两种模式CBC 必须带 PKCS#7 填充密钥扩展要同时兼容 128/192/256 三种长度最重要的一点能通过已知的标准测试向量验证结果。这个需求列表看起来简单实际操作里几乎每一步都藏了细节。比如密钥扩展AES-128 和 AES-256 分支逻辑不一样AES-256 在扩展过程中要额外做一次 S 盒替换。如果你只照着 AES-128 的实现改长度跑出来的密文大概率是错的。1.2 AES 的顶层运算流程每一轮到底在干什么AES 的加密过程可以概括成三层结构初始轮密钥加、中间若干轮变换、最后一轮特殊处理。每一轮包含 SubBytes、ShiftRows、MixColumns、AddRoundKey 四个步骤但最后一轮要扔掉 MixColumns。很多初学者在这里困惑为什么最后一轮少一步原因是设计者为了让解密流程完全对称同时降低实现的复杂度。你不需要深究太多记住结论最后一轮只做 SubBytes、ShiftRows、AddRoundKey 三步。解密过程就是完全反过来先做初始轮密钥加然后循环做 InvShiftRows、InvSubBytes、AddRoundKey、InvMixColumns最后一轮同样没有 MixColumns 的逆操作。这里的顺序是反着来的解密时你先遇到的是 InvShiftRows不是 InvSubBytes因为加密时是先 SubBytes 再 ShiftRows解密只能倒序。我见过不少人把解密顺序写成“先 InvSubBytes 再 InvShiftRows”然后怎么测怎么不对就是没理解这个倒序逻辑。从整体上看AES 的设计哲学很简单通过多轮混合和扩散把明文和密钥的关系搅得足够复杂使得哪怕输入只改变一个比特输出也会面目全非。我们写代码时不用纠结它的数学证明但必须保证每一轮变换的方向、顺序和查找表完全按标准来。1.3 最容易出错的存储约定状态矩阵到底怎么排AES 标准里16 字节的输入要装进一个 4×4 的状态矩阵。这里的坑在于“装”的方向。AES 是列优先的也就是说输入字节依次填进状态矩阵的列而不是行。假设明文是 16 字节数组in[0..15]那么第 0 列填in[0]、in[1]、in[2]、in[3]第 1 列填in[4]、in[5]、in[6]、in[7]依此类推我在 C 里用一维数组表示状态using State std::arrayuint8_t, 16; void load_state(State s, const uint8_t in[16]) { for (int c 0; c 4; c) { for (int r 0; r 4; r) { s[c * 4 r] in[r 4 * c]; } } } void store_state(uint8_t out[16], const State s) { for (int c 0; c 4; c) { for (int r 0; r 4; r) { out[r 4 * c] s[c * 4 r]; } } }这里s[c * 4 r]的意思就是“第 c 列、第 r 行的字节”。用列优先是为了直接对齐 AES 标准文档里的矩阵公式你看文档时不会别扭。很多网上的代码直接用一维数组不分行列也能跑通但遇到 ShiftRows 这种按行操作时索引公式很容易写错。我强烈建议你跟我一样规定好索引 列 × 4 行。后面所有变换都基于这个约定代码里只需要写一遍出错率会低很多。1.4 基础工具函数字节和字的转换AES 里的操作单位有字节、字32 位。密钥扩展中常常要把 4 个字节拼成一个 uint32_t这里要注意字节序。AES 标准明确规定是“大端序”语义也就是第一个字节是最高位字节。uint32_t load_be32(const uint8_t* p) { return (static_castuint32_t(p[0]) 24) | (static_castuint32_t(p[1]) 16) | (static_castuint32_t(p[2]) 8) | static_castuint32_t(p[3]); }字节序这个东西很微妙很多实现里用的是小端序写法只要所有地方都自洽也能跑但如果你拿标准测试向量去验证字节序错了结果就是错的。我自己的经验是所有外部字节输入都用大端序解析内部运算统一用 uint32_t 表示字最后输出再转成大端序。这样处理思路固定排查问题也容易。2. 核心变换的 C 实现S 盒、行移位、列混合、轮密钥加2.1 S 盒的两种拿到方式生成还是硬编码SubBytes 是 AES 唯一的非线性变换通过 S 盒完成“字节到字节”的替换。S 盒的生成过程涉及有限域逆元和仿射变换理论上你可以从零算出来但工程上绝大多数实现都是查表。先看数学生成方式。S 盒分两步第一步对字节 x 求 GF(2^8) 乘法逆元。GF(2^8) 的不可约多项式是 x^8 x^4 x^3 x 1对应十六进制 0x11B。求逆元最直白的做法是穷举因为域里面只有 256 个元素一个个试就能找到乘法结果等于 1 的那个数。uint8_t gf_mul(uint8_t a, uint8_t b) { uint8_t p 0; while (b) { if (b 1) { p ^ a; } b 1; a static_castuint8_t((a 1) ^ (a 0x80 ? 0x1B : 0x00)); } return p; } uint8_t gf_inv(uint8_t a) { if (a 0) { return 0; } for (uint16_t x 1; x 256; x) { if (gf_mul(a, static_castuint8_t(x)) 1) { return static_castuint8_t(x); } } return 0; }这里的gf_mul就是有限域乘法看起来像竖式乘法但加法被换成了异或。a每次左移一位如果溢出最高位是 1就异或 0x1B相当于做了一次多项式模约。你如果第一次见这个写法建议手算两步感受一下后面列混合还要用同样的机制。第二步对逆元做仿射变换。仿射变换的公式是b_i a_i ^ a_{(i4)%8} ^ a_{(i5)%8} ^ a_{(i6)%8} ^ a_{(i7)%8} ^ c_i其中 c 0x63。C 实现如下uint8_t affine(uint8_t a) { uint8_t c 0x63; uint8_t b 0; for (int i 0; i 8; i) { uint8_t bit ((a i) 1) ^ ((a ((i 4) % 8)) 1) ^ ((a ((i 5) % 8)) 1) ^ ((a ((i 6) % 8)) 1) ^ ((a ((i 7) % 8)) 1) ^ ((c i) 1); b | static_castuint8_t(bit i); } return b; }有了这两步就能生成完整 S 盒std::arrayuint8_t, 256 build_sbox() { std::arrayuint8_t, 256 sbox{}; for (uint16_t x 0; x 256; x) { sbox[x] affine(gf_inv(static_castuint8_t(x))); } return sbox; }一运行就会发现sbox[0]正好等于 0x63这就是标准 S 盒的第一个值。在真实项目里我不会每次启动都算一遍而是把 256 个字节硬编码进数组或者用static const在编译期初始化。生成代码的价值在于让你理解 S 盒的来历而硬编码的价值在于减少启动开销和避免实现错误。你可以两个都保留生成代码放在测试文件里验证硬编码表是否正确。逆 S 盒就简单了直接反查std::arrayuint8_t, 256 build_inv_sbox(const std::arrayuint8_t, 256 sbox) { std::arrayuint8_t, 256 inv{}; for (int i 0; i 256; i) { inv[sbox[i]] static_castuint8_t(i); } return inv; }SubBytes 本身只是一句查表void sub_bytes(State s, const std::arrayuint8_t, 256 sbox) { for (auto b : s) { b sbox[b]; } }2.2 行移位方向、索引和反操作ShiftRows 是状态矩阵按行的循环移位但这里说的“行”是数学意义上的行不是 C 数组的下标。因为我们约定状态是s[列 * 4 行]所以要取出第 r 行的四个字节索引分别是s[0*4r]、s[1*4r]、s[2*4r]、s[3*4r]。加密时第 0 行不动第 1 行循环左移 1 个字节第 2 行左移 2 个字节第 3 行左移 3 个字节。写成一段容易理解的代码void shift_rows(State s) { State t{}; for (int r 0; r 4; r) { for (int c 0; c 4; c) { t[c * 4 r] s[((c r) % 4) * 4 r]; } } s t; }这段代码的读法很关键假设现在要填目标矩阵的(第c列, 第r行)它的值来自原始矩阵的(第((cr)%4)列, 第r行)。比如第 1 行原本四列是 [a0, a1, a2, a3]左移一位后变成 [a1, a2, a3, a0]。代入公式目标第 0 列取原第 1 列目标第 1 列取原第 2 列确实如此。解密时的逆操作是循环右移也就是目标第 c 列取原第(c - r)列要小心负数取模的问题void inv_shift_rows(State s) { State t{}; for (int r 0; r 4; r) { for (int c 0; c 4; c) { t[c * 4 r] s[((c - r 4) % 4) * 4 r]; } } s t; }4再取模是为了让负索引转正。我早期直接写(c - r) % 4在 C 里负数取模结果是负数数组直接越界这个坑希望你不要再踩。2.3 列混合GF(2^8) 乘法的实战用法MixColumns 把状态矩阵的每一列当做一个四维向量乘一个固定矩阵。加密时的矩阵系数是2 3 1 1 1 2 3 1 1 1 2 3 3 1 1 2这儿的“乘法”不是整数乘法是 GF(2^8) 乘法。好消息是系数只有 1、2、3乘 1 就是原数乘 2 可以走xtime也就是左移加条件异或 0x1B乘 3 等于 2 的结果异或原数。uint8_t xtime(uint8_t x) { return static_castuint8_t((x 1) ^ (x 0x80 ? 0x1B : 0x00)); }列混合实现为void mix_columns(State s) { for (int c 0; c 4; c) { uint8_t a0 s[c * 4 0]; uint8_t a1 s[c * 4 1]; uint8_t a2 s[c * 4 2]; uint8_t a3 s[c * 4 3]; uint8_t b0 static_castuint8_t(xtime(a0) ^ (xtime(a1) ^ a1) ^ a2 ^ a3); uint8_t b1 static_castuint8_t(a0 ^ xtime(a1) ^ (xtime(a2) ^ a2) ^ a3); uint8_t b2 static_castuint8_t(a0 ^ a1 ^ xtime(a2) ^ (xtime(a3) ^ a3)); uint8_t b3 static_castuint8_t((xtime(a0) ^ a0) ^ a1 ^ a2 ^ xtime(a3)); s[c * 4 0] b0; s[c * 4 1] b1; s[c * 4 2] b2; s[c * 4 3] b3; } }系数矩阵的排列顺序要特别留意。第一行是[2,3,1,1]所以第一个输出字节是2*a0 ^ 3*a1 ^ a2 ^ a3而不是a0 ^ a1 ^ 2*a2 ^ 3*a3。网上有些写法把行都分了看起来整齐实则容易抄错。解密时的逆列混合系数矩阵是14 11 13 9 9 14 11 13 13 9 14 11 11 13 9 14这些系数变大用xtime拼起来太啰嗦直接复用最初的gf_mul最省事void inv_mix_columns(State s) { for (int c 0; c 4; c) { uint8_t a0 s[c * 4 0]; uint8_t a1 s[c * 4 1]; uint8_t a2 s[c * 4 2]; uint8_t a3 s[c * 4 3]; s[c * 4 0] gf_mul(a0, 14) ^ gf_mul(a1, 11) ^ gf_mul(a2, 13) ^ gf_mul(a3, 9); s[c * 4 1] gf_mul(a0, 9) ^ gf_mul(a1, 14) ^ gf_mul(a2, 11) ^ gf_mul(a3, 13); s[c * 4 2] gf_mul(a0, 13) ^ gf_mul(a1, 9) ^ gf_mul(a2, 14) ^ gf_mul(a3, 11); s[c * 4 3] gf_mul(a0, 11) ^ gf_mul(a1, 13) ^ gf_mul(a2, 9) ^ gf_mul(a3, 14); } }这里效率不是重点正确性第一。如果以后要做性能优化可以预计算两张 256 字节的表乘 2 表、乘 3 表甚至组合出 T-表一次查到多字节输出。但那是优化阶段的事初版实现没必要搞这么花。2.4 轮密钥加最朴实的一步AddRoundKey 就是把 16 字节状态与当前轮的 16 字节轮密钥按字节异或。它本身不复杂复杂的是“当前轮的轮密钥到底取哪一段”。密钥扩展后得到的轮密钥是一个连续的字节数组结构如下第 0 组 16 字节初始 AddRoundKey 使用第 1 组 16 字节第 1 轮 AddRoundKey 使用...第 Nr 组 16 字节最后一轮 AddRoundKey 使用。所以完整的密钥长度是16 * (Nr 1)字节。AES-128 就是 176 字节AES-192 是 208 字节AES-256 是 240 字节。void add_round_key(State s, const std::vectoruint8_t round_keys, int round) { for (int c 0; c 4; c) { for (int r 0; r 4; r) { s[c * 4 r] ^ round_keys[round * 16 c * 4 r]; } } }这里round * 16就是跳到那一轮的起始位置c * 4 r严格对应状态的列和行。因为密钥扩展本身也遵循同样的列优先结构所以位置是自洽的。3. 密钥扩展把 16 字节主密钥变成 176 字节轮密钥3.1 词表模型四个字节一组的思维密钥扩展的输入是原始密钥按 4 字节为单位切成若干个“词”word。AES-128 有 4 个词AES-192 有 6 个词AES-256 有 8 个词分别记作 Nk 4、6、8。输出词的数量是固定的 4 * (Nr 1)。也就是说我们要从 Nk 个词扩展出更多的词。扩展的核心规则是每生成一个新词 w[i] w[i - Nk] ^ temptemp 默认是前一个词 w[i - 1]如果 i 是 Nk 的整数倍temp 要先做 RotWord、SubWord再异或轮常数 Rcon对于 AES-256当 i % Nk 4 时temp 还要额外做一次 SubWord。这里的RotWord是让 4 个字节循环左移一个字节SubWord是对每个字节查 S 盒。轮常数 Rcon 是 GF(2^8) 里的 2 的幂从 0x01 开始依次 0x02、0x04、0x08、0x10、0x20、0x40、0x80、0x1B、0x36。C 实现步骤如下std::vectoruint8_t key_expansion(const std::vectoruint8_t key) { int nk static_castint(key.size()) / 4; int nr nk 6; int total_words 4 * (nr 1); std::vectoruint32_t w(total_words); for (int i 0; i nk; i) { w[i] load_be32(key.data() 4 * i); } static const uint8_t rcon[] {0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 0x1B, 0x36}; for (int i nk; i total_words; i) { uint32_t temp w[i - 1]; if (i % nk 0) { temp sub_word(rot_word(temp)) ^ (static_castuint32_t(rcon[i / nk - 1]) 24); } else if (nk 6 i % nk 4) { temp sub_word(temp); } w[i] w[i - nk] ^ temp; } std::vectoruint8_t round_keys(total_words * 4); for (int i 0; i total_words; i) { round_keys[4 * i 0] static_castuint8_t(w[i] 24); round_keys[4 * i 1] static_castuint8_t(w[i] 16); round_keys[4 * i 2] static_castuint8_t(w[i] 8); round_keys[4 * i 3] static_castuint8_t(w[i]); } return round_keys; }辅助函数uint32_t rot_word(uint32_t x) { return (x 8) | (x 24); } uint32_t sub_word(uint32_t x, const std::arrayuint8_t, 256 sbox) { uint8_t b0 sbox[(x 24) 0xFF]; uint8_t b1 sbox[(x 16) 0xFF]; uint8_t b2 sbox[(x 8) 0xFF]; uint8_t b3 sbox[x 0xFF]; return (static_castuint32_t(b0) 24) | (static_castuint32_t(b1) 16) | (static_castuint32_t(b2) 8) | static_castuint32_t(b3); }注意rot_word是循环左移一个字节也就是abcd变成bcda。这样实现有个好处后面把 word 转回字节数组时用的是大端序与前面load_be32呼应整个实现字节序一致。3.2 为什么 AES-256 多一个 SubWord 分支AES-256 的密钥扩展规则里每生成 8 个词中的第 4 个词时要多做一次 SubWord。这是为了增强密钥扩展的非线性扩散。如果没有这一步AES-256 的扩展结构会和 AES-128 高度相似安全性会打折扣。很多初版实现只写了if (i % nk 0)分支然后拿 AES-256 测试向量一验前几轮输出是对的后面全错。你检查半天可能发现就是少了这个分支。我的经验是密钥扩展写完以后先分别用三种密钥长度去验证测试向量不要只测 AES-128。3.3 轮密钥的存储布局与调用约定密钥扩展完成后得到的round_keys向量长度为16 * (nr 1)。调用时你可以直接把它和add_round_key一起用add_round_key里通过参数round定位到对应偏移量。我想额外说明一点密钥扩展结果是一次性计算的。加密多个数据块时如果每次都对同一个密钥重新做一遍扩展纯属浪费。正确的做法是在外层把密钥扩展的结果缓存起来后续加解密只传轮密钥数组。4. 完整的加解密流程ECB 打通CBC 上生产4.1 加密块与解密块的完整调用链有了前面几个部件加密一个 16 字节块的代码就顺理成章了void aes_encrypt_block(uint8_t out[16], const uint8_t in[16], const std::vectoruint8_t round_keys, const std::arrayuint8_t, 256 sbox, int nr) { State state; load_state(state, in); add_round_key(state, round_keys, 0); for (int round 1; round nr; round) { sub_bytes(state, sbox); shift_rows(state); mix_columns(state); add_round_key(state, round_keys, round); } sub_bytes(state, sbox); shift_rows(state); add_round_key(state, round_keys, nr); store_state(out, state); }注意循环从 1 到 nr-1中间轮数一共 nr-1 轮全是完整四步最后一轮单独处理去掉 MixColumns。解密块的方向刚好相反顺序是加轮密钥、逆行移位、逆字节替换、加轮密钥、逆转置列void aes_decrypt_block(uint8_t out[16], const uint8_t in[16], const std::vectoruint8_t round_keys, const std::arrayuint8_t, 256 inv_sbox, int nr) { State state; load_state(state, in); add_round_key(state, round_keys, nr); for (int round nr - 1; round 1; --round) { inv_shift_rows(state); inv_sub_bytes(state, inv_sbox); add_round_key(state, round_keys, round); inv_mix_columns(state); } inv_shift_rows(state); inv_sub_bytes(state, inv_sbox); add_round_key(state, round_keys, 0); store_state(out, state); }解密循环里的顺序是解密特有的。因为加密时一轮的顺序是 SubBytes - ShiftRows - MixColumns - AddRoundKey解密时你逆过来就得先做 InvShiftRows 再做 InvSubBytes然后加上轮密钥再做 InvMixColumns。有人会把 InvMixColumns 放在 AddRoundKey 前面那结果就会错位。用一句话记忆解密是“脱衣服”得一件一件按相反顺序脱不能跳。4.2 PKCS#7 填充与 CBC 加解密ECB 模式下每个 16 字节分组独立加密简单但容易泄露明文模式生产环境基本不用。CBC 是经典分组模式CBC 的加密公式是 C_i AES_K(P_i XOR C_{i-1})第一个分组用初始向量 IV 参与异或。解密公式是 P_i AES_K^{-1}(C_i) XOR C_{i-1}。CBC 需要处理数据长度不是 16 字节倍数的问题我用 PKCS#7 填充如果最后一个分组差 n 字节满 16就补 n 个值为 n 的字节如果已经是 16 字节整也要额外补 16 个值为 16 的字节。后者是必须的因为解密时靠最后一个字节的值判断填充长度如果最后一个分组恰好是整数倍没有填充就无法区分“原本就以 16 结尾”还是“填充了 16 个字节”。填充函数std::vectoruint8_t pkcs7_pad(const std::vectoruint8_t data, size_t block_size) { size_t pad_len block_size - (data.size() % block_size); std::vectoruint8_t padded data; padded.insert(padded.end(), pad_len, static_castuint8_t(pad_len)); return padded; } std::vectoruint8_t pkcs7_unpad(const std::vectoruint8_t data, size_t block_size) { if (data.empty()) { return {}; } uint8_t pad_len data.back(); if (pad_len 0 || pad_len block_size || pad_len data.size()) { // 填充非法按错误处理 } for (size_t i data.size() - pad_len; i data.size(); i) { if (data[i] ! pad_len) { // 填充非法按错误处理 } } return std::vectoruint8_t(data.begin(), data.end() - pad_len); }CBC 加解密核心void cbc_encrypt(const std::vectoruint8_t plain, const std::vectoruint8_t key_bytes, const uint8_t iv[16], std::vectoruint8_t cipher) { auto round_keys key_expansion(key_bytes); int nk static_castint(key_bytes.size()) / 4; int nr nk 6; auto sbox build_sbox(); auto padded pkcs7_pad(plain, 16); State prev; load_state(prev, iv); cipher.clear(); cipher.resize(padded.size()); for (size_t i 0; i padded.size(); i 16) { State block; load_state(block, padded.data() i); for (int j 0; j 16; j) { block[j] ^ prev[j]; } aes_encrypt_block(cipher.data() i, block.data(), round_keys, sbox, nr); load_state(prev, cipher.data() i); } }CBC 解密倒过来void cbc_decrypt(const std::vectoruint8_t cipher ...) { // 用 aes_decrypt_block 逐块解密 // 解密结果与前一个密文分组异或 // 最后去填充 }第一次实现时可以先打通 ECB等 ECB 测试向量通过后再套一层 XOR 逻辑做 CBC。这样可以大幅减少调试范围。我通常把 ECB、CBC 写成两个独立函数测试时先单独验 ECB。4.3 为什么不要在生产里裸用 ECBECB 模式下相同的明文分组会产生相同的密文分组。如果加密一张图片ECB 输出的密文图片里还能隐隐看出原始图像的轮廓这种模式泄露了明文的统计特征。CBC 通过前一个密文分组参与异或破坏了这种对应关系。但 CBC 也有自己的约束IV 必须随机且每次加密不能重复。如果 IV 固定两个完全相同的明文前缀会产生相同密文前缀攻击者就能从中推断信息。正确做法是每次加密都生成新的随机 IV并且把 IV 与密文一起传输IV 不需要保密但必须不可预测。分组密码本身只保证单块安全三段式协议场景里块与块之间如果缺少认证还可能被拼接攻击。所以有条件时更推荐 GCM、CCM 这类带认证模式的实现能同时保证机密性和完整性。个人学习和实验用 CBC 没问题但拿着这套代码去做线上协议时请在明文之外额外加消息认证码。5. 验证、调试与性能心得踩坑实录5.1 用标准测试向量验证实现写完代码第一件事不是开心地加密自己的数据而是找标准测试向量。AES 最经典的 ECB 测试向量如下密钥000102030405060708090a0b0c0d0e0f明文00112233445566778899aabbccddeeff密文69c4e0d86a7b0430d8cdb78070b4c55a把这段数据输入你的 ECB 加密函数逐字节对比输出的十六进制串。如果一致说明你实现了正确的 AES如果不一致立刻进入对比模式。我把验证过程写成一段简单命令式逻辑void print_hex(const std::vectoruint8_t data) { for (uint8_t b : data) { printf(%02x, b); } printf(\n); }你自己写测试时最好把期望密文硬编码出来然后assert(actual expected)。不要用别人的随机密文来验证因为你不知道别人的实现是否可靠。标准向量才是唯一可靠的锚点。5.2 常见 Bug 与排查方法我总结了一份高频错误速查表每一行都来自真实调试经历。症状可能原因检查方向第一个分组就错状态矩阵加载/存储方向反了检查 load_state / store_state 的索引只有后续分组错CBC 里上一个分组参与异或逻辑错误检查 prev 是否更新成密文解密结果开头对结尾乱码填充长度判断错误检查 pkcs7_unpad 逻辑AES-128 对AES-256 错密钥扩展少了 Nk 6 的 SubWord 分支检查 key_expansion解密结果全是乱码解密顺序错误或逆函数用错检查 aes_decrypt_block 的循环顺序轮密钥加的位置偏了round 参数传错检查 add_round_key 里 round * 16定位错误的最好方法是“打印中间状态”。在加密块的每个函数之间输出状态矩阵然后用一个可信实现比如系统里的权威加密工具的中间结果对比。虽然麻烦但对理解算法本身非常有帮助。我在初学时花了一晚上调试 ShiftRows最后发现就是索引公式里的取模写反了。另一个隐蔽坑是填充的“非法值”没有做完整检查。我在pkcs7_unpad里要先确认最后一个字节的值在合法范围然后逐个校验填充区域的值是否等于该值否则直接报错。现实协议里填充校验不严格可能会导致 padding oracle 攻击这是个很经典的漏洞面。手工实现的代码可能只用于内部实验但养成严格校验的习惯不会错。5.3 性能优化方向与安全建议初版代码的性能不在最优状态原因在于大量使用gf_mul的循环和函数调用。实际加速手段一般有三个方向第一T-表优化。把 SubBytes 和 MixColumns 合并成查找表用一张 256×4 的表下一次查询同时完成两个变换。代价是需要多张表并且要考虑字节序对齐代码复杂度明显上升。第二编译器优化。开启-O2后简单循环展开和多层内联能带来不小提升。如果在嵌入式环境里__attribute__((always_inline))也是个思路。第三硬件指令。主流 CPU 基本都有 AES-NI 指令集一条指令完成一整轮 AES。但注意硬件指令通常只暴露给底层库你想在自己的 C 实现里用需要内联汇编或编译器内建函数。假如只是学习目的先把软件实现写对再谈指令加速。性能之外还要说安全。第一所有查表操作如果索引依赖密钥或密文理论上存在 cache timing 侧信道风险。严谨的安全实现会使用恒定时间编程例如用位运算代替条件分支避免因分支预测泄露信息。第二不要把密钥硬编码到二进制里密钥管理应该依靠系统钥匙串或安全硬件。第三分组密码要配合认证模式使用。我这套代码里 CBC 只保证机密性没有完整性保护真实应用中应叠加 HMAC 或者直接换成认证加密模式。5.4 我现在的建议如果想把这套代码用到实际产品里我不建议真的使用手写实现除非你的安全团队有能力审计。手写密码算法最大的风险不是数学上的错而是实现上的侧信道漏洞。OpenSSL、系统自带的 CryptoAPI、专门的安全库都经过大量审计和硬件优化安全性和性能都比手写实现可靠。那手写实现的意义在哪里在于理解。当你亲手写一遍 S 盒生成、列混合、密钥扩展再回去看库函数文档里面每个选项、每个模式、每个警告都有具体的算法图像。之后再遇到加密相关的问题你能快速判断是模式使用问题、密钥管理问题还是算法本身的问题。这是纯调库的用户很难获得的深度。我自己的体会是AES 的 C 实现不应该被看作是“重复造轮子”而是一门必修课。它把你从“调用者”变成“理解者”。如果你看完这篇博文后动手实现我希望你能先跑通标准向量再做 CBC最后再去尝试优化或扩展硬件加速。至于是自己留着学习还是继续改造完全取决于你的目标。最后再分享一个小技巧写这类密码算法时建议从一开始就准备一个“自测程序”把测试向量、中间状态打印、错误退出集中在一个文件里。每次改完任何一个函数跑一遍自测心里就有底了。等全部通过再把这个自测文件保留下来将来做性能优化时它就是你最可靠的回归测试工具。
