Шифрование в rar
Здравствуйте!
Читаю много очень умных вещей. Интересно, но порой сложновато. Можно несколько прозаичнее и чуть ближе к обычным пользователям, не использующим специальные программы? Скажите, насколько стоек симметиричный алгоритм шифрования реализованный в архиваторе rar и какой там алгоритм используется? Я читал, что AES-128 или наш ГОСТ? Сколько надо часов крутой прикрутой машине, что бы открыть архив?
Ссылки
[link1] http://www.win-rar.com/index.php?id=24&kb_article_id=51
[link2] http://www.rarlab.com/rar/unrarsrc-3.5.4.tar.gz
[link3] http://www.pgpru.com/forum/viewtopic.php?p=3633#3633
[link4] http://www.securitylab.ru/forum/read.php?&FID=29&TID=19635&MID=219931#message219931
[link5] https://torproxy.net/index.cgi/101100A/http/624eb2rznzhtq2cz.onion/hiddenhosting/777/index.html
[link6] https://www.pgpru.com/biblioteka/statji/sekretnostjbezopasnostjnejasnostj
[link7] https://www.pgpru.com/comment19967
Новые версии используют AES-128 (вроде как. Исходники RAR'а закрыты, проверить это непросто). Но дело в том, что использование лучших криптографических примитивов само по себе не даёт никаких гарантий стойкости. Ошибка может крыться в их реализации, во взаимодействии с любым из компонентов программы, где угодно. Только свободный общественный анализ исходных текстов программы способен выявить такие недоработки. Взломщику же достаточно нащупать любой. Было в истории множество примеров, когда ломались программы, использующие самые стойкие шифровальные схемы.
Полным перебором? Простая комбинаторика, можете сами подсчитать. Миллиарды лет. Криптоанализом и поиском бреши — от дней, недель и месяцев до нескольких лет, в зависимости от затраченных усилий. Только кому это нужно, когда элементарная машина под названием утюг электрический может получить этот ключ из Вас за пару часов?
"Что, умный, интернет у тебя есть, можешь узнать, что угодно? Неее, чтобы всё узнать, нужен не интернет... Нужен утюг." © КВН ;)
Хорошо, что интересно. Если возникает интерес к какой-то теме. то сложности преодолеваются легче.
Может все-таки не стОит использовать для шифрования "обычные" программы с закрытым исходным кодом?
И где шифрование приутствует просто как дополнительная возможность. У таких программ не может быть репутации
по определению.
Ампула с цианидом решит все ваши проблемы. ;-)
P. S.
Чуть подальше от обычных пользователей, использующих неспециальные программы: ;-)
Понимаю, что Oleg_Malcev'у это пока не пригодится, но вдруг заинтересует кого-то еще:
Вот так все должно выглядеть в идеале.
Архиватор должен архивировать. Шифровать должна другая программа.
И не надо ломать голову над тем, какой в закрытом архиваторе алгоритм.
Вообще-то господа на счет закрытых исходников это мягко говоря неправда. Исходники распаковщика открыты, формат файла тоже известен, никаких явно видимых дыр там нет. В части шифрования 3-й рар является наверно самым надежным архиватором, действительно используется реализация AES-128, для установки ключа из пароля используется 262144 итераций SHA-1, c подмешиванием random-ного salt, чтоб не возможно было создать предпросчитанный словарь из ключей. Таким образом если идет перебор паролей (bruteforce, словарь) – то скорость не более 10-ка в секунду.
Если ключей к AES – пространство 2^128. Вобщем остается только человеческий фактор (выбор короткого пароля или пароля из словаря).
Вот можете посмотреть: http://www.rarlab.com/rar/unrarsrc-3.4.3.tar.gz
В кратце установка ключа:
Если нет доверия к тем реализациям – можете прогнать Rinjdael и SHA-1 на тестовых векторах.[/code]
Ну почему неправда? Неполное раскрытие исходников программы – это не более чем коммерческий трюк. Просто чтобы и пользователей успокоить и продажу программы сохранить.
Предположим, мы хотим создать криптопрограмму с отмычкой. Можно сделать утечку битов ключа через векторы инициализации или еще какой-нибудь трюк применить. Если исходники открыты не полностью, это будет трудно заметить.
Все тестовые векторы совпадут, реализация будет внешне выглядеть вполне корректной.
Из числа наиболее распространенных – возможно. Были попытки сделать и полностью open-source архиваторы с шифрованием под WIN, но они не получили распространения, потому что сам формат архивов должен быть распространен среди пользователей.
Хотя...
Вспомните недавний успех программы TrueCrypt. Появляется бесплатная и открытая программа и тут же обходит всех коммерческих конкурентов. Рано или поздно так произойдет со всеми часто используемыми программами – браузерами, архиваторами и т.д. А уж с программами шифрования и подавно.
Для закрытых программ останется только ниша больших пакетов для графики, моделирования и т.д.
Допустим там все реализовано правильно. Но при прочих равных условиях, все равно лучше использовать ПОЛНОСТЬЮ открытую программу.
Все-таки RAR это прежде всего архиватор, а не программа для шифрования. И
к нему нельзя подходить с критериями для подобных программ и никто не ведет речь о замене RAR-ом некоего продукта для шифрования. 99% вопросов
связанно с криптоанализом RAR и звучат как – "у меня есть архив с паролем – как его сломать?" Т.е. в данном случае все-же первична возможность взлома.
А не наоборот стойкость.
Кстати на счет совпадения тестовых векторов – никто не мешает взять доверенную реализацию этих алгоритмов и сформировать тестовые векторы с рандомного ключа и рандомного plaintext. И если уж и они совпадут – то извините крыть нечем. ;)
Вот вот, rar и zip никуда не денутся из нашей жизни, что-бы там не появилось.
;) Каких?
Вообще-то все (утрированно) комерческие программы такого плана умеют:
1) работать с токенами (причем не с одним а эдак штуками с 10-ю).
2) работать с смарткартами и ридерами оных.
3) умеют шифировать весь диск при старте системы.
Т.е. никакого "обхода" пока особо не заметно. Разве чт о конкуренция PGPdisk.
Что и требовалось объяснить начавшему этот топик.
Речь шла как раз о том, что это не так. Есть "случайно" выбираемые векторы инициализации для режима шифрования (не путать с тестовыми векторами), есть контрольные суммы (саму сумму изменить нельзя, но подогнать под нее содержимое блока можно), служебные заголовки, избыточная информация и т.д.. Если туда по методам стеганографии внедрять информацию о ключе? Подбирать "случайные" значения "соли", облегчающие криптоанализ?
Допустим это все маловероятно, слишком сложно. Но по крайней мере теоретически это все возможно. И в некоторых программах подобные трюки использовались.
То что "полузакрытая" программа корректно считает случайным образом выбранные тестовые векторы, не говорит о ее надежности.
А как же набирающий обороты архиватор 7-Zip open source использует aes для шифрования http://www.7-zip.org
Да я просто пытался вспомнить какие там архиваторы бывают. Про 7-zip слышал. И чего там с оборотами? Правда набирает?
mozilla и thunderbird уже давно им пакуются ж)
Какова максимально оправданная длина пароля в rar? Например во первых по максимуму(к примеру больше либо нельзя либо не имеет смысла) и во вторых как принято говорить не против спецслужб, а просто если хочется скрыть информацию от посторонних глаз?
Выбирайте случайный пароль из 8-10 символов, состоящий из букв обоих регистров, цифр и различных символов. Если не будет лучшего способа взлома пароля, кроме полного перебора, такой пароль даст джае более, чем достаточное пространство комбинаций. А ключ, если верить Maxi, вычисляется из пароля итеративным хэшированием, так что ключ в итоге всё равно будет обладать достаточной непредсказуемостью.
какая функция используется?
JJ Dowson, насколько я понял, используется[link1] функция хэширования SHA-1.
А вот какой применяется режим оперирования блочного шифра, я не нашёл. :(
Lustermaf, Существует ли информация об использовании в WinRAR функции MD5?
JJ Dowson, в исходниках UnRAR[link2] ничего по поводу MD5 не нашёл. Есть только sha1.cpp.
Lustermaf, спасибо за информацию. Будет, на что потратить выходные :)
JJ Dowson, имейте в виду, что это всего лишь исходники компонента[link3] распаковки (UnRAR). Исходные коды самого WinRAR недоступны.
Lustermaf, я понимаю :)
Меня на самом деле куда больше интересует анализ ассемблерного листинга как раз самого WinRAR'а.
Скляров писал, что в Элкомсофте искали уязвимости в rar и не нашли.
[[http://lusfert.land.ru/files/winrar_security.pdf **On the Security of the
WinRAR Encryption Method**]]
Нашёл здесь[link4].
Хорошая статья, спасибо. На данный момент, пожалуй, вполне исчерпывающий итог по теме.
А на меня наоборот статья произвела впечатление поверхностной. Как будто авторам обязательно захотелось что-нибудь написать по теме, но писать было нечего. Приведенные атаки в своем большинстве надуманны и базируются на каких-то странных предположениях. Например, в первой атаке с какой-то стати в конце шага 3 утверждается, что "BOB sends this back to ALICE asking what is the problem". Это критичное место для самой возможности атаки. Потому как если BOB не посылает поврежденный файл назад ALICE (а просто, например, просит его перепослать заново), или же посылает, но зашифрованным (что было бы логичным), то атака разваливается как карточный домик. Ну и т.д.
Это обычное допущение для любой атаки с оракулом. Да, сам Боб может и не предпринять никаких подобных мер, а просто запросить у Алисы новую копию архива. Но ведь мы имеем дело с активным взломщиком Мэллори. Логично предположить, что он перехватит это сообщение Боба и от имени Алисы попросит отправить разбитый архив, чтобы выяснить, что же произошло.
На мой взляд статья как раз хороша тем, что не сосредотачивается на теоретическом обосновании реальности атак (вместо этого авторы просто отсылают читателя к работам Тадаёси Коно), а рассматривают практические шаги по их проведению, одновременно отмечая возможные приложения этих атак.
Причем здесь оракул? Это скорее MITM-атака (Man In The Middle).
И допущение здесь всего лишь такое, что злоумышленник может произвольным образом менять пакеты бегающие по незащищенному каналу. Все остальное – определяется выбранным сторонами протоколом общения. Но предположение о том, что они в какой-то момент забудут про шифрование и начнуть слать по незащищенному каналу нешифрованные данные, выглядит как минимум странно.
Учитывая, что коммуникация между Бобом и Алисой идет шифрованной, Мэллори не может ничего попросить от лица Алисы, так как нешифрованные запросы Боб будет просто игнорировать, а шифровать Мэллори еще не научился. Кроме того, если даже сам Боб решит отослать битый архив назад Алисе, то он пошлет его опять же шифрованным. Любые предположения, что что-то между Алисом и Бобом пойдет в нешифрованном виде, несостоятельны.
Так что, если эта атака и имеет место, то она направлена против протокола, придуманного самими же авторами (согласно которому Боб посылает битый архив нешифрованным), но к рару это имеет лишь косвенное отношение.
Думаю, Вы не хуже меня знаете, что криптографический оракул — это любой "чёрный ящик", обладающий секретным ключом, которого взломщик может попросить выполнить криптографическую операцию, и делать на основании её результатов те или иные выводы.
Боб знает ключ расшифрования и является оракулом для Мэллори. Если Мэллори не сумеет "попросить" одного из участников расшифровать для него модифицированный особым образом архив, атака не сможет состояться.
Разумеется, это комбинированная атака, включающая и MITM — без этого Мэллори не сможет получить результат шифрования для проведения криптоанализа.
Шифрование не есть аутентификация (WinRAR не аутентифицирует даже заголовок архива, не говоря уж об отправителе). Алиса просто решила отправить Бобу зашифрованный с помощью WinRAR'а архив. Если бы она хотела его аутентифицировать, то заверила бы цифровой подписью PGP и, скорее всего, вообще с помощью PGP зашифровала, и мы не имели бы предмета спора. А вот Ваше предположение кажется мне притянутым за уши. ;)
Это требует жёсткой предварительной договорённости. Могу представить себе такое, если бы у Алисы и Боба была определённая заранее чёткая политика безопасности. Но что если они просто решили обменяться каким-нибудь проектом отчёта о новой ценовой политике фирмы?
Наоборот, авторы не высказывали никакого протокола. Они взяли обычную модель поведения. Среднестатистический пользователь видит в перечне фич WinRAR'a поддержку шифрования и думает: "О! Теперь мои файлы, которые я пересылаю по почте, будут защищены!". И, будучи в ложном чувстве защищённости, просто отправляет файлы по почте. Абсолютно реалистичная среда и сценарий атаки, по-моему.
А почему бы тогда не поступить проще: Мэллори от лица Боба шлет Алисе открытым текстом: "Алиса, я не могу распаковать твой архив, WinRAR глючит. Перепошли отчёт не сжимая. Боб.", и Алиса на радость Мэллори шлет отчёт, не заморачиваясь с WinRAR. Эта атака из той же оперы, что и предложенная в статье. Более того, просьба перепослать не шифруя будет работать против любого шифра, включая пресловутый PGP (если Алиса делает то, что ее просит псевдо-Боб открытым текстом). Может, тоже статью тиснем?
Безграмотное использование может дискредитировать любой шифр, и WinRAR тут не будет исключением. Только заслуживает ли это отдельной статьи?
Если договоренности нет, то о чем вообще эта статья ведет речь? Гадания на кофейной гуще?
Что такое "обычная модель поведения"? Авторы пусть и неявно, но определяют протокол общения Алисы с Бобом, в котором Боб по получению битого архива посылает результат в нешифрованном виде назад Алисе. Вам такое поведение кажется "обычным", а мне – нет.
Да, атака работает против описанного протокола, вот только сам протокол выглядит надуманным (и не вписывающимся в традиционные методы использования незащищенных каналов для передачи конфиденциальной информации).
Ну, если уж этот сценарий кажется Вам нереалистичным, вот ещё пара примеров:
http://www.pgpru.com/faq/crypto/#6
http://www.pgpru.com/faq/crypto/#9
Как говорится, найдите десять отличий... Непонятно только, зачем разработчики так суетились и что-то меняли? Ведь можно было просто предложить пользователям в руководстве не отправлять битые файлы куда попало.
Вы меня удивляете, господа. WinRAR имеет опцию добавления аутентификационной информации.
Из справки:
"Add authenticity information", is avaliable only to registered users and forces WinRAR to put in archive information concerning the creator, last update time and archive name.
Вот пример: http://www.mytempdir.com/583285
И как я проверю, что это действительно ЭЦП, а не просто красивая картинка?
У меня же нет публичного ключа/сертификата Kent'а, который можно использовать в WinRAR.
Поскольку именно разработчик (или cracker, взломавший программу) с помощью регистрационного кода подтверждает имя пользователя, эта опция вообще не даёт какой-либо существенной защиты.
А описанные атаки она просто переводит в разряд чистого MITM. Да, Мэллори не сможет модифицировать заголовок архива, зато он может с помощью keygen'а, к примеру (а может и легально купив программу на ложное имя — разве продавец будет его проверять? Он ведь не центр сертификации), зарегистрировать программу на имя Алисы. Боб видит в полученном архиве цифровую подпись Алисы, и чувствует себя не менее защищённо, убеждённый, что файл пришёл именно от неё, а не от коварного Мэллори.
Теперь мы имеем и аутентификацию. И, надеюсь, что даже RElf не станет возражать, что Мэллори получает прекрасный инструмент социнженерии, которым может выудить у Боба любую нужную ему информацию.
Публичного ключа нет. Но в данном случае важен сам факт верной подписи от известного имени – хоть какая-то уверенность.
Легально купить программу на существующее имя, думаю, не получится. Могу поинтересоваться, если интересно.
Практика показала, что крякнутые версии дают неправильную подпись.
Должно получиться. Иначе у разных Иванов Ивановых (или Джонов Смитов, если хотите) возникнут проблемы при покупке программы.
Помимо этого я точно помню, что когда-то получал от одного человека архив, заверенный корректной подписью, и программа у него была крякнутая. Но это было довольно давно, с версией 2.8 или около того.
Я только что написал письмо в техподдержку с просьбой дать здесь комментарии. Надеюсь, откликнутся.
SATtva,
Я думаю, решение тут простое: регистрационные ключи, всплывшие на варезных сайтах добавляются в чёрный список, и новые версии программю считают их неверными, как и подписи, ими сгенерированные.
Получил ответ от автора программы:
Вот такая информация появилась:
Все это было ужасно интересно, но не совсем понятно для среднего человека.
Скажите мне, о гуру, возможно ли взломать rar архив 3.xx, если известна примерно половина содержания архива? Можно ли найти вторую половину, если пароль неизвестен, но известна его длина и она составляет, к примеру, 16 символов?
Перебор пароля затрудняется итеративным хэшированием. Если он не слишком надёжен, можно попробовать угадать, но от полного перебора можно сразу отказаться. Шифрование AES, судя по тому, что мы обсуждали в форуме, реализовано в RAR вполне адекватно, так что атаковать шифртекст напрямую тоже бесполезно. Если бы мне было жизненно необходимо вскрыть архив, я бы искал следы пароля на диске.
Блин, порой такой бред, бывает, напишут... Уже и не знаешь, плакать или смеяться...
Считайте, что если нет тайных неизвестных остальному миру закладок в rar, то надёжность шифра в данном случае определяется криптомощностью пароля. Не стоит себя обольщать тем что пароль типа a1b2c345 невзламываемый... Хороший пароль – это близкий к случайному, и длинный... Поскольку запомнить совсем случайный пароль сложно, для критический вещей можно посоветовать придумать собственный пароль, но подлиннее.. Хотя бы символов 25-30...
И позаботиться о том, чтобы он не использовался для для других данных: доступ к системе, к mail-серверу и т.д. Иначе социнженерия опять всех как всегда порулит :)
Вообще, детальный ответ сложный...
Когда интересовался, мне давали рекомендацию не шифровать имён файлов в rar, а просто сделать шифрованными сами данные в архиве, без имён файлов, а потом такой архив запаковать в ещё один, можно с другим паролем... Смысл в том, что если будут ломать такой архив, то шифрование имён файлов архива значительно упростит его взлом... так как они там отдельно шифруются от самх данных. Фактически произойдёт подбор пароля не ко всему объёму данных, а только метаданным архива, после чего подобранный пароль применится ко всему архиву... как-то так.. Сорри если байки, давно уж это было... Ну и, соответственно, чем больше архив тем сложнее его взломать перебором, так как потребуется большее время на проверку каждого пароля.
Тоже не шифруя имён файлов...
То есть, грубо говоря, надо делать так что имена файлов вообще никогда не шифровались с помощью опций самого рара...
А не проще ли ставить безопасные пароли? Если я ставлю 30ти значный случайный пароль, то без разницы будет идти перебор со скоростью 10 или 1000000 паролей в секунду, всеравно при моей жизни он не успеет завершиться.
30ти значный случайный пароль трудно запомнить.
Для проверки ключа достаточно тестового расшифрования нескольких начальных байтов архива, содержащего предсказуемый заголовок. Время проверки увеличивает итеративное хэширование пароля.
Между прочим, в rar-архиве разные файлы могут быть зашифрованы с
разными паролями.
Можно ли тогда сказать, что mcrypt -b -a "algoritthm" даёт существенно лучшую защиту при равносильном пароле? Опция -b вроде как убирает указанный эфект.
Вообще-то в топике обсуждается RAR, а не mcrypt.
В mcrypt осуществляется проверка расшифрования по хэшу данных. -b убирает сведения об использованном алгоритме шифрования и убирает все хэши и служебные заголовки. Это не является способом обеспечения существенно лучшей защиты, если програма создана нормально, о чём автор программы честно предупреждает.
Для чего нужно итеративное хэширование и почему оно полезно, несмотря на использование длинных паролей написано в работе Clemens Fruhwirth "New Methods in Hard Disk Encryption":
Пусть технология быстродействия компьютеров растёт по степени r. Пусть нужно выести функию f(t), по которой можно узнать сколько паролей может перебрать атакующий за промежуток времени t. Пусть пользователь выбрал столько циклов хэширования, что на его машине проверка пароля занимает время c.
Тогда на момент времени 0 функция f(0)) зависит от преимущества в ресурсах взломщика над пользователем и в зависимости от времени проверки пароля c будет равна:
$f(0)=\frac{k}{c}$
Если проверка пароля занимает одну секунду, то за год можно перебрать k x 365 x 24 x 3600 паролей.
Если степень роста мощности компьютерных технологий за год r, функция взлома паролей будет экспоненциально возрастать:
$f(t)=f(0) e^{rt}$
Интеграл над функцией f(t) даёт отношение преимущества между периодом времени t и моментом 0:
$F(t)=f(0)\int^{t}_0{e^{rx}\, dx$
При r > 0:
$F(t)=\frac{e^{rt}-1}{r}f(0)$
Если бы было, что r = 0, то:
$F(t)=t{}f(0)$
Для вычисления времени полного перебора множества паролей размером p нужно вычислить это время t, как функцию от p,
с учётом выражения p=F(t):
$t=\frac{1}{r}\ln{\bigg {(} 1+\frac{pr}{f(0)} \bigg{)} }$
Или для r = 0:
$t=\frac{p}{f(0)}$
По этим двум уравнениям понятна разница, сколько лет потребуется на взлом пароля размером p.
А теперь можно рассмотреть, с чем реально способен работать пользователь:
1) Фразу английского языка из 40 букв = 1.2 бит энтропии на букву = 248 бит
2) Выбор случайной последовательности 10 картинок из 60 возможных = 260 бит
3) 13 случайных знаков, сгенерированных утилитой mkpasswd, 6 бит энтропии на знак = 278 бит
4) Пароль вида 11/60 из набора картинок + случайная 6-значная строка = 2 100 бит
5) Ключ 128-бит, хранимый на смарт-карте.
Дальше можно в зависимости от того, наксолько вы верите в закон Мура выбирать коэффициент r.
1) Если мощности компьютеров будут удваиваются каждые два года, r = 0.347
2) Если каждые 5 лет, r = 0.139
3) Если каждые 10 лет, то r = 0.069
4) 20 лет, r = 0.035
5) технология остановилась r = 0
Теперь можно посчитать, сколько лет понадобиться противнику для полного перебора паролей при разном уровне скорости развития технологии при задержке в проверке пароля в пользовательском компьютере за счёт итеративного хэширования в 1 секунду, но преимуществу противника над пользовательскими выч. ресурсами в 108 раз:
Т.е. выбирая задержку, пользователь может несколько уравнять свои шансы при противостоянии с противником с высокими выч. ресурсами даже с учётом их экспоненциального роста во времени и с учётом сравнительно низкой энтропии запоминаемого пароля.
А теперь, кто хочет, может убрать итеративное хэширование и задержку в одну секунду, уменьшить коэффициент c в уравнении f(t) на несколько тысяч, пересчитать эту таблицу под свой вариант, посмотреть на сколько хуже будут результаты и делать выводы, что куча умных людей якобы зря изобретала методы повышения временной стойкости ключей, получаемых из пароля, стандарты разрабатывали (вот бюрократы :-)
Или надо тренировать свою память для запоминания гарантированно 128-битных паролей.
Запомнить один такой пароль при желании несложно. Использовать его будем для криптодиска на котором храняться все остальные пароли.
Имхо это самый простой и довольно безопасный способ.
https://www.pgpru.com/comment2246
sha256 password generator[link5]
unknown
Это очень странно, что вы говорите... хотя, может быть и так. Я вижу единственный способ отличения расшифрованного файла от нерасшифрованного: смотреть на заголовок файла, который расшифровывается, его первые несколько байт. Если есть априорная информация что там, то это усложнит задачу. Но я могу легко написать скриптик, который перешифрует вложенным образом один и тот же файл большое число раз, а реальный пароль будет стоять только на одну итерацию. Можно пофантазировать каким образом вычислять остальные пароли... Далее допустим что программа-взломщик не имея априорной информации ни о фоорме содержимого ни о методе шифрования вряд ли будет пробовать 100 раз последовательно применить дешифроватор к одному и тому же файлу... В общем, имхо, можно как-то наворотить так, чтоб снизить эффект проверки верности пассфразы по первым байтам расшифрованного файла. В конечном счёте можно вообще застеганографировать важное сообщения в контейнер с шумом, а сам контейнер пустить под mcrypt -b.
P. S.: я про него в контексте рара сказал как пример программы, возможно, не страдающей проблемой рара "распознавания правильной пассфразы по дешифрованному файлу".
Это ложный путь, security trough obscutiry. Всегда подразумеваем, что противник знает часть открытого текста (да хоть 99% его содержания) и форму его шифрования. Опираемся только на стойкость выбранного алгоритма.
Это самая примитивная задача, если Вам она так нужна, то она может быть решена иначе: Сгенерируйте случайное число x и поместите в шифроконтейнер его хэш-значение Y=H(x), если при расшифровке совпадёт, что H(x)=Y, то ключ верный в пределах вероятности коллизии хэш-функции (2-256 для SHA-512).
Таким образом, никакого известного открытого текста (заголовка), который противник должен искать в контейнере, ему предоставлено не будет, но повторяю, особого смысла в этом нет.
Я понимаю что вы хотели сказать. Путь ложный с точки зрения криптографии как таковой, если же говорить о реализации конкретных систем ИБ, то какой-то элемент "security trough obscutiry" там всегда присутствует, хотя и не несёт на себе основную нагрузку... В конце концов, вся стеганография может быть в том или ином виде понята как часть ecurity trough obscutiry... ибо что такое security? В общем случае к этому понятию можно многое отнести.
Так вот и проговоритесь почему нет смысла в совершенно конкретной реализации ИБ...
Основная проблема защиты – это то, что для проверки каждой подбираемой пассфразы нужно полностью разархивировать с её помощью архив, а на это уйдёт много времени...
Хотя... м.б. имеется в виду что раз шифр блочный, то всегда можно расшифровать только кусок файла и, соответственно, никакой зависимости сложности взлома от объёма зашифрованных данных? Вы это хотели сказать?
Надеюсь, что я тоже вас понимаю :-)
Просто сначала надо выбрать лучший способ без obscurity. Идеальную модель. А затем вполне можно для подстраховки добавить немного obscurity, если очень уверены в том, что делаете. Просто можно:
a) перестараться и всё не улучшить, а парадоксальным образом ухудшить
b) вызвать подозрения во внесении backdoor у посторонних пользователей
c) есть способы организации obscurity гораздо лучше обоснованные, более эффективные и практичнее. Просто это оффтопик для темы.
При брутфорсе это так. Но я хотел сказать не это.
Если подходить максималистски, то итеративное хэширование – тоже своего рода obscurity – способ добавить фиктивной энтропии на 10 бит к паролю, но хорошо обоснованный.
/Библиотека/Статьи/СекретностьБезопасностьНеясность[link6]
RAR сейчас фактически стал стандартом де-факто в области обмена запаролеными архивами. В общем это неплохо, так как пользоваться раром удобно, и он есть у каждого. В связи с этим полезно было бы провести исследование на тему того, возможно ли преднамереное внесение в алгоритм шифрования рара уязвимостей без потери совместимости с форматом. Насколько я понимаю, при симмитричном шифровании на основе пароля можно построить доказательство стойкости системы с закрытым исходным кодом, т.к. возможна проверка соответствия алгоритма заявленому, и не возможны никакие нестойкие вариации проходящие эту проверку.
Допустим возьмем схему шифрования:
key = pkcs5(password)
enc = AES(key, data)
В этой схеме возможно доказательство правильности реализации без раскрытия исходников архиватора.
Но если применяется схема наподобии этой:
key1 = pkcs5(password)
key2 = random
enc = AES(key1, key2) + AES(key2, data)
В этой схеме доказательство без раскрытия исходника невозможно, так как возможна слабая реализация ГСЧ.
Какую именно схему использует RAR?
А ещё возможно организовать утечку битов ключа через вектор инициализации и другие побочные каналы.
Если считать, что не у каждого есть unix-like ОС, то да, иначе: tar.gz.gpg
Я сомневаюсь что в rar нет технический полей для дополнительной информации, где бы можно было сохранять копию введённого пароля. Да и вообще, rar в точности не избыточен как архиватор? То есть если 1 бит заменить то уже точно не расшифровать? И как там это всё связано с шифрованием...
Как пользователь RAR с десятилетним стажем (или больше, ещё из DOS) скажу, что там даже опция есть для внесения избыточности, благодаря которой архив при повреждениях можно восстановить. Как она сочетается с шифрованием, сказать не могу, ибо шифрование в RAR никогда не использовал.
Варианта два. Если перед зашифрованием данные хэшируются, формируя MDC, который сверяется для проверки корректности расшифрования (что предполагалось выше), то малейшее повреждение/искажение шифртекста приведёт к его блокировке. Если же процедура шифрования не налагает дополнительных методов контроля целостности, тогда всё выглядит так: искажение шифртекста повреждает один-два блока (в зависимости от режима) открытого текста, это выявляется по ошибке CRC (используемой для контроля целостности), после чего ошибка исправляется штатными средствами архиватора. Отсюда же получаем проблему: учитывая слабую коллизионную стойкость CRC, становится возможным проводить watermark-атаки и вносить предсказуемые изменения в открытый текст, которые не будут обнаружены проверкой CRC-суммы.
Не думаю, что rar использует crc. Скорее всего, данные шифруются, а затем кодируются Кодом Боуза-Чоудхури-Хоквингхема или Кодом Рида-Соломона.
Если правильно помню, повреждённые архивы выдают сообщение о несоответствии CRC.
Моя мысль была о том, что crc не используется для восстановлении информации.
Скорее всего, используется комбинация всех этих методов.
CRC – алгоритм только для контроля целостности, он отвечает на вопрос искажены или нет данные.
Для восстановление искаженных данных архива при добавленной в архив избыточности возможно при использовании специальных алгоритмов, например, Код Боуза-Чоудхури-Хоквингхема или Код Рида-Соломона.
Так и я этого не заявлял. Перечитайте постинг[link7]. Я говорил о том, что вследствие слабой коллизионной стойкости CRC можно так вводить ошибки (искажения) в шифртекст, что при расшифровании они не приведут к изменению контрольной суммы.
И все-таки, как взломать пароль-то? Дело в том, что я скачал из интернета архив с музыкой. RAR формат. А он требует пароль. Что делать? Жалко же!
Вы можете понадеяться что пароль слабый и воспользоваться программой-взломщиком, но это всё равно будет брут-форс-перебор без всяких гарантий.