AES/CBC/NOPC在C#和Java之间添加

我在C#和Java中使用了一些加密函数，它们的输出似乎不匹配。我用和测试一样的钥匙和IV线来喂

输入字符串：“&app_version=1.0.0.0”

爪哇：

输出：

60f73a575b647263d75011bb974a90e85201b8dfeec6ec8ffba04c75ab5649b3

4b6fd83c35565fc30a9ce56134c277cbea74d14886cf99e11f4951075d4f4505

C#：

输出：

60f73a575b647263d75011bb974a90e85201b8dfeec6ec8ffba04c75ab5649b3

4b6fd83c35565fc30a9ce56134c277cbea74d14886cf99e11f4951075d4f4505

我正在使用Java解密程序进行检查，它正确地解密了Java加密字符串，但C#字符串被读取为“&app#u version=1Q0.0.0”，因此它看起来很接近，但有点偏离

在加密步骤之前，我已经检查了密钥、输入和IV的字节是否匹配。是否存在其他可能导致差异的差异

编辑 使用所有的零键“00000000000000000000”和IV“0000000000000000”，我得到了Java和C#的相同输出：

---

所以，也许你正在读的钥匙或IV有问题…

我觉得自己像个傻瓜…我的IV一个是零，另一个是大写字母O！！好吧，至少我知道这段代码是等效的。

你能发布java代码和C代码的输出数据吗？在CBC模式下解密时添加的输出和期望值与实际值（无填充）仅在输入大小是块大小的倍数（16字节，128位）时有效。您能验证数据大小是否正确吗？如果提供非标准的输入数据，密码的行为可能是意外的。此外，为了排除故障，请尝试使用全零IV。我正在填充，以便输入是16的倍数。我尝试了0的键和IV，得到了相同的输出，将添加到原始问题中，通过将键设置为“正常”值（将IV保持为零）进一步缩小它。如果它产生不同的值，请在CBC内部与ECB重试。我对C不太熟悉，但代码在逻辑上似乎很合理。哈哈！至少你发现了你的问题。当你说钥匙没问题时，我怀疑IV或C的AES实现有问题。

081821ab6599650b4a31e29994cb130203e0d396a1d375c7d1c05af73b44a86f