.NET 6 AES-128 CFB模式零填充解密结果异常原因咨询

核心前提：CFB是流加密模式，本质不需要填充 #

CFB属于流加密模式，它通过生成密钥流与明文逐块异或完成加密，无论明文长度是否为块大小（16字节）的整数倍，都不需要额外填充。但.NET的AES实现允许在流模式下指定填充模式，这会导致解密阶段的处理逻辑差异。

1. PaddingMode.Zeros导致乱码的原因 #

当解密时设置PaddingMode.Zeros，其处理逻辑是移除解密结果末尾所有连续的0字节：

• 若加密阶段使用的是默认的PaddingMode.PKCS7（.NET AES默认填充），当明文长度恰好为16字节（块大小）时，PKCS7会自动添加一个完整的16字节填充块（每个字节为0x10）。解密后得到的是「原明文 + 16个0x10字节」，而PaddingMode.Zeros无法识别这些0x10是填充字节，不会移除它们。这些0x10属于不可打印的控制字符，转成字符串时就会显示为无效问号。
• 即使加密阶段未添加填充，强行在解密时指定PaddingMode.Zeros，系统仍会尝试扫描末尾的0字节。若原明文末尾没有0，解密程序可能因填充校验逻辑错误，保留部分异常字节，最终出现乱码。

2. PaddingMode.ANSIX923结果正常的原因 #

ANSIX923的填充规则是：填充k个字节，前k-1个为0，最后一个字节为k的数值（k为需要填充的字节数）：

• 当明文长度为16字节时，若加密阶段用PKCS7填充，会添加16个0x10字节；而ANSIX923填充16字节时，最后一个字节也是0x10，前15个为0。解密时，ANSIX923的校验逻辑会识别到末尾的0x10，并移除对应的16字节填充块，刚好得到正确的原明文。
• 若加密阶段未添加填充，解密时指定PaddingMode.ANSIX923，当解密结果长度恰好为块大小时，系统会判断无需移除填充，直接返回原内容，因此结果正常。

总结 #

流模式（如CFB）下不应指定填充模式，建议加密和解密阶段都设置PaddingMode.None，避免因填充逻辑不匹配导致的乱码问题。

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