RijndaelManaged在.NET Framework与.NET 5的差异及跨版本兼容问题咨询

问题原因 #

Rijndael算法合法的密钥长度仅为16、24、32字节三类，你遇到的版本差异本质是两类框架的容错逻辑不同：

• .NET Framework的RijndaelManaged实现内置了自动补齐逻辑，传入长度不合法的密钥时，会自动用0x00补全到最近的合法密钥长度，你传入的12字节密钥会被自动补4个0x00到16字节使用，因此不会报错。
• .NET Core/.NET 5+移除了这项隐式补齐逻辑，密钥长度不合法时会直接抛出异常，避免开发者因隐式操作出现安全问题。

兼容解决方案 #

因为你无法修改.NET Framework端代码，只需要在.NET 5端手动模拟.NET Framework的密钥补齐逻辑即可，无需调整原有加解密流程的其他参数：

1. 替换原有密钥生成代码，手动把12字节密钥补全到16字节：

// 原有逻辑生成12字节原始密钥，原代码中Convert.FromBase64String(Convert.ToBase64String())为冗余操作，可直接省略
byte[] rawKey = Encoding.UTF8.GetBytes("qwertyuiopas");
// 模拟.NET Framework默认补齐规则，不足16字节的部分补0x00
if (rawKey.Length < 16)
{
    Array.Resize(ref rawKey, 16);
}
this.key = rawKey;

2. 其他加解密参数必须和.NET Framework端完全一致，包括：

• 加密模式（默认值为CipherMode.CBC）
• 填充模式（默认值为PaddingMode.PKCS7）
• IV值（如果用固定IV则两端完全相同，如果用随机IV需要把IV和密文一起传输给.NET Framework端解密）

3. 推荐在.NET 5中用Aes.Create()替代RijndaelManaged实例，该API为跨平台兼容实现，功能完全匹配，且无过时警告。

如果测试发现补齐后仍然无法解密，可以在.NET Framework端输出加密时实际使用的密钥值BitConverter.ToString(rijndaelInstance.Key)，拿到实际使用的16字节密钥后直接硬编码到.NET 5项目中即可100%兼容。

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