Почему ZIP APPNOTE на сайте PKWARE не упомянул правильный механизм проверки пароля в своей спецификации?

Question

Я читаю устаревшее PKWARE password check mechanism в APPNOTEs доступны.В конце раздела 6.1.6 Расшифровывая заголовок шифрования , абзац гласит следующее:

После расшифровки заголовка последний 1 или2 байта в буфере ДОЛЖНЫ быть старшим словом / байтом CRC для дешифруемого файла, хранящегося в младшем / старшем порядке Intel.Версии PKZIP до 2.0 использовали 2-байтовую проверку CRC;1-байтовая проверка CRC используется в версиях после 2.0.Это можно использовать для проверки правильности введенного пароля.

В вышеприведенном абзаце упоминается только проверка 1 или 2 байта с помощью CRC, но не упоминает , чтоэто также может быть проверка для 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 не упомянул вышеупомянутую информацию?

Answer 1

Соответствует ли linux zip 3.0 стандарту PKWARE APPNOTE или PKWARE не упоминал о приведенной выше информации?

И то, и другое верно.PKWARE не считает необходимым добавлять сторонние изменения в свой стандарт.Но спасибо, что нашли документацию об этом байте метки времени.У меня были некоторые головные боли по этому поводу для моей собственной реализации, прежде чем я понял, заглянув в исходный код Info-Zip, что они заменили байт CRC байтом метки времени (кстати, хорошая идея).