C语言手搓AES算法：从原理到嵌入式实现的工程实践

1. 项目概述：为什么选择用C语言手搓AES？

在嵌入式开发、安全协议栈实现或者对性能有极致要求的场景里，你经常会遇到一个灵魂拷问：加解密功能，是用现成的库，还是自己动手实现？尤其是对于AES（Advanced Encryption Standard）这种已经成为国际标准的对称加密算法。网上现成的库很多，OpenSSL、mbedTLS，拿过来编译一下好像就能用。但当你面对一个资源受限的MCU，需要剔除所有不必要的依赖；或者你需要透彻理解每一个加密步骤，以便进行安全审计或定制化优化时，从零开始用C语言实现一个AES软算法，就从一个“可选动作”变成了“必选项”。

我最近就遇到了这样一个需求：为一个低功耗的物联网终端设备设计固件，需要实现与服务器的安全通信。硬件平台是一颗主频不到100MHz的ARM Cortex-M3内核MCU，RAM只有几十KB，Flash也不富裕。使用庞大的密码学库显然不现实，而芯片厂商提供的硬件加密引擎又和我们的通信协议不完全匹配。最终，我们决定自己实现AES-128的加解密。这个过程就像亲手打磨一把瑞士军刀，虽然市面上有现成的，但自己做的，才知道每一个齿轮是怎么咬合的，哪里可以更薄，哪里需要更韧。

这个“AES加解密软算法（C语言实现）”项目，就是这次实践的总结。它不只是一个能跑通的代码，更是一份关于如何将复杂的数学算法，转化为高效、可靠且易于理解的C语言模块的思考笔记。无论你是嵌入式新手想窥探密码学的门径，还是老鸟在寻找一个轻量级、可移植的AES参考实现，我相信这里的讨论和代码都能给你带来直接的帮助。我们会从AES的核心原理出发，一步步拆解其实现，并重点分享在资源受限环境下进行优化和调试的那些“坑”与“技巧”。

2. AES算法核心原理快速解析

在动手写代码之前，我们必须先弄清楚AES到底在干什么。很多人一上来就对着复杂的变换步骤埋头苦干，结果越写越迷糊。理解其设计哲学，才能写出清晰的代码。

AES是一种分组密码算法，它把明文分成固定长度的块（Block）进行处理，AES标准中块长度是128位（16字节）。密钥长度则有128位、192位和256位三种，分别对应AES-128, AES-192, AES-256。我们以最常用的AES-128为例，它的加密过程，可以形象地理解为一个对数据块的“多轮搅拌”过程。

这个“搅拌”由四种基本变换组合而成，在一轮中依次执行：

1. SubBytes（字节替换）：这是一个非线性变换，是AES安全性的重要来源。它通过一个被称为S盒（Substitution-box）的查找表，将状态矩阵中的每一个字节替换成另一个字节。这个S盒是经过精心设计的，具有良好的非线性特性，能有效抵抗密码分析。
2. ShiftRows（行移位）：这是一个线性变换，目的是让数据在行间扩散。状态矩阵的每一行以不同的字节数向左循环移位。第0行不移位，第1行左移1字节，第2行左移2字节，第3行左移3字节。这打破了每一列字节之间的独立性。
3. MixColumns（列混合）：这是另一个线性变换，目的是让数据在列内进一步扩散。它将状态矩阵的每一列视为在有限域GF(2^8)上的一个多项式，并与一个固定的多项式进行模乘运算。这个操作让单个字节的变化迅速影响到整个列。
4. AddRoundKey（轮密钥加）：这是最简单的一步，将当前的状态矩阵与一轮的子密钥（Round Key）进行按位异或（XOR）操作。子密钥是从初始密钥通过密钥扩展算法派生出来的。

完整的AES-128加密，就是对一个16字节的明文数据块，先进行一次初始的AddRoundKey（使用第0轮子密钥），然后进行9轮完整的上述四步操作（称为标准轮），最后第10轮只执行SubBytes、ShiftRows和AddRoundKey（省略了MixColumns）。所以一共是10轮。

注意：解密过程就是加密过程的逆序，使用逆变换（InvSubBytes, InvShiftRows, InvMixColumns）和相同的子密钥序列（但使用顺序相反）。理解这一点对实现解密函数至关重要。

密钥扩展算法同样关键。它需要将初始的128位密钥（16字节）扩展成11个128位的子密钥（共176字节），供每一轮的AddRoundKey使用。扩展过程利用了S盒和轮常数（Rcon），也涉及有限的异或和移位操作。如果密钥扩展实现得不好，会成为性能瓶颈。

3. 工程结构与模块化设计

面对一个包含多个变换和密钥扩展的算法，良好的代码结构是成功的一半。直接写一个几百行的巨型函数是灾难性的，不利于调试、阅读和优化。我的设计遵循“高内聚、低耦合”的原则，将整个工程划分为几个清晰的模块。

3.1 核心模块划分

整个项目主要包含以下头文件和源文件：

• aes.h：公共头文件，定义数据类型、函数接口、常量（如S盒、轮常数）。
• aes_core.c：核心算法实现文件，包含加解密的核心变换函数（如SubBytes,ShiftRows等）和它们的组合。
• aes_key.c：密钥扩展算法的实现。
• aes_api.c：面向用户的应用接口层，提供诸如AES_ECB_Encrypt,AES_CBC_Decrypt这样的高级函数，处理分组工作模式。
• main.c(或测试文件)：用于测试和演示。

在aes.h中，我首先定义了关键的数据类型。由于AES操作的基本单位是字节（8位），并且经常以4字节字（32位）为单位进行处理（特别是在密钥扩展和列混合中），因此明确类型很重要：

#ifndef AES_H #define AES_H #include <stdint.h> // 使用标准整数类型 // 定义状态矩阵：4行，每行Nb个字节（AES-128中Nb=4） typedef struct { uint8_t s[4][4]; // 按列优先顺序存储，即s[r][c]表示第r行第c列 } aes_state_t; // 加密/解密函数指针类型，用于统一接口 typedef void (*aes_crypt_func_t)(aes_state_t* state, const uint8_t* round_key); // 密钥调度表：对于AES-128，需要11个子密钥，每个16字节，共176字节 typedef struct { uint8_t rd_key[176]; // 存储所有扩展后的轮密钥 int rounds; // 轮数，AES-128为10 } aes_ctx_t; // 公共API void aes_key_schedule(aes_ctx_t* ctx, const uint8_t* key); void aes_encrypt_block(aes_ctx_t* ctx, aes_state_t* state); void aes_decrypt_block(aes_ctx_t* ctx, aes_state_t* state); // 分组工作模式接口（示例） void aes_ecb_encrypt(aes_ctx_t* ctx, const uint8_t* in, uint8_t* out, size_t len); void aes_cbc_encrypt(aes_ctx_t* ctx, const uint8_t* in, uint8_t* out, size_t len, const uint8_t iv[16]); #endif // AES_H

这种设计将算法上下文（密钥表）与具体的数据块操作分离，使得同一个密钥上下文可以用于加密多个数据块，符合实际使用场景。

3.2 状态矩阵的存储顺序之争

这里有一个初学者极易混淆的细节：状态矩阵在内存中如何存储？AES标准文档中描述的状态矩阵是4x4的字节矩阵，操作时按行按列讨论。但在C语言实现时，我们有两种选择：

1. 行优先存储：uint8_t state[4][4]，state[row][col]。
2. 列优先存储：uint8_t state[4][4]， 但将每一列视为一个4字节的字，state[row][col]实际上可能表示第col列第row个字节。更常见的是直接用一维数组uint8_t state[16]，并通过索引row + 4*col来访问。

我强烈推荐并采用第二种（列优先/一维数组视图）。为什么？因为这和AES的许多操作，特别是列混合（MixColumns）和密钥扩展中字（Word）操作的概念天然契合。在列混合中，我们正是以列为单位进行运算。使用一维数组state[16]，并约定state[0], state[4], state[8], state[12]构成第0列，会让后续的代码清晰很多。在函数内部，我们可以这样定义和访问：

void SubBytes(uint8_t state[16]) { for (int i = 0; i < 16; ++i) { state[i] = sbox[state[i]]; // 直接查表替换 } }

而在头文件的结构体中，我仍然保留了二维数组[4][4]的定义，这是为了在概念上与标准文档对齐，但在核心函数实现时，我会将其作为一维数组来操作。只要在整个项目中保持一致的约定即可。

4. 核心变换的C语言实现与优化

这是整个项目的重头戏。我们将逐一实现四个核心变换，并讨论其中的优化技巧。

4.1 S盒与字节替换（SubBytes/InvSubBytes）

S盒是一个256字节的查找表。加密用的S盒（Forward S-box）和解密用的逆S盒（Inverse S-box）都是固定的。最直接的方法就是把它们定义为静态常量数组。

// aes_core.c static const uint8_t sbox[256] = { 0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5, 0x30, 0x01, 0x67, 0x2b, 0xfe, 0xd7, 0xab, 0x76, // ... 其余内容遵循AES标准 }; static const uint8_t inv_sbox[256] = { 0x52, 0x09, 0x6a, 0xd5, 0x30, 0x36, 0xa5, 0x38, 0xbf, 0x40, 0xa3, 0x9e, 0x81, 0xf3, 0xd7, 0xfb, // ... };

SubBytes函数就变得异常简单：

void SubBytes(uint8_t state[16]) { for (int i = 0; i < 16; i++) { state[i] = sbox[state[i]]; } }

逆字节替换InvSubBytes同理，只是查inv_sbox表。

实操心得：查表法的性能与安全权衡。查表法速度极快，是空间换时间的典型。但在一些对侧信道攻击（如缓存计时攻击）非常敏感的安全场景，可能需要使用计算法来生成S盒值，以避免访存模式泄露密钥信息。对于大多数嵌入式应用，查表法是完全可接受的。

4.2 行移位（ShiftRows/InvShiftRows）

行移位操作的是状态矩阵的“行”。如果我们采用列优先的一维数组视图state[16]，索引i对应的位置是行 = i % 4，列 = i / 4。那么对第r行的循环左移r位，就相当于将该行上的4个元素（位于索引r, 4+r, 8+r, 12+r）进行循环左移。

实现时，可以逐行处理：

void ShiftRows(uint8_t state[16]) { uint8_t temp; // 第1行左移1位： [1,1], [1,2], [1,3], [1,0] temp = state[1]; state[1] = state[5]; state[5] = state[9]; state[9] = state[13]; state[13] = temp; // 第2行左移2位：等价于交换两对元素 SWAP(state[2], state[10]); SWAP(state[6], state[14]); // 第3行左移3位：相当于右移1位 temp = state[15]; state[15] = state[11]; state[11] = state[7]; state[7] = state[3]; state[3] = temp; }

这里我用了宏SWAP来交换两个变量。逆移位InvShiftRows就是反向操作（右移），代码逻辑对称。

4.3 列混合（MixColumns/InvMixColumns）

这是算法中最复杂的一步，涉及有限域GF(2^8)上的乘法。有限域乘法不是普通的整数乘法，其定义基于一个不可约多项式m(x) = x^8 + x^4 + x^3 + x + 1（对应十六进制0x11B）。

列混合将每一列看作一个系数在GF(2^8)上的多项式，与固定多项式c(x) = {03}x^3 + {01}x^2 + {01}x + {02}进行模x^4+1乘法。对于解密，则是与逆多项式d(x) = {0b}x^3 + {0d}x^2 + {09}x + {0e}相乘。

手动实现有限域乘法的位运算（xtime函数）是可行的，但在性能要求高的场合，查表法是更优选择。我们可以预先计算并存储“乘以2”、“乘以3”、“乘以9”、“乘以11”等结果的查找表。不过，AES的列混合只涉及与{01},{02},{03},{09},{0b},{0d},{0e}这几个常数的乘法。一个经典的优化是结合查表和计算。

我采用了一种清晰且高效的方式来实现MixColumns：

static inline uint8_t xtime(uint8_t x) { return ((x << 1) ^ (((x >> 7) & 1) * 0x1b)); } void MixColumns(uint8_t state[16]) { uint8_t i, a, b, c, d; for (i = 0; i < 4; ++i) { // 取出当前列 a = state[i]; b = state[i + 4]; c = state[i + 8]; d = state[i + 12]; // 列混合变换公式 state[i] = xtime(a) ^ xtime(b) ^ b ^ c ^ d; state[i + 4] = a ^ xtime(b) ^ xtime(c) ^ c ^ d; state[i + 8] = a ^ b ^ xtime(c) ^ xtime(d) ^ d; state[i + 12] = xtime(a) ^ a ^ b ^ c ^ xtime(d); } }

xtime函数实现了GF(2^8)上乘以{02}的操作。左移一位相当于乘以2，但如果最高位是1（x>>7为1），则需要异或上不可约多项式0x1b（即0x11B去掉最高位）。基于xtime，乘以{03}可以表示为xtime(x) ^ x。

对于解密的InvMixColumns，系数更复杂，直接计算开销较大。一个更聪明的做法是：在密钥扩展阶段，为解密生成“等效逆轮密钥”。这样在解密时，就可以使用和加密相同的MixColumns函数（实际上是它的逆），而无需实现复杂的InvMixColumns。这是很多优化库采用的策略。如果坚持实现InvMixColumns，则需要实现与{0e},{0b},{0d},{09}的乘法，可以通过组合xtime和异或来完成，但代码会更冗长。

4.4 轮密钥加（AddRoundKey）

这是最简单的操作，就是状态矩阵与当前轮的子密钥进行异或。子密钥在内存中是连续存储的，每轮使用16个字节。

void AddRoundKey(uint8_t state[16], const uint8_t* round_key) { for (int i = 0; i < 16; ++i) { state[i] ^= round_key[i]; } }

4.5 密钥扩展（Key Expansion）

密钥扩展算法将初始的16字节密钥扩展成11个轮密钥（176字节）。其核心是KeyExpansion函数，它生成一个线性数组w[]，每4个字节（一个字）为一组。对于AES-128，需要44个字（44*4=176字节）。

扩展算法中，最关键的步骤是对每个扩展轮次的第一个字（即w[i]，其中i是4的倍数）进行特殊处理，称为SubWord（字节替换）、RotWord（字循环左移）和与轮常数Rcon异或。

static const uint8_t Rcon[11] = {0x00, 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 0x1b, 0x36}; // 注意索引从1开始使用 void KeyExpansion(const uint8_t* key, uint8_t* round_key) { uint32_t temp; uint32_t w[44]; // AES-128需要44个字 int i = 0; // 将初始密钥拷贝到前4个字 while (i < 4) { w[i] = ((uint32_t)key[4*i]<<24) | ((uint32_t)key[4*i+1]<<16) | ((uint32_t)key[4*i+2]<<8) | (uint32_t)key[4*i+3]; i++; } // 扩展后续的字 while (i < 44) { temp = w[i-1]; if (i % 4 == 0) { // 关键步骤：RotWord -> SubWord -> XOR Rcon temp = (temp << 8) | (temp >> 24); // RotWord temp = (sbox[(temp >> 24) & 0xFF] << 24) | (sbox[(temp >> 16) & 0xFF] << 16) | (sbox[(temp >> 8) & 0xFF] << 8) | (sbox[temp & 0xFF]); // SubWord temp ^= ((uint32_t)Rcon[i/4] << 24); } w[i] = w[i-4] ^ temp; i++; } // 将字数组w[]拷贝到字节数组round_key[]中，便于按轮使用 for (i = 0; i < 44; ++i) { round_key[4*i] = (w[i] >> 24) & 0xFF; round_key[4*i+1] = (w[i] >> 16) & 0xFF; round_key[4*i+2] = (w[i] >> 8) & 0xFF; round_key[4*i+3] = w[i] & 0xFF; } }

这个实现清晰地展示了密钥扩展的过程。注意RotWord是一个字（4字节）内的循环左移，SubWord是对这个字的每个字节应用S盒替换。

5. 整合与工作模式实现

有了所有核心变换和密钥扩展，我们就可以组装完整的加解密函数了。

5.1 加密与解密单块函数

加密函数aes_encrypt_block按照之前描述的轮结构组织调用：

void aes_encrypt_block(aes_ctx_t* ctx, aes_state_t* state) { uint8_t* s = (uint8_t*)state; // 将状态视为一维字节数组 const uint8_t* round_key = ctx->rd_key; // 初始轮密钥加 AddRoundKey(s, round_key); round_key += 16; // 前9轮标准轮 for (int round = 1; round < ctx->rounds; ++round) { SubBytes(s); ShiftRows(s); MixColumns(s); AddRoundKey(s, round_key); round_key += 16; } // 最后一轮（无MixColumns） SubBytes(s); ShiftRows(s); AddRoundKey(s, round_key); }

解密函数aes_decrypt_block是逆过程。如果采用了“等效逆轮密钥”的优化，其结构会和加密函数几乎一样，只是使用不同的S盒（逆S盒）和行移位方向。如果直接实现，则需要调用逆变换函数。

5.2 分组工作模式：ECB与CBC

AES是分组密码，一次处理16字节。对于任意长度的消息，需要分组工作模式。最简单的模式是ECB（电子密码本），就是将数据按16字节分块，每块独立加密。但ECB模式在明文有重复块时，密文也会重复，安全性较差。

更常用的是CBC（密码分组链接）模式。它在加密前，先将当前明文块与前一个密文块（或初始向量IV）进行异或，然后再加密。这样相同的明文块加密后也会得到不同的密文块，安全性更好。

下面给出CBC加密模式的实现示例：

void aes_cbc_encrypt(aes_ctx_t* ctx, const uint8_t* in, uint8_t* out, size_t len, const uint8_t iv[16]) { uint8_t block[16]; uint8_t feedback[16]; // 存储上一个密文块，用于异或 if (len % 16 != 0) { // 错误处理：数据长度必须是16的倍数，实际应用中可能需要填充(PKCS#7等) return; } memcpy(feedback, iv, 16); // 用IV初始化反馈 for (size_t i = 0; i < len; i += 16) { // 1. 明文块与上一个密文块（或IV）异或 for (int j = 0; j < 16; ++j) { block[j] = in[i + j] ^ feedback[j]; } // 2. 加密异或后的块 aes_state_t* state = (aes_state_t*)block; aes_encrypt_block(ctx, state); // 3. 输出密文块，并更新反馈 memcpy(&out[i], block, 16); memcpy(feedback, block, 16); } }

CBC解密则是反向过程，需要先解密，再与前一个密文块异或。这里有一个关键点：解密时，feedback存储的是前一个密文块（即输入in），而不是前一个输出。这是CBC模式的一个经典易错点。

6. 性能优化与内存权衡实战

在资源受限的嵌入式环境，优化至关重要。我们的目标是：在有限的Flash和RAM中，获得尽可能快的速度。

6.1 查表法的极致优化（T-Table）

前述的MixColumns实现虽然清晰，但每轮每个字节都需要多次调用xtime和异或，计算量不小。工业级的优化通常采用一种叫做T-Table（预计算表）的方法。其核心思想是，将SubBytes、ShiftRows和MixColumns三个步骤合并，通过4个256字（4字节）的查找表来完成一轮中一列（4字节）的变换。

具体来说，我们预先计算4个表T0,T1,T2,T3。每个表有256个条目，每个条目是一个32位字。对于状态矩阵的每一列[a0, a1, a2, a3]^T，经过一轮变换（除AddRoundKey外）后的结果列[b0, b1, b2, b3]^T可以通过查表快速计算：

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]

然后再加上轮密钥即可。这样，一轮的运算从大量的字节运算变成了4次查表和4次异或，速度提升一个数量级。代价是这4个表需要占用4KB的只读存储空间（4 * 256 * 4字节）。

是否使用T-Table，取决于你的具体场景。如果你的MCU有充足的Flash（几十KB以上），且性能是首要目标，那么T-Table是不二之选。如果你的Flash极其紧张（比如只有16KB），那么可能就需要忍受较慢的计算法。

6.2 针对ARM Cortex-M的指令集优化

如果你的目标平台是ARM Cortex-M3/M4/M33等，并且编译器支持（如ARM GCC, IAR），可以利用其提供的单周期乘法指令和位操作指令进行优化。例如，xtime操作可以用内联汇编或编译器内置函数更高效地实现。一些编译器甚至提供了针对AES的专用内置函数（如ARM的__ssat,__usat配合位操作）。不过，这需要深入理解架构和编译器特性，属于进阶优化。

6.3 内存布局优化

对于密钥调度表ctx->rd_key，确保它在内存中对齐到4字节边界，可以提升访问速度，特别是在32位架构上。可以使用编译器属性如__attribute__((aligned(4)))。

在加解密函数中，尽量使用局部变量或寄存器变量来存储中间状态，减少对全局或堆内存的访问。

7. 调试、验证与常见问题排查

自己实现的密码算法，最怕的就是结果不对。如何验证其正确性？

7.1 使用标准测试向量

NIST（美国国家标准与技术研究院）提供了官方的AES测试向量（Known Answer Tests）。你可以找一组标准的明文和密钥，运行你的程序，将输出密文与标准密文对比。这是最权威的验证方法。例如AES-128的一个经典测试向量：

Key: 2b7e151628aed2a6abf7158809cf4f3c Plaintext: 3243f6a8885a308d313198a2e0370734 Ciphertext: 3925841d02dc09fbdc118597196a0b32

为你的代码编写一个测试函数，自动加载这些向量并断言结果，是保证正确性的第一步。

7.2 分段调试与中间值对比

如果整体结果不对，就需要分段调试。

1. 先验证密钥扩展。打印出扩展后的所有轮密钥，与标准值或使用可靠工具（如OpenSSL命令行）计算的结果对比。密钥扩展错了，后面全错。
2. 再验证单轮变换。手动构造一个简单的状态矩阵，单独测试SubBytes、ShiftRows、MixColumns的输出是否正确。特别是MixColumns，可以找一些简单的输入（如全0x01，全0x02）手动计算验证。
3. 使用中间状态对比。在加密函数中，在每一轮结束后打印出状态矩阵的值，与标准中间值对比。这能帮你精确定位是哪一轮、哪一个变换出了问题。

7.3 常见问题速查表

7.4 内存与栈溢出检查

在嵌入式系统中，栈空间通常很小。确保你的函数没有定义过大的局部数组（比如在函数内部定义uint8_t state[16]是安全的，但定义一个大缓冲区可能危险）。对于密钥调度表等大数组，最好放在全局区或通过动态内存（如果可用）申请，并注意字节对齐。

使用-fstack-usage等编译器选项来检查函数的栈使用情况，确保不会在运行时导致栈溢出，那将是难以调试的灾难。

8. 从模块到应用：集成与测试建议

当核心算法验证正确后，就可以将其集成为项目中的一个安全模块了。以下是一些建议：

1. 提供清晰的API：像我们之前设计的aes.h一样，提供初始化（密钥设置）、加密、解密、以及清理（如果需要）的接口。接口应线程安全，或者明确说明非线程安全。
2. 处理数据对齐和填充：实际数据长度 rarely 是16字节的整数倍。你需要实现一种填充方案，如PKCS#7。在API层面，可以提供带填充和不带填充的版本，让调用者选择。
3. 错误处理：函数应返回明确的错误码（如AES_OK,AES_INVALID_LENGTH,AES_NULL_PTR），而不是简单地崩溃或返回无意义数据。
4. 编写单元测试：除了标准测试向量，还应创建一些边界条件测试（如空数据、单字节数据、极长数据）和随机测试，用你的实现和另一个可信实现（如OpenSSL）进行交叉验证。
5. 性能剖析：在目标硬件上，使用工具测量加解密一定量数据所需的时间和CPU周期。这有助于你评估算法性能是否满足项目要求，并指导进一步的优化方向。

最后，分享一个我踩过的坑：在为一个超低功耗设备实现AES-128 CBC时，为了省电，我最初关闭了所有优化，代码跑得很慢。后来发现，启用编译器-Os（优化大小）选项后，代码体积只增加了不到1KB，但速度提升了近5倍，整体功耗反而因为CPU活跃时间大幅缩短而降低了。在嵌入式领域，有时适当的“空间换时间”或启用编译器优化，是达成低功耗目标的有效手段，而不是一味地追求代码体积最小化。这个项目让我深刻体会到，从原理到实现，再到优化和集成，每一步都需要结合具体场景深思熟虑。希望这份详细的梳理，能帮你少走些弯路。