» WinRAR (часть 2)

Цитата:

Странная статья. http://habrahabr.ru/company/dsec/blog/216785/

Почему странная? Обычная статья.
Баг есть и проявляется в версии 4.20, в 5 версии его нет.

Метод сжатия файлов в архиве никак не влияет на стойкость шифрования?

franzykman

Цитата:

Метод сжатия файлов в архиве никак не влияет на стойкость шифрования?

А какая между ними должна быть связь? Математических ограничений на использование алгоритмов шифрования битового потока я пока в научных работах не видел, а если какой-то человек их выскажет, то пусть и обоснует их с выкладками и математически строгими доказательствами своей гипотезы. А пока таких доказательств нет это только предположение из серии "Насколько данное явление реально?", но не более того.

Victor_VG
Да я и не претендую на новизну: так, спросил, вдруг метод "Без сжатия" и с маленьким словарем делает архив более уязвимым.

franzykman

А с какой стати? Криптоалгоритм получает на вход бинарный поток и работает с ним не зависимо от его содержимого. Сжатие и шифрование сиречь разные материи и вроде им негде пересекаться.

franzykman

Цитата:

вдруг метод "Без сжатия" и с маленьким словарем делает архив более уязвимым

Метод "Без сжатия" при нешифрованном имени файла может дать информацию о части данных в начале файла. Но AES считается устойчивым к known plaintext attack, и до тех пор, пока не доказано обратное, метод "Без сжатия" не делает архив более уязвимым. Размер же словаря при сжатии на стойкость шифрования никак не влияет.

EugeneRoshal

Женя можно вас попросить в changelog библиотеки UnRAR пометить что изменилось в версии 5.10 по сравнению с 5.0.1. А то там этой информации сейчас нет. Это не сильно торопит, но наверное если они есть, то стоит указать общие изменения.

EugeneRoshal
Уважаемый Евгений! Раз уж вы нас опять посетили не могли ли бы хоть парой слов прокомментировать вот это. Или, если где-то уже отвечено, то поделиться ссылкой. А то неуютно как-то: такую дыру нашли (??), а уважаемый автор отмалчивается...
Заранее спасибо!

Цитата:

прокомментировать вот это

В 4.20 была такая ошибка. В 5.0 в числе прочего работа с zip тоже была частично переделана, в связи с чем в 5.x такой ошибки больше нет.

Добавлено:

Цитата:

Женя можно вас попросить в changelog библиотеки UnRAR пометить что изменилось в версии 5.10 по сравнению с 5.0.1.

Существенных изменений, влиящих на API, там нет. Такие изменения я упоминаю в whatsnew.txt.

Я для порядка в каждой версии пересобираю unrar и unrar.dll из свежих исходников. В принципе, код распаковки достаточно устоявшийся, и в нем какие-то значительные изменения бывают редко. Но все равно свежая версия может включать мелкие оптимизации и исправления, так что по возможности имеет смысл обновляться. Только не на бету, а на релиз.

EugeneRoshal

Понял, вопрос снят.

Winrar 5.01 ru не распаковывает этот cab
http://www.tightvnc.com/download/2.7.10/tightvnc-2.7.10-setup-32bit.msi ,
пишет, что "Архив повреждён"
7z 9.20 успешно распаковывает и тестирует архив. (нужный мне файл)
я конечно понимаю, что msiexec /a tightvnc-2.7.10-setup-32bit.msi /qb TARGETDIR=%tmp%\tvnc, но всё же.

ptitza_in_da_ruboard

Есть такое. Это просто нестандартная БД, но её прекрасно берёт плагин Far Observer.

Как сделать так, что бы это сообщение не появлялось через командную строку? a -inul
-inul в данном случае не помогает

franzykman:


Цитата:

вдруг метод "Без сжатия" и с маленьким словарем делает архив более уязвимым.

Естественно, делает. Известные размеры файлов -- уже компрометация. А тут ещё и "родное" распределение зашифрованных блоков...

Избыточность данных -- альфа и омега криптоанализа, на неё больше всего рассчитывает взломщик. Поэтому любой более-менее серьёзный процесс шифрования начинается с упаковки данных, дабы снизить избыточность. Евгений уже ответил, что в AES есть средства против такого анализа. Но это детали реализации и сегодняшнего состояния дел (которого мы достоверно и не знаем). А теория стоит на своём: не хочешь давать взломщику дополнительную информацию, помогающую при расшифровке -- запакуй шифруемый поток.

Другое дело, что кроме метода "без сжатия" есть много других, любого из которых достаточно для сокрытия избыточности данных для целей шифрования.

ПС: Не разбирался, что там изменилось в новой версии с проверкой пароля. Но, судя по предыдущим постам, там есть какие-то дополнительные средства, позволяющие проверить верность пароля без полной распаковки. Этот довесок (чексум, хэш или ещё что) добавляет ту же самую избыточность, очень полезную для взлома...

ptitza_in_da_ruboard

Цитата:

Winrar 5.01 ru не распаковывает этот cab

CAB является частью MSI, но все-таки MSI это не CAB. WinRAR для работы с CAB использует MS cabinet.dll, а ей, похоже, не нравится, что после данных CAB присутствуют дополнительные данные. Другими словами, работать с MSI WinRAR не обучен.

Pasha_new

Цитата:

-inul в данном случае не помогает

Сейчас выложил на rarlab.com новую сборку английской beta 1. В ней -inul должен отключать это сообщение.

Добавлено:
chAlx

Цитата:

Этот довесок (чексум, хэш или ещё что) добавляет ту же самую избыточность, очень полезную для взлома.

Медленный односторонний хэш - несколько дополнительных циклов PBKDF2 после завершения основного цикла вычисления ключа. Этот хэш мог бы помочь ускорить brute force attack, но скорость его вычисления достаточно низка, чтобы сделать такую атаку неэффективной при разумной сложности пароля.

Перебиралки паролей и без этого хэша, с помощью эвристик, справлялись с проверкой пароля. Так что от этого хэша требовалось только, чтобы его вычисление не было быстрее, чем вычисление ключа шифрования.

EugeneRoshal:

Цитата:

Перебиралки паролей и без этого хэша, с помощью эвристик, справлялись с проверкой пароля. Так что от этого хэша требовалось только, чтобы его вычисление не было быстрее, чем вычисление ключа шифрования.

Зато хэш, в отличие от эвристик, считается за фиксированное время и с гарантированной точностью результата :)

Не, я не спорю: решение на сегодня выглядит достаточно надёжным. Просто к слову пришлось, раз уж речь про теорию зашла. Да и старый RAR вызывал детскую радость от вида распакованной каши байт после подбора пароля: "Просили -- получите!" Можно внутрь него запихать какой-нибудь неугадываемый контент приличного размера и быть уверенным, что перебор паролей займёт время, кратное единичной распаковке. И ещё не факт, что результат будет верным (там, вроде, CRC такого размера, который может и коллизию выдать)...

Но всё же RAR -- это архиватор, а не криптопровайдер (несмотря на использование его в таком качестве некоторыми варезниками и спецслужбами). Так что имеющихся средств обывателю хватает с головой -- за них спасибо.

chAlx

Цитата:

Можно внутрь него запихать какой-нибудь неугадываемый контент приличного размера и быть уверенным, что перебор паролей займёт время, кратное единичной распаковке.

Я, конечно, перебиралки паролей не писал, но крайне сомневаюсь, что они выполняют полную распаковку файла. Тогда подбор паролей к гигабайтовому файлу шел бы со скоростью 5 паролей в минуту.

Скорее всего расшифровываются несколько блоков в начале и проверяются на похожесть на rar'овский упакованный формат. Такая проверка может выполняться за фиксированное и очень небольшое время. Защита от такого перебора это медленная установка ключей, а дополнительный хэш, если он не быстрее установки ключей, на скорость перебора практически не влияет.

WinRAR 5.10 beta 2
Bugs fixed:
a) when processing nested archives, WinRAR could attempt to open inner archive as self-extracting instead of opening an outer archive. It happened if inner archive was stored without compression and outer archive name had non-standard extension;
b) Unix RAR could not decompress hard links stored by WinRAR if link source name included path separator characters.

SAT31

v5.10b2 ru-RU

Цитата:

Версия 5.10 бета 2

1. Исправлены ошибки:

а) при обработке архивов, вложенных один в другой, вместо открытия внешнего архива WinRAR мог пытаться открыть внутренний архив как самораспаковывающийся. Это происходило, если внутренний архив был сохранён без сжатия, а внешний архив имел имя с нестандартным расширением;

б) RAR для UNIX не мог извлекать из архивов жёсткие ссылки, созданные WinRAR, если в исходном имени ссылки присутствовали символы-разделители пути.

ждёт своих пользователей.

EugeneRoshal
Уважаемый Евгений!
Можно ли каким-либо образом сохранить настройки SFX модуля для последующего использования?

Я, к примеру, настроил SFX: title, icon, license text, several shortcuts, run command, and so on. Каждый раз выставлять все эти значения во множестве вкладок несколько напрягает, особенно если создавать такой архив требуется часто. Я, конечно же, могу сохранить все эти настройки в текстовый файл, но все равно нужно их каждый раз выставлять вручную во множестве вкладок SFX options.

Поэтому вопрос, можно ли эти настройки как-либо сохранить, чтобы потом их можно было загрузить "одним щелчком мыши", а не выставлять их вручную?

ItsJustMe

Есть такой приём, сам им пользовался: настраиваю всё что мне надо, после иду на вкладку Комментарий, копирую его в текст, и когда надо вставляю готовый комментарий через ту же вкладку. Остаётся только подкорректировать мелочи - почти вся работа уже сделана.

Victor_VG
О! Понял, спасибо!

ItsJustMe

Чем богаты.

P.S.

Побрёл кофе пить. Вкусный, свежареный, с коньячком и лимоном.

Подскажите, можно ли проблему решить без замены винрара на другой архиватор. Зип архивы, созданные винраром невозможно обновить через арклайт плагин для фара. Как так и что с этим делать?

hooddy

Я бы сначала посмотрел две вещи: не заблокирован ли файл иным процессом - в этом случае арклайт создаст его переименованную копию при обновлении; и что не менее важно методы используемые при упаковке данного архива. Пока кроме общих подсказок где и что посмотреть ничем помочь не могу - я не знаю что у вас за архив и вынужден опираться на собственный опыт.

hooddy

Цитата:

Зип архивы, созданные винраром невозможно обновить через арклайт плагин для фара.

Я арклайтом не пользуюсь, что именно ему не нравится - не знаю. Но, возможно, имеет смысл попробовать выключить "High precision modification time" на странице "Time" диалога архивации при создании zip архива в WinRAR. Может плагину NTFS extra field в ZIP архиве не нравится.

EugeneRoshal

На это он обычно не обращает внимания. Сам бы проблемный архив увидеть и может быть мы бы узнали где возникает сбой. Жаль что автор уже более года плагином не занимается (может некогда?) и накопление выявленных ошибок в нём явление известное. Да, их исправляют, но часть ошибок пока ждёт своего исправления на Мантисе.

EugeneRoshal
Bug:

Условия:
а) Winrar 5.01, 5.1b1 (x32, x64)
б) win 8.1 x64
в) запуск с ключом -as
г) архивирование папки c:\windows

1) winrar u -as -r -dh w.rar c:\windows\
2) winrar u -as -r -dh w.zip c:\windows\

В 1 случае процесс прерывается с ошибкой - "! Ошибки при поиске файла, архив синхронизировать невозможно"
Во 2 случае процесс отрабатывает до конца.
Если ключ -as убрать ошибка не появляется.

Dook

Правильно, вы забыли что часть файлов заблокирована ядром ОС, а выполняемая операция требует повышенных привилегий, к примеру Backup and Restore Privileges, кроме того формат контейнера Zip не поддерживает симлинки, хардлинки, точки соединения и потоки - они пропускаются, а в контейнере Rar также как в контейнере UNIX архиватора Tar это нормальные данные, а вы пытаетесь получить точную копию фрагмента файловой системы часть данных в которой не доступна при текущем уровне привилегий пользователя, отсюда и сообщение о невозможности выполнить требуемую операцию в полном объёме.