Что шифрование по умолчанию, имена файлов и незашифрованные записи всё ещё оставляют после отправки ZIP с паролем

Пароль на архиве — не замок на всём контейнере

ZIP с паролем легко принять за сейф: файл у кого угодно, без ключа внутри ничего не видно. Формат устроен иначе. Сначала ZIP — это каталог, потом список файлов. Флаг шифрования висит на локальном заголовке и на записи центрального каталога каждого файла. Он не висит на «целом файле .zip». Поставить пароль значит только то, что хотя бы один сжатый поток обернули каким-то алгоритмом. Это не значит, что каталог нечитаем, и не значит, что каждая запись взяла тот же алгоритм и ту же фразу.

Ведомости, сканы паспорта, закрытые ключи SSH, дампы базы и таблицы клиентов без маскирования не должны оставлять лишние открытые следы за пределами той папки, в которой вы сейчас работаете. Вопрос не в том, «умный ли архиватор». Вопрос: «не отдала ли эта упаковка открытое имя, открытую запись или слабый зашифрованный поток, которым не следовало покидать этот диск». В предыдущей заметке тот же класс передачи: незашифрованный файл в облаке всё ещё могут открыть провайдер, клиент синхронизации и хеш содержимого. Сначала ZIP с паролем, потом загрузка — вопрос только меняется: с «видит ли облако файл» на «какой слой этот контейнер реально закрыл».

Дальше опираемся на APPNOTE.TXT 6.3.10 PKWARE (1 ноября 2022), спецификации WinZip AES AE-1 / AE-2 и описание AES-256 в формате 7z у 7-Zip: слои там написаны так, что их можно сверить с локальным списком. Корпоративная политика, веб-страница «зашифровать ZIP» и старый интерфейс наложат ещё один слой. Сменив программу, снова откройте её пункты шифрования и посмотрите Method. Предложения про ZipCrypto ниже не переносите на архив, где уже выбран AES-256 или стоит галочка «Шифровать имена файлов».

ZipCrypto, расширение AES и шифрование имён — три разных слоя

Вопрос «ZIP зашифрован или нет» как да/нет отбрасывает как минимум три слоя. Первый — классическое шифрование PKWARE: в меню его часто подписывают ZipCrypto или Zip 2.0. Раздел 6 APPNOTE держит объект узко: PKZIP шифрует сжатый поток данных. У каждого зашифрованного файла в начале области данных лежит 12-байтовый заголовок шифрования. Три 32-битных ключа стартуют от пароля и дальше обновляются тем же CRC-32, который ZIP уже использует. Расширение по-прежнему .zip. Проводник или старый распаковщик часто покажут окно пароля. Совместимость хорошая. Стойкость — отдельный вопрос.

Второй слой — AES, который позже положили в тот же контейнер ZIP. WinZip не ломает базовую структуру и добавляет одно: метод сжатия становится десятичным 99, а в локальный заголовок и в центральный каталог кладут 11-байтовое дополнительное поле 0x9901 с идентификатором производителя — ASCII-буквами AE. Байты силы 0x01 / 0x02 / 0x03 означают ключи на 128, 192 и 256 бит. Настоящий метод (например, Deflate с кодом 8) переезжает в это поле. Старая программа, которая не понимает AES, обычно пишет «неподдерживаемый метод сжатия 99», а не принимает шифротекст за открытый текст. Этот слой закрывает содержимое файла. По умолчанию он не превращает имена в центральном каталоге в шифротекст.

Третий слой — «закрыть ещё и каталог». Strong Encryption в ZIP записывает шифрование центрального каталога как опцию и требует дополнительные флаги general purpose, например биты 6 и 13. У классического ZipCrypto этого слоя нет. Формат 7z идёт другой дорогой. На странице формата 7-Zip сказано: используется AES-256, ключ выводится из пароля функцией на SHA-256, большое число итераций поднимает цену полного перебора. Ключ командной строки -mhe=on шифрует имена файлов; в окне 7-Zip на русском это галочка «Шифровать имена файлов». Если её не включить, список всё равно может показать имена, даже когда содержимое уже на AES.

ZipCrypto: спецификация сама называет его слабым

Классическое шифрование — не «народная молва, что оно слабое». Владелец формата уже понизил его статус. APPNOTE 6.0.1 пишет: эта форма considered weak by today's standards и рекомендуется только для низкой защиты или для совместимости со старыми программами ZIP. В том же разделе скелет алгоритма: ключи стартуют как 32-битные числа 305419896, 591751049 и 878082192; update_keys на каждый байт пароля вызывает CRC-32; 12-байтовый заголовок в начале области данных продолжает перемешивать ключи; последние один или два байта заголовка сверяют со старшими битами CRC, чтобы решить, похож ли пароль на верный. Это потоковый шифр. Это не блочный режим с тегом подлинности вроде AES-GCM.

Спецификация ещё пишет, что 12-байтовый заголовок нужен, чтобы «сделать атаку по открытому тексту на данные неэффективной». Открытые исследования пошли другой дорогой. В 1994 году Эли Бихам и Пол Кохер опубликовали A Known Plaintext Attack on the PKZIP Stream Cipher: по известному отрезку открытого текста восстанавливается внутреннее состояние. Заметка Майкла Стея 2002 года ZIP Attacks with Reduced Known Plaintext снизила нужный объём открытого текста. В архивах часто лежат предсказуемые префиксы — %PDF, фиксированный заголовок Office, объявление XML, сигнатура PNG — потому что это форматы файлов, а не секреты. Шаги атаки сюда не входят. В вывод относится другое: слабое место — алгоритм, а не фраза «у вас пароль из шести символов». Более длинный пароль не переписывает факт: спецификация называет классическое шифрование слабым, и линия исследований по известному открытому тексту существует.

Совместимость объясняет, почему метод всё ещё жив. Проводник Windows умеет создавать и открывать обычный ZIP, но встроенного окна «поставить пароль на этот ZIP» у него нет. Независимый консультант на Microsoft Q&A написал: чтобы поставить пароль, нужна сторонняя программа вроде 7-Zip, а Проводник часто всё равно показывает окно на ZipCrypto-архивах, которые она собрала. Поэтому немало программ оставляют ZipCrypto по умолчанию: получатель дважды щёлкнет и откроет. Вы получаете «ему ничего не надо ставить». Платите слабым шифрованием, которое спецификация уже признала. 7-Zip умеет писать ZIP на AES-256. После этой смены системный распаковщик, который понимает только ZipCrypto, может отказаться открывать файл. Это выбор между совместимостью и стойкостью, а не «в обоих меню написано шифрование, значит одно и то же».

Имена, CRC и незашифрованные записи остаются открытыми

Даже когда слой содержимого переехал на AES, ZIP по умолчанию всё ещё контейнер, который можно просмотреть списком. Поле FileName в локальном заголовке и в центральном каталоге — открытый текст. Бит 0 general purpose значит только, что зашифрован поток данных этой записи. Бит 11 значит, что имя в UTF-8. Он не значит, что имя зашифровано. В 2004 году Тадаёси Коно в разборе схемы шифрования WinZip прямо назвал три факта формата: метаданные зашифрованных файлов утекают, имена не аутентифицированы, и один архив может одновременно держать зашифрованные и незашифрованные файлы. Это разрешённые формы контейнера, а не баги реализации.

Собственная заметка WinZip об AES записывает смешанный архив как официальное разрешение. Нет требования, чтобы каждый файл в ZIP был зашифрован, и нет требования, чтобы зашифрованные файлы делили один метод или одну фразу. Один архив может сочетать незашифрованные файлы с Zip 2.0, AES-128, AES-192 и AES-256 в любой смеси. Записи папок даже рекомендуют не шифровать, чтобы сэкономить место. На практике: кладёте в один пакет zarplata-2026-09.xlsx и readme.txt — пароль может спросить только таблица. Заметка и имена каталога читает любой, у кого файл. Получатель, почтовый шлюз, превью Яндекс Диска или Google Диска и клиент синхронизации часто видят этот список первым — не ячейки после удачной распаковки.

В открытом заголовке ещё лежат размер и контрольные суммы. WinZip пишет: AE-1 кладёт в заголовок ZIP контрольную сумму CRC незашифрованного содержимого, AE-2 записывает CRC как 0 и опирается на 10-байтовый код подлинности. В FAQ причина прямая: для файла в четыре байта или короче сам CRC помогает угадать исходник, каким бы шифрованием вы ни пользовались. Начиная с WinZip 11 большинство файлов снова идут как AE-1 ради дополнительной проверки целостности, но файлы короче 20 байт в несжатом виде и потоки BZIP2, у которых уже есть своя проверка, остаются на AE-2 и CRC не хранят. Вывод ключа — PBKDF2 (RFC 2898) на 1000 итераций; псевдослучайная функция — HMAC-SHA1. Спецификация ещё замечает: HMAC-SHA1 даёт 160 бит, поэтому эффективное пространство поиска для AES-192 или AES-256 нельзя читать как теоретическую длину ключа. Чтобы сверить эти числа, «взлом» не нужен. Они уже в открытой спецификации.

Проверка на месте: не извлекая исходник, смотрите Method и имена

Слоган «я поставил пароль, значит безопасно» сам себя не доказывает. Разбейте проверку на шаги, которые можно закончить на этом компьютере. Каждый шаг отвечает на один вопрос. Не ставьте опыт на настоящей ведомости, сертификате или закрытом ключе.

1. Напишите текстовую канарейку, чьё имя нарочно похоже на деловой документ, например canary-payroll-20260905.txt. Если нужен случайный пароль, возьмите 6–128 символов в генераторе паролей (по умолчанию 16; короче 8 сервис помечает как более слабую). Эту строку считайте только паролем архива, не новым паролем входа.
2. Соберите ZIP так, как обычно отправляете файлы: одни программы по умолчанию ставят ZipCrypto, другие просят выбрать AES-256. Не переименовывайте файл, чтобы «спрятать» тему. Соберите второй архив 7z — один раз с шифрованием имён, один раз без, чтобы сравнить.
3. Пока не вводите пароль. Откройте ZIP в 7-Zip или выполните в терминале 7z l -slt canary.zip. Появилось ли в списке canary-payroll-20260905.txt. Затем найдите строку Method =: ZipCrypto — классическое шифрование; AES-256 — AES на слое содержимого. Оба поля читаются без извлечения тела: они не сидят за фразой «сначала введите пароль».
4. Так же выведите список 7z. Без шифрования имён имя часто всё равно видно. С -mhe=on имя канарейки не должно появиться, пока не введёте пароль. Это проверка третьего слоя, а не утверждение «7z сам по себе таинственнее ZIP». Разница в том, закрыт ли заголовок каталога.
5. Положите канареечный архив в тот Диск или черновик письма, которым пользуетесь (никому не отправляйте). Смотрит ли превью или веб-интерфейс внутренние имена. В предыдущей заметке мгновенная загрузка и превью на незашифрованном файле требуют исходник; здесь, даже если содержимое закрыто, имена каталога всё равно могут попасть в индекс. Когда закончите, удалите архив-канарейку и исходник и проверьте Корзину.

Первая половина локальной проверки шифрования — не отдала ли вкладка открытый текст серверу — другой вопрос, чем Шифрование в браузере: как убедиться, что исходный текст не покинул устройство. Архиватор почти всегда должен прочитать исходник на этом компьютере, чтобы упаковать. Здесь спрашивается, что остаётся после упаковки вне потока шифротекста. Если имя канарейки всплыло в 7z l -slt или в превью Диска до ввода пароля, граница доверия шире, чем «у того человека нет пароля». Если Method всё ещё ZipCrypto, вы купили совместимость, а не стойкое шифрование в смысле спецификации.

Отделите шифротекст целого файла от пароля на архиве

Если нужно «сначала превратить этот файл в шифротекст на устройстве, потом решить, пойдёт он почтой или на Диск», регистрироваться не надо и файл MakePwd не отдаёте. Откройте шифрование файлов. Текущая вкладка шифрует блоками AES-256-GCM и даёт скачать .lock или .enc. Пароль растягивается PBKDF2-HMAC-SHA256 на 100 000 итераций; у каждого файла свой salt. Один файл — до 5 ГБ. Файл, пароль и открытый текст не уходят как рабочие данные. Всеми инструментами можно пользоваться без аккаунта; хранилища паролей, которое берегло бы фразу за вас, нет.

Шифрование файлов отвечает на вопрос «стали ли эти байты шифротекстом, пока не покинули браузер». Оно не отвечает «закрывает ли ZIP имена по умолчанию». Имя скачивания выбираете вы, поэтому не обязательно отправлять что-то вроде zarplata-2026.xlsx.zip, которое само сдаёт тему. В заголовке .lock исходное имя всё ещё может лежать; если само имя чувствительно, переименуйте файл до шифрования. Шифротекст может ехать через Диск или почту. Пароль отправьте другим каналом — например одноразовой ссылкой: ключ лежит во фрагменте URL #, с HTTP на сервер не уходит, создание и чтение открыты, сервер хранит только шифротекст. Когда нужна случайная фраза, возьмите 6–128 символов в генераторе паролей и скопируйте только на той странице. Что провайдер всё ещё видит после загрузки без шифрования — предыдущая заметка. Здесь только проведена граница: что ZIP с паролем всё ещё может оставить.

Частые вопросы

Если у ZIP есть пароль, зашифрован ли весь архив?

Нет. В APPNOTE PKWARE флаг шифрования стоит на бите 0 поля general purpose у каждого файла. Этот бит закрывает сжатый поток именно этой записи, а не контейнер. Имена лежат в локальном заголовке и в центральном каталоге. В заметке WinZip об AES сказано: один ZIP может смешивать незашифрованные записи с Zip 2.0, AES-128, AES-192 и AES-256, и пароли могут быть разными.

Чем ZipCrypto отличается от ZIP с AES-256?

ZipCrypto — классическое шифрование PKWARE из раздела 6 APPNOTE: три 32-битных ключа, 12-байтовый заголовок шифрования и обновление ключей через CRC-32. Спецификация сама называет его слабым по сегодняшним меркам и оставляет для низкой защиты или старых программ ZIP. WinZip AES использует дополнительное поле 0x9901, метод сжатия 99, соль, проверку пароля и код подлинности HMAC-SHA1. Расширение у обоих .zip: смотрите Method, а не суффикс.

Можно ли увидеть список файлов без пароля?

Обычно да — у классического ZIP и у 7z, где не включили шифрование имён. Команда 7z l -slt в 7-Zip показывает имена и Method, не извлекая открытый текст. Формат 7z умеет шифровать имена ключом -mhe=on; именно этот слой закрывает заголовок каталога. У Проводника Windows нет встроенного окна «поставить пароль на ZIP».

ZIP с паролем — это то же самое, что шифрование файлов MakePwd?

Нет. Пароль архива отвечает, какой шифр ZIP применил этот контейнер. Шифрование файлов закрывает весь файл в этой вкладке AES-256-GCM, пишет .lock / .enc, ограничивает один файл 5 ГБ, не загружает файл и пароль и открывается без аккаунта. Пароль отправьте другим каналом, например фрагментом # одноразовой ссылки.

Три вещи, которые стоит помнить перед следующим архивом

Первое: «я поставил пароль» значит только то, что хотя бы один поток данных обернули каким-то шифрованием ZIP. Это не значит, что каталог нечитаем, и не значит, что зашифрована каждая запись. Второе: ZipCrypto (спецификация называет слабым; линия исследований по известному открытому тексту есть), WinZip AES (сильнее на содержимом; имена по умолчанию остаются открытыми) и шифрование имён в 7z — три разные границы. Расширение .zip или .7z не говорит, на каком вы слое. Третье: сверяйте Method и имена, которые видны до пароля, одноразовой канарейкой и 7z l -slt. Не ставьте эту проверку на настоящей таблице.

Если следующий вопрос — что провайдер всё ещё видит после того, как незашифрованный файл попал на Диск, читайте Что провайдер облака, клиент синхронизации и хеш файла всё ещё могут увидеть после загрузки незашифрованного файла. Когда сам шаг шифрования должен доказать, что открытый текст не покинул устройство, читайте Шифрование в браузере: как убедиться, что исходный текст не покинул устройство. Когда пароль нужно отдать отдельно и не хотите класть его в тело письма, читайте Почему ключ после решётки в URL удобно класть и когда эта защита ломается. Здесь только сведена в вывод граница: после отправки ZIP с паролем что ещё могут оставить шифрование по умолчанию, имена файлов и незашифрованные записи.