id: Гость   вход   регистрация
текущее время 14:14 28/03/2024
Автор темы: Гость, тема открыта 19/12/2004 19:46 Печать
создать
просмотр
ссылки

Шифрование в rar


Здравствуйте!
Читаю много очень умных вещей. Интересно, но порой сложновато. Можно несколько прозаичнее и чуть ближе к обычным пользователям, не использующим специальные программы? Скажите, насколько стоек симметиричный алгоритм шифрования реализованный в архиваторе rar и какой там алгоритм используется? Я читал, что AES-128 или наш ГОСТ? Сколько надо часов крутой прикрутой машине, что бы открыть архив?


 
На страницу: 1, 2, 3, 4, 5 След.
Комментарии
— Kent (12/12/2007 15:20)   профиль/связь   <#>
комментариев: 437   документов: 30   редакций: 15
Между прочим, в rar-архиве разные файлы могут быть зашифрованы с
разными паролями.
— Гость (12/12/2007 20:20)   <#>
Для проверки ключа достаточно тестового расшифрования нескольких начальных байтов архива, содержащего предсказуемый заголовок. Время проверки увеличивает итеративное хэширование пароля.

Можно ли тогда сказать, что mcrypt -b -a "algoritthm" даёт существенно лучшую защиту при равносильном пароле? Опция -b вроде как убирает указанный эфект.
— unknown (13/12/2007 12:00, исправлен 13/12/2007 12:33)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Вообще-то в топике обсуждается RAR, а не mcrypt.
В mcrypt осуществляется проверка расшифрования по хэшу данных. -b убирает сведения об использованном алгоритме шифрования и убирает все хэши и служебные заголовки. Это не является способом обеспечения существенно лучшей защиты, если програма создана нормально, о чём автор программы честно предупреждает.


А не проще ли ставить безопасные пароли? Если я ставлю 30ти значный случайный пароль, то без разницы будет идти перебор со скоростью 10 или 1000000 паролей в секунду, всеравно при моей жизни он не успеет завершиться


Для чего нужно итеративное хэширование и почему оно полезно, несмотря на использование длинных паролей написано в работе 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 раз:

Рост выч. технологий/размер пароля24826027821002128
Каждые 2 года 10-215509590
5 лет10-230120230170
10 лет10-245225445725
20 лет10-2754308751435
нет роста10-236510710141023

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

А теперь, кто хочет, может убрать итеративное хэширование и задержку в одну секунду, уменьшить коэффициент c в уравнении f(t) на несколько тысяч, пересчитать эту таблицу под свой вариант, посмотреть на сколько хуже будут результаты и делать выводы, что куча умных людей якобы зря изобретала методы повышения временной стойкости ключей, получаемых из пароля, стандарты разрабатывали (вот бюрократы :-)

Или надо тренировать свою память для запоминания гарантированно 128-битных паролей.
— ntldr (13/12/2007 13:20)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20

Запомнить один такой пароль при желании несложно. Использовать его будем для криптодиска на котором храняться все остальные пароли.
Имхо это самый простой и довольно безопасный способ.
— unknown (13/12/2007 13:35)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
https://www.pgpru.com/comment2246
— Гость (13/12/2007 14:05)   <#>
sha256 password generator
— Гость (13/12/2007 15:27)   <#>
unknown
Это не является способом обеспечения существенно лучшей защиты, если програма создана нормально, о чём автор программы честно предупреждает.

Это очень странно, что вы говорите... хотя, может быть и так. Я вижу единственный способ отличения расшифрованного файла от нерасшифрованного: смотреть на заголовок файла, который расшифровывается, его первые несколько байт. Если есть априорная информация что там, то это усложнит задачу. Но я могу легко написать скриптик, который перешифрует вложенным образом один и тот же файл большое число раз, а реальный пароль будет стоять только на одну итерацию. Можно пофантазировать каким образом вычислять остальные пароли... Далее допустим что программа-взломщик не имея априорной информации ни о фоорме содержимого ни о методе шифрования вряд ли будет пробовать 100 раз последовательно применить дешифроватор к одному и тому же файлу... В общем, имхо, можно как-то наворотить так, чтоб снизить эффект проверки верности пассфразы по первым байтам расшифрованного файла. В конечном счёте можно вообще застеганографировать важное сообщения в контейнер с шумом, а сам контейнер пустить под mcrypt -b.

P. S.: я про него в контексте рара сказал как пример программы, возможно, не страдающей проблемой рара "распознавания правильной пассфразы по дешифрованному файлу".
— unknown (13/12/2007 16:48)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Далее допустим что программа-взломщик не имея априорной информации ни о фоорме содержимого ни о методе шифрования вряд ли будет пробовать 100 раз последовательно применить дешифроватор к одному и тому же файлу...

Это ложный путь, security trough obscutiry. Всегда подразумеваем, что противник знает часть открытого текста (да хоть 99% его содержания) и форму его шифрования. Опираемся только на стойкость выбранного алгоритма.

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

Это самая примитивная задача, если Вам она так нужна, то она может быть решена иначе: Сгенерируйте случайное число x и поместите в шифроконтейнер его хэш-значение Y=H(x), если при расшифровке совпадёт, что H(x)=Y, то ключ верный в пределах вероятности коллизии хэш-функции (2-256 для SHA-512).

Таким образом, никакого известного открытого текста (заголовка), который противник должен искать в контейнере, ему предоставлено не будет, но повторяю, особого смысла в этом нет.
— Гость (13/12/2007 18:01)   <#>
Это ложный путь, security trough obscutiry.

Я понимаю что вы хотели сказать. Путь ложный с точки зрения криптографии как таковой, если же говорить о реализации конкретных систем ИБ, то какой-то элемент "security trough obscutiry" там всегда присутствует, хотя и не несёт на себе основную нагрузку... В конце концов, вся стеганография может быть в том или ином виде понята как часть ecurity trough obscutiry... ибо что такое security? В общем случае к этому понятию можно многое отнести.

Таким образом, никакого известного открытого текста (заголовка), который противник должен искать в контейнере, ему предоставлено не будет, но повторяю, особого смысла в этом нет.

Так вот и проговоритесь почему нет смысла в совершенно конкретной реализации ИБ...
Основная проблема защиты – это то, что для проверки каждой подбираемой пассфразы нужно полностью разархивировать с её помощью архив, а на это уйдёт много времени...
Хотя... м.б. имеется в виду что раз шифр блочный, то всегда можно расшифровать только кусок файла и, соответственно, никакой зависимости сложности взлома от объёма зашифрованных данных? Вы это хотели сказать?
— unknown (14/12/2007 09:17, исправлен 14/12/2007 10:15)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Я понимаю что вы хотели сказать. Путь ложный с точки зрения криптографии как таковой, если же говорить о реализации конкретных систем ИБ, то какой-то элемент "security trough obscutiry" там всегда присутствует, хотя и не несёт на себе основную нагрузку...

Надеюсь, что я тоже вас понимаю :-)

Просто сначала надо выбрать лучший способ без obscurity. Идеальную модель. А затем вполне можно для подстраховки добавить немного obscurity, если очень уверены в том, что делаете. Просто можно:
a) перестараться и всё не улучшить, а парадоксальным образом ухудшить
b) вызвать подозрения во внесении backdoor у посторонних пользователей
c) есть способы организации obscurity гораздо лучше обоснованные, более эффективные и практичнее. Просто это оффтопик для темы.

Хотя... м.б. имеется в виду что раз шифр блочный, то всегда можно расшифровать только кусок файла и, соответственно, никакой зависимости сложности взлома от объёма зашифрованных данных? Вы это хотели сказать?


При брутфорсе это так. Но я хотел сказать не это.

Если подходить максималистски, то итеративное хэширование – тоже своего рода obscurity – способ добавить фиктивной энтропии на 10 бит к паролю, но хорошо обоснованный.
— SATtva (14/12/2007 14:11)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Путь ложный с точки зрения криптографии как таковой, если же говорить о реализации конкретных систем ИБ, то какой-то элемент "security trough obscutiry" там всегда присутствует, хотя и не несёт на себе основную нагрузку...

/Библиотека/Статьи/СекретностьБезопасностьНеясность
— ntldr (14/12/2007 15:32)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
RAR сейчас фактически стал стандартом де-факто в области обмена запаролеными архивами. В общем это неплохо, так как пользоваться раром удобно, и он есть у каждого. В связи с этим полезно было бы провести исследование на тему того, возможно ли преднамереное внесение в алгоритм шифрования рара уязвимостей без потери совместимости с форматом. Насколько я понимаю, при симмитричном шифровании на основе пароля можно построить доказательство стойкости системы с закрытым исходным кодом, т.к. возможна проверка соответствия алгоритма заявленому, и не возможны никакие нестойкие вариации проходящие эту проверку.
Допустим возьмем схему шифрования:
key = pkcs5(password)
enc = AES(key, data)
В этой схеме возможно доказательство правильности реализации без раскрытия исходников архиватора.
Но если применяется схема наподобии этой:
key1 = pkcs5(password)
key2 = random
enc = AES(key1, key2) + AES(key2, data)
В этой схеме доказательство без раскрытия исходника невозможно, так как возможна слабая реализация ГСЧ.
Какую именно схему использует RAR?
— unknown (14/12/2007 16:22)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Насколько я понимаю, при симмитричном шифровании на основе пароля можно построить доказательство стойкости системы с закрытым исходным кодом, т.к. возможна проверка соответствия алгоритма заявленому, и не возможны никакие нестойкие вариации проходящие эту проверку.
Допустим возьмем схему шифрования:

А ещё возможно организовать утечку битов ключа через вектор инициализации и другие побочные каналы.

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

Если считать, что не у каждого есть unix-like ОС, то да, иначе: tar.gz.gpg
— Гость (14/12/2007 21:54)   <#>
В связи с этим полезно было бы провести исследование на тему того, возможно ли преднамереное внесение в алгоритм шифрования рара уязвимостей без потери совместимости с форматом.

Я сомневаюсь что в rar нет технический полей для дополнительной информации, где бы можно было сохранять копию введённого пароля. Да и вообще, rar в точности не избыточен как архиватор? То есть если 1 бит заменить то уже точно не расшифровать? И как там это всё связано с шифрованием...
— SATtva (14/12/2007 23:25)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Да и вообще, rar в точности не избыточен как архиватор?

Как пользователь RAR с десятилетним стажем (или больше, ещё из DOS) скажу, что там даже опция есть для внесения избыточности, благодаря которой архив при повреждениях можно восстановить. Как она сочетается с шифрованием, сказать не могу, ибо шифрование в RAR никогда не использовал.

Варианта два. Если перед зашифрованием данные хэшируются, формируя MDC, который сверяется для проверки корректности расшифрования (что предполагалось выше), то малейшее повреждение/искажение шифртекста приведёт к его блокировке. Если же процедура шифрования не налагает дополнительных методов контроля целостности, тогда всё выглядит так: искажение шифртекста повреждает один-два блока (в зависимости от режима) открытого текста, это выявляется по ошибке CRC (используемой для контроля целостности), после чего ошибка исправляется штатными средствами архиватора. Отсюда же получаем проблему: учитывая слабую коллизионную стойкость CRC, становится возможным проводить watermark-атаки и вносить предсказуемые изменения в открытый текст, которые не будут обнаружены проверкой CRC-суммы.
На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3