Java AES 解密带有错误标头的 zip 文件
当我解密 zip 流时，我遇到了一个奇怪的问题。
解密给定的流后，除了 8 个字节的标头之外，我得到了完全相同的字节数组。
它应该是 50 4B 03 04（根据 Zip 规范），但我得到了不同的结果。
当我在 C# 中解密相同的流时，标头是正确的。我使用 RijndaelManaged、模式 CBC、填充 ZeroBytePadding 和块大小 = 128
在 Java 中，我使用 AES/CBC/NoPadding 块大小 = 128 进行解密。
我相信原因是填充，但我不明白为什么其余字节是正确的。
I faced a strange issue when I am decrypting a zip stream.
After I decrypted the given stream I have exactly the same array of bytes apart from 8 bytes of header.
It should be 50 4B 03 04 (according to Zip spec) but I get different.
When I decrypt the same stream in c# the header is correct. I use RijndaelManaged, mode CBC, padding ZeroBytePadding, and block size = 128
In Java I use AES/CBC/NoPadding block size=128 to decrypt.
I believe the cause is padding but then I don't understand why the rest of bytes are correct.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在 CBC 模式下，填充模式应该只影响消息的最后一个字节，而不是第一个字节（即从 ZeroBytePadding 到 NoPadding，您可能会在末尾添加一些 0 字节）。
如果您的第一个块不同（但其余块匹配），最可能的原因是加密和解密中的初始化向量不同。检查一下。
In CBC mode, the padding mode should only affect the last bytes of your message, not the first ones (i.e. from ZeroBytePadding to NoPadding you might get some added 0 bytes at the end).
If your first block is different (but the rest matches), the most probable cause is a different initialization vector in encryption and decryption. Check this.