AES加密实现仅损坏末尾字节问题排查求助

1. 先确认填充模式是否完全匹配 #

AES是块加密算法，必须把明文补到16字节的整数倍才能加密，不同填充模式的处理逻辑差异极大，加密和解密使用的模式必须完全一致：

• PKCS#7（优先用标准实现）：缺多少字节就补多少个等于缺省数的字节。比如你原文件2677字节，2677÷16余5，那要补11个0x0B（16-5=11）；要是文件刚好是16的倍数，得额外补16个0x10，否则解密时无法判断是否需要去填充。
• Zero Padding：用0x00补到块大小，但这个模式坑点多——如果原文件末尾本身有0x00，解密时根本分不清是原数据还是填充，而且不同实现对“刚好是块大小的文件”处理逻辑不一致，有的不补，有的补16个0x00，很容易出错。

你的情况是解密后多12字节、原末尾5字节被17个00替换，大概率是加密用了一种填充模式，解密时用了另一种，或是自己实现的填充/去填充逻辑存在错误。

2. 排查填充/去填充代码的常见bug #

容易踩的错误点： #

• 加密时填充长度计算错误：比如当文件大小刚好是16的倍数时，跳过了填充步骤（正确应该补16个0x10），导致解密时无法正确识别填充边界。
• 解密时去填充逻辑混乱：比如不管实际填充长度，直接硬删末尾16字节；或是把PKCS#7填充当成Zero Padding，直接删除所有末尾0x00——你遇到的末尾数据被替换，很可能是解密时没正确去掉填充，还额外写入了多余的00字节。
• 文件读写时字节数异常：比如加密时没完整读取文件所有字节，或是写入加密数据时不小心多写了几个0x00，叠加填充问题后就会出现大小异常。

举个典型的错误去填充代码：

# 错误示例：不管实际填充长度，强制删除末尾16字节
def bad_unpad(data):
    return data[:-16]

这种代码碰到非块大小倍数的文件，会直接删掉原数据的末尾有效字节，后续处理再补入00就会出现你描述的情况。

3. 核对加密后的文件大小 #

原文件2677字节，用PKCS#7加密后的大小应该是2688字节（168块×16字节）。如果你的加密后文件不是这个大小，说明加密阶段就出问题了：

• 要是加密后是2689字节，说明加密时多写了1个0x00，解密时又没处理好填充，叠加后就多了12字节。
• 先检查加密时是否完整读取了整个文件的字节，有没有出现读取偏移或额外写入的情况。

4. 顺带确认加密模式与密钥派生 #

虽然你的问题出在末尾，但也得排除其他干扰项：

• 比如用CBC模式时，加密和解密的IV（初始化向量）必须完全一致，IV错误会导致前16字节乱码，若后续块解密异常，也可能影响填充边界的判断。
• 密码转密钥的过程（比如PBKDF2），迭代次数、盐、密钥长度（128/192/256位）必须加密解密一致，密钥错误会导致整个解密数据乱码，但你只是末尾异常，这个概率较低，可快速验证排除。

5. 手动验证最后一块解密数据 #

把加密后的最后16字节单独解密，查看结果：

• 如果是PKCS#7填充，解密后的最后一个字节应该是0x0B，且最后11字节都是0x0B，去掉这11字节就能还原原文件的末尾5字节。
• 如果解密后最后一块全是0x00，说明加密时用了Zero Padding，但解密时没去掉这些填充，还额外添加了00，导致数据异常。

总结排查步骤 #

1. 不要自己手动实现填充逻辑，直接用语言内置加密库（比如Java的Cipher、Python的pycryptodome）的标准PKCS#7实现，比自定义逻辑可靠得多。
2. 检查加密代码：填充长度计算为pad_len = 16 - (len(data) % 16)，然后补入pad_len个值为pad_len的字节。
3. 检查解密代码：先取最后一个字节作为pad_len，再截取data[:-pad_len]，最好验证所有填充字节的值是否都等于pad_len，防止数据篡改导致的判断错误。
4. 核对加密前后文件大小：加密后必须是16的整数倍，解密后必须与原文件大小完全一致。

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