为什么PKWARE网站上的ZIP APPNOTE没有在其规范中提到正确的密码检查机制？

Posted 2021-04-07

我一直在阅读password check mechanism中的PKWARE遗产APPNOTEs。在6.1.6节解密加密标题的末尾，该段落声明如下：

在解密头之后，缓冲区中的最后1或2个字节应该是被解密文件的CRC的高位字/字节，以英特尔低字节/高字节顺序存储。 2.0之前的PKZIP版本使用2字节CRC校验;在2.0之后的版本上使用1字节CRC校验。这可用于测试提供的密码是否正确

上面的段落只提到了CRC的1或2字节检查，但没有提到它也可以检查last mod file time而不是CRC，基于bit 3的general purpose bit flag。

我使用默认的zip 3.0在linux机器上使用Traditional PKWARE Encryption加密了一个文件，经过以下的解密过程后，我意识到应该用last mod file time而不是CRC检查最后一个或两个字节，以检查密码是否正确。

在网上搜索了一段时间之后，我才发现这个版本的APPNOTE实际上描述了CRC或last mod file time的检查，取决于bit 3的general purpose bit flag。

linux zip 3.0不遵循PKWARE APPNOTE标准或PKWARE没有提到上述信息吗？

答案

linux zip 3.0是不符合PKWARE APPNOTE标准还是PKWARE没有提到上述信息？

两者都是真的。 PKWARE并不觉得有必要在其标准中添加第三方更改。但是，感谢您找到有关此时间戳字节的任何文档。通过查看Info-Zip的源代码，我们已经通过时间戳字节替换了CRC字节（顺便说一句，这是一个好主意）之前我对自己的实现感到头疼。