На днях получил письмо от читателя моей статьи "К вопросу о запароленных архивах, или Читайте постскриптум, батенька!" из CompDocs#14. Изложенные в письме мысли, безо всяких сомнений, имеют отношение к делу. Но суть ведь в том, что в той статье речь шла не столько о способах взлома запароленных архивов, сколько о взломе путем "грубого" перебора паролей (метод звлома различных систем путем перебора паролей называется брутфорсом: brute force - грубая сила прим. ред.). Точнее - о препятствиях на тернистом пути взломщика-перебориста. В любом случае, спасибо читателю за письмо. Оно-то и натолкнуло меня на написание этой статьи :)

Отбросим абстракцию, и поговорим о конкретике. Например, о WinZip. О самой последней версии - 9.0. В ней полно нововведений по части шифрования. В частности, WinZip 9.0 "поддерживает шифрование со 128- и 256-битовым ключом по алгоритму AES, который обеспечивает намного более высокую степень защиты, чем ставший уже традиционным метод Zip 2.0, использовавшийся в более ранних версиях".

Обратимся к описанию использованной в архиваторе спецификации шифрования по алгоритму AES с официального зипного сайта.

- - - - - - - -
Величина для верификации пароля (Password verification value, всюду далее - PVV).
Эта двухбайтовая величина вычисляется в процессе получения ключей для шифрования/дешифрования по паролю. При шифровании, PVV вычисляется по шифрующему паролю и сохраняется в зашифрованном файле. Перед дешифровкой PVV можно вычислить по дешифрующему паролю и сравнить со значением, сохраненным в файле. Т.о. возможна быстрая проверка, которая отлавливает большинство, но не все, неверные пароли. 1 против 65536, что неверный пароль даст верное PVV. Следовательно, совпадение PVV не дает гарантии того, что пароль - верен.
- - - - - - - -

Какой отсюда можно сделать вывод? Взлом по PVV в 1 случае из 65536 (в среднем) будет сигнализировать об успешной попытке, которая, скорее всего, не является таковой. Безусловно, перебор возможных паролей будет идти быстро. И те пароли, для которых PVV окажется неверным - неверны. А вот те, которые "вроде бы полу-верны"... По этому поводу - читаем спецификацию дальше.

А это - сюрприз в новой версии. CRC исходных файлов заменен на "Authentication code" зашифрованных. А это означает, что, определив множество "полу-верных" паролей на основании анализа PVV, дальнейшую автоматизацию выполнить очень сложно. Почитаем еще немного, чтобы понять причины, вынудившие разработчиков поступить именно так.

- - - - - - - -
В криптографических кругах сегодня устоялось мнение, что аутификация обеспечивает повышенную безопасность, т.к. она делает некоторые атаки более сложными в реализации ...
Применение CRC-32 обладает таким недостатком: для очень маленьких файлов, с размером 4 байта и меньше, значение CRC-32 можно использовать, отбросив алгоритм шифрования, чтобы определить незашифрованное содержимое файла. Поэтому файлы, зашифрованные согласно AE-2 (Encryption Specification AE-2 - А.Р.) используют код аутификации вместо CRC-32 для проверки неповрежденности данных ...
- - - - - - - -

Вот так-то. А логика ведь - железная. Кому нужен CRC незашифрованных файлов, если по коду аутификации можно установить неповрежденность данных, а по PVV - корректность пароля? Известно кому. Тем, кто эти архивы хочет поломать. Чтобы, отталкиваясь от PVV, продолжать перебор паролей. Так что, кто был :-E, тот стал :-F.

Поэтому при взломе архива в формате WinZip 9.0 размер архива оказывается несущественным. А существенной оказывается высокая сложность автоматизации "нормального" процесса перебора паролей. Т.е. разработчики, отбросив использование CRC исходных данных, переложили сложность процесса взлома с плеч компа (долгий и нудный простой перебор, размер архива - существенен) на голову взломщика (человека, которому придется по заранее неизвестным критериям отсеивать неверные пароли из тех, для которых PVV оказалось верным). Но это только в последней версии. Предыдущие версии архиватора использовали и другой алгоритм шифрования, и CRC.

Вот только не все так безоблачно, как может показаться на первый взгляд. И старая и новая версия защиты данных в WinZip могут оказаться беспомощны перед следующим пустячком. Допустим, в архиве находится "гиперсекретный" rar-файл. Ну очень секретный... И размер большой - несколько гигов... И шифрование с 256-битным ключом... Казалось бы - все в порядке. Но. ЭТО ФАЙЛ СТАНДАРТНОГО ФОРМАТА И КАЖДЫЙ ЛАМЕР ЗНАЕТ, ЧТО RAR = "Rar!...", т.е. первые четыре байта расшифрованных данных НАПЕРЕД ИЗВЕСТНЫ. А 4 байта - это 32 бита. А пароль, правильно дешифрующий 32 бита, с очень высокой вероятностью является правильным паролем. Поэтому перебор паролей можно производить, абстрагируясь от всего архива, и расшифровывая только первые 4 байта данных. Если получено "Rar!" - можно считать, что дело в шляпе. То же можно сказать и о файлах других распространенных форматов - в начале таких файлов, как правило, стоит подпись длиной в 2 и более байт.

Поэтому для повышения безопасности хранения данных в зашифрованных архивах необходимо соблюдать одно из следующих правил:
1) перед архивацией у всех важных файлов убирать расширения
2) архивировать с шифрованием также и имен файлов

Первое правило может породить ряд неудобств. Понятно почему. Поэтому предпочтительнее использовать второе правило.

P.S. Кстати, WinRar 3 (точнее, начиная с версии 2.9 прим. ред.) также использует алгоритм AES (со 128-битным ключом). В связке с CRC-32, а не кодом аутификации. Поэтому при взломе запароленного rar-архива с зашифрованными именами файлов придется-таки расшифровывать данные целиком, чтобы можно было в автоматическом режиме проверять верность пароля, сравнивая значение CRC. Из-за этого при взломе rar-архивов размер оказывается существенным.

Александр Рябов. Сентябрь 2004, Украина.
ryabov@ua.fm

Ссылки по теме:

Математико-физический уголок

К вопросу о запароленных архивах...