C语言使用tiny-AES-c实现AES256-ECB加密仅前16字符生效问题排查

你观察到的仅前16字节被加密、剩余明文保持不变的现象，是AES块加密开发中的典型误区，和你修改BLOCK_LEN配置的操作完全无关，根因非常明确：

• AES是严格固定16字节分组长度的块加密算法，不管是AES128/192/256变体，单次加密运算的输入输出长度固定为16字节，这个长度是密码学标准定义死的，和密钥长度无关。你修改库内的BLOCK_LEN宏不会改变算法本身的块处理逻辑，属于完全无效的排查方向。
• tiny-AES-c库提供的AES_ECB_encrypt接口本身的设计是单次处理单个16字节块，不会自动遍历你传入的整个输入缓冲区。你当前的代码大概率是把整个明文缓冲区的起始指针直接传给这个接口，接口只会读取起始位置的16字节完成加密写回，就直接返回了，缓冲区剩余的字节完全没有经过加密流程，自然会保持原明文状态，你看到的末尾"123"未加密就是这个原因导致的。
• 没有做明文长度对齐处理。ECB模式要求所有待加密内容必须按16字节的块切分，哪怕最后一个块不足16字节，也需要通过填充规则补满16字节后才能送进加密接口，你当前输入的字符串长度超过16字节的部分，因为没有补全、没有循环喂给加密接口，自然不会被加密。

按照以下逻辑调整代码，即可实现全字符串的加密效果：

1. 对原始明文做PKCS#7格式填充：计算当前明文长度对16取余的差值，如果余数不为0，就在明文末尾追加对应数量的字节，每个字节的取值等于追加的总数量。比如明文长度是19（16个基础字符+末尾3个"123"），对16取余为3，就追加3个值为0x03的字节，把总长度凑为32，也就是两个完整的16字节块。
2. 循环分块调用加密接口：从填充完成的明文缓冲区起始位置开始，每次取出16字节作为单块输入，调用一次AES_ECB_encrypt得到对应的16字节密文块，按顺序写入输出缓冲区，之后将读写指针向后偏移16字节，重复这个过程直到所有填充后的块全部处理完成。
3. 密文存储时不要依赖字符串结束符：AES加密后的密文是二进制数据，可能包含0x00字节，不能用strlen计算密文长度，存储到文件时要明确记录密文的实际字节数，避免出现密文截断的问题。

补充提醒：ECB模式本身存在结构性安全缺陷，相同的明文块会生成完全相同的密文块，很容易被攻击者分析存储内容的结构。如果只是测试加解密流程可以暂时使用，后续涉及真实密码存储时，一定要替换为CBC、GCM等带初始向量、带完整性校验的加密模式，不要直接用ECB模式做敏感数据存储。

内容的提问来源于stack exchange，提问作者Shadoww