1. 项目概述：从零构建一个纯C的AES加密算法库

最近在做一个嵌入式设备上的安全通信模块，需要实现一套轻量级的AES加密算法。市面上虽然有很多现成的库，比如OpenSSL的AES组件，但在资源受限的MCU上，动辄几百KB的库体积和复杂的依赖链让人望而却步。更重要的是，很多库为了通用性做了大量封装，代码结构复杂，不利于深入理解AES这个“现代密码学基石”的内部运作机制。于是，我决定自己动手，用纯C语言从头实现AES算法，并且一次性把最常见的几种工作模式——ECB、CBC和CTR都搞定。这不仅仅是为了完成项目，更是一次彻底搞懂对称加密底层原理的绝佳机会。

如果你也和我一样，对“黑盒”式的加密调用感到不安，想真正掌握如何将一段明文，通过一系列精巧的数学变换，变成一堆看似杂乱无章的密文，那么这个项目就是为你准备的。我们将从AES最核心的S盒、行移位、列混合和轮密钥加开始，一步步搭建起加密和解密的流程，然后再用这个核心引擎去驱动ECB、CBC、CTR这些工作模式。整个过程会涉及大量的位操作、查表和状态矩阵变换，我会把每一步的“为什么”都讲清楚。最终，你会得到一套完全可控、无任何外部依赖、代码清晰可读的AES加密库源码，无论是集成到你的IoT设备、桌面应用，还是单纯用于学习，都极具价值。

2. AES核心算法原理与C语言实现拆解

AES（Advanced Encryption Standard）是一种分组密码算法，它加密和解密的数据块大小固定为128位（16字节）。密钥长度则可以是128位、192位或256位，分别对应AES-128、AES-192和AES-256。我们这里以实现最常用的AES-128为例，一旦核心流程打通，扩展到192和256位只是轮数（Round）的增加，原理完全一致。

AES加密过程可以看作是对一个4x4的字节状态矩阵（State）进行多轮（对于AES-128是10轮）的迭代变换。每一轮都包含四个基本操作（最后一轮略有不同）：字节代换（SubBytes）、行移位（ShiftRows）、列混合（MixColumns）和轮密钥加（AddRoundKey）。解密则是这些操作的逆过程。

2.1 关键数据结构与轮密钥扩展

在C语言中，我们首先需要定义如何表示这个4x4的状态矩阵。最直观的方式是用一个二维数组uint8_t state[4][4]。但是，考虑到后续行移位和列混合操作对整行或整列数据访问的便利性，以及一些优化技巧，我们也可以用一个一维数组uint8_t state[16]来按列优先顺序存储。我选择了后者，因为它在内存上是连续的，在某些平台和优化下可能更有优势。数据填充的顺序是：state[0], state[4], state[8], state[12]是第一列，以此类推。

轮密钥扩展（Key Expansion）是AES的第一步，也是至关重要的一步。它的作用是将一个短的初始密钥（比如16字节）扩展成一系列用于各轮加密的轮密钥（共11个，每个128位）。这个过程的精妙之处在于它引入了非线性（通过S盒）和与轮数的关联（通过Rcon），确保了密钥序列的伪随机性，即使初始密钥只有少量差异，扩展出的轮密钥也会截然不同。

// 轮常数表，用于密钥扩展 static const uint8_t Rcon[10] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 0x1b, 0x36 }; void KeyExpansion(const uint8_t* key, uint8_t* w) { uint8_t temp[4]; int i = 0; // 初始密钥直接作为前4个字（16字节） while (i < 4) { w[i*4] = key[i*4]; w[i*4+1] = key[i*4+1]; w[i*4+2] = key[i*4+2]; w[i*4+3] = key[i*4+3]; i++; } i = 4; while (i < 44) { // AES-128需要44个字（11轮*16字节/轮） // 将前一个字存入temp for(int k=0; k<4; k++) { temp[k] = w[(i-1)*4 + k]; } if (i % 4 == 0) { // 1. 字循环：将temp中的4个字节循环左移一位 uint8_t t = temp[0]; temp[0] = temp[1]; temp[1] = temp[2]; temp[2] = temp[3]; temp[3] = t; // 2. 字节代换：对temp的每个字节进行S盒替换 for(int k=0; k<4; k++) { temp[k] = getSBoxValue(temp[k]); } // 3. 与轮常数异或 temp[0] ^= Rcon[i/4 - 1]; } // w[i] = w[i-4] xor temp for(int k=0; k<4; k++) { w[i*4 + k] = w[(i-4)*4 + k] ^ temp[k]; } i++; } }

注意：这里的getSBoxValue函数需要提前实现，用于查询S盒的替换值。S盒是一个256字节的查找表，是AES非线性的主要来源，其设计基于有限域GF(2^8)上的乘法逆元和仿射变换。在实现时，我们通常直接将其定义为静态常量数组。

2.2 核心轮函数：SubBytes, ShiftRows, MixColumns, AddRoundKey

字节代换（SubBytes）：这是AES中唯一的非线性变换。它通过一个预定义的S盒（Substitution-box）将状态矩阵中的每一个字节替换为另一个字节。这个操作极大地增强了算法的混淆（Confusion）特性，使得密文与密钥之间的关系变得极其复杂。在C实现中，我们只需要遍历状态矩阵的16个字节，每个字节作为索引去查S盒表即可。解密时则使用逆S盒（InvSBox）。

void SubBytes(uint8_t* state) { for (int i = 0; i < 16; i++) { state[i] = getSBoxValue(state[i]); // 加密用S盒 // 解密时替换为：state[i] = getInvSBoxValue(state[i]); } }

行移位（ShiftRows）：这是一个线性变换，目的是将状态矩阵中的行按不同的偏移量进行循环左移。具体规则是：第0行不移位，第1行循环左移1个字节，第2行循环左移2个字节，第3行循环左移3个字节。这个操作增强了算法的扩散（Diffusion）特性，使得一个字节的改变能在多轮迭代后影响到整个状态矩阵。在按列优先的一维数组表示法中，行移位需要一些下标计算。

void ShiftRows(uint8_t* state) { uint8_t temp; // 第1行循环左移1字节: 状态矩阵中第1行的元素索引是 1,5,9,13 temp = state[1]; state[1] = state[5]; state[5] = state[9]; state[9] = state[13]; state[13] = temp; // 第2行循环左移2字节: 索引 2,6,10,14 -> 交换 (2,10) 和 (6,14) temp = state[2]; state[2] = state[10]; state[10] = temp; temp = state[6]; state[6] = state[14]; state[14] = temp; // 第3行循环左移3字节，等价于循环右移1字节: 索引 3,7,11,15 temp = state[15]; state[15] = state[11]; state[11] = state[7]; state[7] = state[3]; state[3] = temp; }

列混合（MixColumns）：这是AES中最复杂的操作，它将状态矩阵的每一列视为GF(2^8)上的一个多项式，并与一个固定的多项式c(x) = {03}x^3 + {01}x^2 + {01}x + {02}进行模x^4+1乘法。这个操作在列之间引入了强烈的扩散。在实际C代码实现中，我们通常不直接进行多项式运算，而是利用其线性性质，将其转化为一个在字节上的矩阵乘法，并通过查找表（T-table）或直接计算来实现。这里给出直接计算的实现，便于理解原理。

// 在GF(2^8)上乘以2（即左移一位，如果最高位为1则异或0x1b） #define xtime(x) (((x) << 1) ^ (((x) & 0x80) ? 0x1b : 0x00)) void MixColumns(uint8_t* state) { uint8_t tmp[4]; for (int i = 0; i < 4; i++) { // 处理每一列 // 列i的四个字节：state[i], state[i+4], state[i+8], state[i+12] tmp[0] = state[i]; tmp[1] = state[i+4]; tmp[2] = state[i+8]; tmp[3] = state[i+12]; state[i] = xtime(tmp[0]) ^ xtime(tmp[1]) ^ tmp[1] ^ tmp[2] ^ tmp[3]; state[i+4] = tmp[0] ^ xtime(tmp[1]) ^ xtime(tmp[2]) ^ tmp[2] ^ tmp[3]; state[i+8] = tmp[0] ^ tmp[1] ^ xtime(tmp[2]) ^ xtime(tmp[3]) ^ tmp[3]; state[i+12] = xtime(tmp[0]) ^ tmp[0] ^ tmp[1] ^ tmp[2] ^ xtime(tmp[3]); } }

解密时的逆列混合操作InvMixColumns使用的是另一个固定多项式d(x) = {0b}x^3 + {0d}x^2 + {09}x + {0e}，计算逻辑类似但更复杂，通常也通过查表优化。

轮密钥加（AddRoundKey）：这是最简单的操作，将当前的状态矩阵与当前轮的轮密钥进行逐字节的异或（XOR）操作。它引入了密钥的依赖性。实现上就是一次循环。

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

2.3 完整的AES-128加密与解密流程

将上述轮函数组合起来，就构成了完整的加密流程。需要注意的是，初始轮之前有一次AddRoundKey（使用扩展密钥的第0-3个字），然后进行9轮标准轮函数（SubBytes, ShiftRows, MixColumns, AddRoundKey），最后一轮省略MixColumns。

void AES_Encrypt(uint8_t* input, const uint8_t* key, uint8_t* output) { uint8_t state[16]; uint8_t roundKey[176]; // 44个字 * 4字节 = 176字节 // 1. 密钥扩展 KeyExpansion(key, roundKey); // 2. 初始化：明文拷贝到状态矩阵 for (int i = 0; i < 16; i++) { state[i] = input[i]; } // 3. 初始轮密钥加 AddRoundKey(state, roundKey); // 使用第0轮密钥 // 4. 进行9轮标准加密 for (int round = 1; round < 10; round++) { SubBytes(state); ShiftRows(state); MixColumns(state); AddRoundKey(state, roundKey + round * 16); // 使用第round轮密钥 } // 5. 最后一轮（无MixColumns） SubBytes(state); ShiftRows(state); AddRoundKey(state, roundKey + 10 * 16); // 使用第10轮密钥 // 6. 将状态矩阵输出为密文 for (int i = 0; i < 16; i++) { output[i] = state[i]; } }

解密流程AES_Decrypt则是加密流程的逆序，操作也全部使用逆变换（InvSubBytes, InvShiftRows, InvMixColumns），并且轮密钥的使用顺序也是反的。这里有一个关键点：由于列混合和轮密钥加操作的顺序问题，解密时轮密钥需要先进行逆列混合变换，或者调整操作顺序。一种常见的实现是使用“等价解密电路”，但这会增加复杂度。我们这里采用最直观的方式，即严格按照逆序执行逆操作。

void AES_Decrypt(uint8_t* input, const uint8_t* key, uint8_t* output) { uint8_t state[16]; uint8_t roundKey[176]; KeyExpansion(key, roundKey); for (int i = 0; i < 16; i++) { state[i] = input[i]; } // 初始轮（对应加密的最后一轮） AddRoundKey(state, roundKey + 10 * 16); InvShiftRows(state); InvSubBytes(state); // 中间9轮 for (int round = 9; round > 0; round--) { AddRoundKey(state, roundKey + round * 16); InvMixColumns(state); // 注意：解密时InvMixColumns在AddRoundKey之后 InvShiftRows(state); InvSubBytes(state); } // 最后轮（对应加密的初始轮） AddRoundKey(state, roundKey); // 使用第0轮密钥 for (int i = 0; i < 16; i++) { output[i] = state[i]; } }

实操心得：在实现解密时，最容易出错的地方就是InvMixColumns和AddRoundKey的顺序。记住一个口诀：“加密时先列混合再加密钥，解密时先加密钥再逆列混合”。这是因为这些操作在有限域上的数学特性决定的。如果顺序搞反，解密结果必然是乱码。建议在实现后，用标准的测试向量（例如NIST发布的AES Known Answer Test）进行严格验证。

3. 工作模式详解：ECB、CBC、CTR的实现与选择

AES核心算法一次只处理128位（16字节）的数据块，这被称为分组密码。但实际需要加密的消息长度是任意的，可能是几个字节，也可能是几个GB。工作模式（Mode of Operation）就是定义如何重复应用分组密码来加密任意长度消息的规则。不同的模式在安全性、并行性、错误传播等方面有巨大差异。

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

ECB（Electronic Codebook）模式是最直观的模式：将明文分割成若干个16字节的分组（最后一个分组可能需要填充），然后对每个分组独立地用相同的密钥进行AES加密。

实现逻辑：

1. 对明文进行PKCS#7填充（后面会详述），确保其长度是16的整数倍。
2. 将填充后的明文按16字节分块。
3. 对每一块明文，调用AES_Encrypt函数。
4. 将所有密文块拼接起来。

void AES_ECB_Encrypt(uint8_t* plaintext, int plaintext_len, const uint8_t* key, uint8_t* ciphertext) { int padded_len = (plaintext_len / 16 + 1) * 16; // 计算填充后长度 uint8_t* padded_data = (uint8_t*)malloc(padded_len); memcpy(padded_data, plaintext, plaintext_len); // 进行PKCS#7填充 uint8_t pad_value = padded_len - plaintext_len; for (int i = plaintext_len; i < padded_len; i++) { padded_data[i] = pad_value; } // ECB加密每个块 for (int i = 0; i < padded_len; i += 16) { AES_Encrypt(padded_data + i, key, ciphertext + i); } free(padded_data); }

ECB的特点与致命缺陷：

• 优点：简单，每个分组的加密解密完全独立，支持并行计算和随机访问。
• 致命缺点：相同的明文块会产生相同的密文块。这意味着如果明文中有大量重复的模式（比如一张BMP格式的图片，其背景色是均匀的），在密文中会清晰地暴露出来。因此，ECB模式在实际的安全通信中几乎不应该被使用，它只适用于加密随机数据（如密钥本身）。

注意事项：在网络上搜索AES示例代码时，很多简单的教程都用ECB模式，因为它实现起来最简单。但请务必记住，除非你非常清楚自己在做什么（比如只是在学习算法原理），否则不要在任何需要语义安全的场景下使用ECB。

3.2 CBC模式：引入链式反馈的密码分组链接

CBC（Cipher Block Chaining）模式通过引入一个初始化向量（IV，Initialization Vector）和链式反馈，解决了ECB的模式重复问题。在CBC中，每一个明文块在加密前，会先与前一个密文块进行异或（第一个块与IV异或）。

实现逻辑（加密）：

1. 生成或获取一个随机的、不可预测的16字节IV。IV不需要保密，但必须唯一且随机，通常随密文一起发送。
2. 对明文进行填充。
3. 将第一个明文块与IV异或，然后加密，得到第一个密文块。
4. 将第二个明文块与第一个密文块异或，然后加密，得到第二个密文块。
5. 以此类推。

void AES_CBC_Encrypt(uint8_t* plaintext, int plaintext_len, const uint8_t* key, const uint8_t* iv, uint8_t* ciphertext) { uint8_t block[16]; uint8_t feedback[16]; // 用于存储上一个密文块（或初始IV） memcpy(feedback, iv, 16); // 初始反馈是IV int padded_len = (plaintext_len / 16 + 1) * 16; uint8_t* padded_data = (uint8_t*)malloc(padded_len); memcpy(padded_data, plaintext, plaintext_len); uint8_t pad_value = padded_len - plaintext_len; for (int i = plaintext_len; i < padded_len; i++) { padded_data[i] = pad_value; } for (int i = 0; i < padded_len; i += 16) { // 1. 明文块与反馈值异或 for (int j = 0; j < 16; j++) { block[j] = padded_data[i + j] ^ feedback[j]; } // 2. 加密异或后的块 AES_Encrypt(block, key, ciphertext + i); // 3. 更新反馈值为当前密文块 memcpy(feedback, ciphertext + i, 16); } free(padded_data); }

解密逻辑： 解密过程是反向的：先解密一个块，然后将结果与前一个密文块（解密第一个块时是IV）异或，得到明文块。注意，解密时不需要按顺序进行，因为每个密文块在解密时只依赖于自身和前一个密文块（或IV）。

CBC的特点：

• 优点：消除了ECB的模式重复问题，相同的明文块在不同的位置或使用不同的IV会产生不同的密文块，提供了语义安全。
• 缺点：
  1. 错误传播：加密是串行的，无法并行。更重要的是，解密时，如果一个密文块在传输中损坏（比特错误），它会影响两个明文块：对应的块解密后完全乱码，下一个块解密后仅损坏的块对应的位出错。
  2. 填充预言攻击：如果攻击者能够向系统提交密文并观察解密是否成功（通过填充错误等侧信道），可能实施填充预言攻击来逐步破解密文。现代的实现必须使用“填充Oracle防御”或直接采用无填充的认证加密模式（如GCM）。

3.3 CTR模式：将分组密码变为流密码

CTR（Counter）模式的思想非常巧妙：它不再直接加密明文，而是加密一个计数器（Counter）来产生一个密钥流（Keystream），然后将这个密钥流与明文进行异或得到密文。解密过程完全相同（异或的特性）。

实现逻辑：

1. 选择一个随机数（Nonce）和一个计数器（Counter）。通常Nonce和Counter组合成一个16字节的值，例如高8字节是Nonce，低8字节是Counter，Counter从0开始递增。
2. 对于每个明文块，加密Nonce || Counter得到一个16字节的密钥流块。
3. 将密钥流块与明文块进行逐字节异或，得到密文块。
4. Counter加1，重复步骤2-3，直到处理完所有明文。

void AES_CTR_Transform(uint8_t* input, int input_len, const uint8_t* key, const uint8_t* nonce, uint8_t* output) { // CTR模式加密和解密是同一个函数 uint8_t counter_block[16]; uint8_t keystream_block[16]; uint64_t counter = 0; // 假设使用64位计数器 // 将Nonce（假设为8字节）拷贝到counter_block的高位 memcpy(counter_block, nonce, 8); for (int i = 0; i < input_len; i += 16) { // 1. 构造计数器块：Nonce + Counter // 注意字节序，这里简单将counter按小端序放入后8字节 for (int j = 0; j < 8; j++) { counter_block[15 - j] = (counter >> (j * 8)) & 0xFF; } // 2. 加密计数器块，生成密钥流 AES_Encrypt(counter_block, key, keystream_block); // 3. 密钥流与输入（明文或密文）异或 int bytes_to_process = (input_len - i) < 16 ? (input_len - i) : 16; for (int j = 0; j < bytes_to_process; j++) { output[i + j] = input[i + j] ^ keystream_block[j]; } // 4. 计数器递增 counter++; } }

CTR模式的巨大优势：

• 并行性：由于每个计数器块都是独立的，密钥流的生成可以完全并行化（加密端和解密端都可以）。
• 无填充：CTR模式是流密码模式，明文不需要填充到分组长度的整数倍。最后一个块用密钥流的部分字节异或即可。
• 随机访问：要解密第N个块，只需要知道Nonce和Counter的初始值，然后直接加密Nonce || (Counter+N)生成对应的密钥流块即可，无需解密前面的所有块。
• 加密解密同构：同一个函数既用于加密也用于解密，减少了代码重复和潜在错误。

CTR模式的关键要求：

• 计数器必须永不重复：使用相同的密钥和相同的计数器值加密两个不同的明文是灾难性的，因为攻击者可以将两个密文异或，从而得到两个明文的异或，进而可能分析出明文。因此，必须确保（Key, Nonce）对唯一。通常Nonce是随机生成的，只要随机性足够好，冲突概率极低。

实操心得：在现代应用中，CTR模式因其并行、无填充、随机访问的特性，被广泛使用。但它本身只提供保密性，不提供完整性（即无法防止密文被篡改）。因此，CTR模式通常与一个消息认证码（MAC），如HMAC，结合使用，形成“加密然后认证”或“认证加密”模式（如GCM模式，它本质上是CTR模式加上GMAC认证）。在实现时，务必妥善管理Nonce，例如使用一个递增的序列号或高质量的随机数生成器。

4. 填充方案、IV/Nonce管理与代码优化

4.1 填充方案：PKCS#7详解

对于ECB和CBC这类需要分组对齐的模式，当明文长度不是16字节的整数倍时，就需要填充。PKCS#7是最常用的填充方案。

规则：假设需要填充N个字节，那么这N个字节的每个字节的值都设置为N。

• 示例1：明文最后差3字节，则填充0x03 0x03 0x03。
• 示例2：明文长度恰好是16的倍数，则需要额外填充一个完整的分组（16字节），每个字节为0x10。这是为了解密时能无歧义地移除填充。

实现与验证：

// PKCS#7 填充 int pkcs7_pad(uint8_t* data, int data_len, int block_size) { int pad_len = block_size - (data_len % block_size); if (pad_len == 0) pad_len = block_size; for (int i = 0; i < pad_len; i++) { data[data_len + i] = pad_len; } return data_len + pad_len; // 返回填充后的总长度 } // PKCS#7 去填充验证 int pkcs7_unpad(uint8_t* data, int padded_len, int block_size, int* success) { if (padded_len == 0 || padded_len % block_size != 0) { *success = 0; return 0; } uint8_t pad_value = data[padded_len - 1]; if (pad_value == 0 || pad_value > block_size) { *success = 0; return 0; } // 验证填充字节的值是否正确 for (int i = padded_len - pad_value; i < padded_len; i++) { if (data[i] != pad_value) { *success = 0; return 0; } } *success = 1; return padded_len - pad_value; // 返回去除填充后的原始数据长度 }

注意：在解密后去除填充时，必须验证填充的合法性。不验证就直接去除是许多填充Oracle攻击的根源。上面的unpad函数进行了基本验证，在实际安全应用中，验证失败时应返回一个通用的错误，而不是具体的错误类型，以避免侧信道攻击。

4.2 IV与Nonce的管理策略

• CBC的IV：必须是不可预测的（通常要求是密码学安全的随机数），并且不需要保密。绝对禁止使用固定的IV或全零IV。每次加密都应使用新的随机IV，并将其与密文一起存储或传输（通常放在密文开头）。
• CTR的Nonce：必须确保在相同的密钥下永不重复。常见的策略有两种：
  1. 随机Nonce：使用足够长的随机数（如12字节），由于生日悖论，随机冲突的概率极低。需要将Nonce与密文一起传输。
  2. 计数器Nonce：将Nonce分为两部分：一部分是固定或随机的“初始化值”，另一部分是递增的计数器。例如，一个8字节的随机数作为前缀，加上一个8字节的计数器。这要求系统能持久化记录最后一个使用的计数器值，防止重启后重复。

4.3 代码优化与可移植性考量

我们上面的实现是“教育优先”的，注重可读性。在实际项目中，尤其是对性能有要求的场景，可以考虑以下优化：

1. 查表法（T-table）：将轮函数中的多个步骤（SubBytes, ShiftRows, MixColumns）合并，通过预先计算好的查找表（T-table）来加速。这是软件实现AES最常用的优化手段，可以将多轮操作简化为查表和异或，性能提升显著。
2. 内联函数与宏：将xtime,getSBoxValue等简单操作定义为宏或内联函数，消除函数调用开销。
3. 硬件加速：现代x86 CPU（AES-NI指令集）和许多ARM Cortex-A系列处理器都提供了AES的硬件指令。在支持的环境下，使用这些指令可以获得数个数量级的性能提升。我们的C代码可以作为不支持硬件加速时的备选方案。
4. 内存对齐：确保状态矩阵和轮密钥数组的内存地址是16字节对齐的，在某些架构上能提高内存访问速度。
5. 常量时间实现：为了防止时序攻击（Timing Attack），所有操作，特别是S盒查表，应该保证运行时间不依赖于密钥或数据。这通常意味着要避免使用数据依赖的分支和数组索引。我们的基础实现在这方面是脆弱的，安全关键的应用需要使用精心编写的常量时间代码。

5. 集成测试、常见问题与安全实践

5.1 使用标准测试向量进行验证

在完成代码编写后，第一件事就是用官方测试向量验证其正确性。你可以从NIST的官方网站找到AES的Known Answer Test (KAT) 向量。这里给出一个AES-128 ECB模式的简单测试：

int test_aes_ecb() { // 测试向量来自NIST FIPS 197 Appendix B uint8_t key[16] = { 0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6, 0xab, 0xf7, 0x97, 0x99, 0x89, 0xcf, 0xab, 0x12 }; uint8_t plaintext[16] = { 0x32, 0x43, 0xf6, 0xa8, 0x88, 0x5a, 0x30, 0x8d, 0x31, 0x31, 0x98, 0xa2, 0xe0, 0x37, 0x07, 0x34 }; uint8_t expected_ciphertext[16] = { 0x39, 0x25, 0x84, 0x1d, 0x02, 0xdc, 0x09, 0xfb, 0xdc, 0x11, 0x85, 0x97, 0x19, 0x6a, 0x0b, 0x32 }; uint8_t ciphertext[16]; uint8_t decrypted[16]; AES_Encrypt(plaintext, key, ciphertext); // 比较ciphertext和expected_ciphertext if (memcmp(ciphertext, expected_ciphertext, 16) != 0) { printf("ECB加密测试失败！\n"); return -1; } AES_Decrypt(ciphertext, key, decrypted); // 比较decrypted和plaintext if (memcmp(decrypted, plaintext, 16) != 0) { printf("ECB解密测试失败！\n"); return -1; } printf("AES-128 ECB基础加解密测试通过！\n"); return 0; }

同样，需要为CBC和CTR模式寻找包含IV/Nonce和更长明文的测试向量进行验证。

5.2 常见问题排查表

在实现和调试过程中，你可能会遇到以下问题：

5.3 安全实践要点

1. 密钥管理是关键：算法本身是安全的，但密钥泄露则一切归零。永远不要硬编码密钥在代码中。使用安全的密钥生成和存储机制。
2. 弃用ECB：对于任何需要保密性的实际数据，不要使用ECB模式。
3. 正确使用CBC：CBC必须使用随机且不可预测的IV。考虑使用加密的IV（例如，用密钥加密一个计数器作为IV）。注意防范填充Oracle攻击，对于新项目，建议直接使用认证加密模式。
4. 优先选择CTR或GCM：在新项目中，CTR（结合HMAC进行认证）或直接使用GCM（Galois/Counter Mode）这类认证加密模式是更佳选择。GCM同时提供保密性和完整性，且效率很高。
5. 实现侧信道防御：如果代码运行在可能被物理接触或共享的云环境，需要考虑时序攻击和缓存攻击。使用常量时间实现的算法库（如OpenSSL的恒定时间函数）是更安全的选择。
6. 不要自己发明加密模式：始终使用经过密码学界广泛审查的标准模式（如CBC, CTR, GCM）。组合使用加密和认证时，遵循“加密然后MAC”或使用标准的AEAD模式。

通过这个从零实现AES ECB、CBC、CTR的过程，我们不仅得到了一套可用的源码，更重要的是深入理解了对称加密的核心思想、工作模式的差异以及实际应用中的种种陷阱。这套代码可以作为学习密码学的绝佳材料，也可以在经过严格审计和优化后，用于资源受限且无法使用大型加密库的环境。记住，在密码学中，“魔鬼在细节中”，任何一个微小的失误都可能彻底破坏系统的安全性。