Шифрование в rar
Здравствуйте!
Читаю много очень умных вещей. Интересно, но порой сложновато. Можно несколько прозаичнее и чуть ближе к обычным пользователям, не использующим специальные программы? Скажите, насколько стоек симметиричный алгоритм шифрования реализованный в архиваторе rar и какой там алгоритм используется? Я читал, что AES-128 или наш ГОСТ? Сколько надо часов крутой прикрутой машине, что бы открыть архив?
комментариев: 437 документов: 30 редакций: 15
разными паролями.
Можно ли тогда сказать, что mcrypt -b -a "algoritthm" даёт существенно лучшую защиту при равносильном пароле? Опция -b вроде как убирает указанный эфект.
комментариев: 9796 документов: 488 редакций: 5664
В 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-битных паролей.
комментариев: 371 документов: 19 редакций: 20
Запомнить один такой пароль при желании несложно. Использовать его будем для криптодиска на котором храняться все остальные пароли.
Имхо это самый простой и довольно безопасный способ.
комментариев: 9796 документов: 488 редакций: 5664
Это очень странно, что вы говорите... хотя, может быть и так. Я вижу единственный способ отличения расшифрованного файла от нерасшифрованного: смотреть на заголовок файла, который расшифровывается, его первые несколько байт. Если есть априорная информация что там, то это усложнит задачу. Но я могу легко написать скриптик, который перешифрует вложенным образом один и тот же файл большое число раз, а реальный пароль будет стоять только на одну итерацию. Можно пофантазировать каким образом вычислять остальные пароли... Далее допустим что программа-взломщик не имея априорной информации ни о фоорме содержимого ни о методе шифрования вряд ли будет пробовать 100 раз последовательно применить дешифроватор к одному и тому же файлу... В общем, имхо, можно как-то наворотить так, чтоб снизить эффект проверки верности пассфразы по первым байтам расшифрованного файла. В конечном счёте можно вообще застеганографировать важное сообщения в контейнер с шумом, а сам контейнер пустить под mcrypt -b.
P. S.: я про него в контексте рара сказал как пример программы, возможно, не страдающей проблемой рара "распознавания правильной пассфразы по дешифрованному файлу".
комментариев: 9796 документов: 488 редакций: 5664
Это ложный путь, security trough obscutiry. Всегда подразумеваем, что противник знает часть открытого текста (да хоть 99% его содержания) и форму его шифрования. Опираемся только на стойкость выбранного алгоритма.
Это самая примитивная задача, если Вам она так нужна, то она может быть решена иначе: Сгенерируйте случайное число x и поместите в шифроконтейнер его хэш-значение Y=H(x), если при расшифровке совпадёт, что H(x)=Y, то ключ верный в пределах вероятности коллизии хэш-функции (2-256 для SHA-512).
Таким образом, никакого известного открытого текста (заголовка), который противник должен искать в контейнере, ему предоставлено не будет, но повторяю, особого смысла в этом нет.
Я понимаю что вы хотели сказать. Путь ложный с точки зрения криптографии как таковой, если же говорить о реализации конкретных систем ИБ, то какой-то элемент "security trough obscutiry" там всегда присутствует, хотя и не несёт на себе основную нагрузку... В конце концов, вся стеганография может быть в том или ином виде понята как часть ecurity trough obscutiry... ибо что такое security? В общем случае к этому понятию можно многое отнести.
Так вот и проговоритесь почему нет смысла в совершенно конкретной реализации ИБ...
Основная проблема защиты – это то, что для проверки каждой подбираемой пассфразы нужно полностью разархивировать с её помощью архив, а на это уйдёт много времени...
Хотя... м.б. имеется в виду что раз шифр блочный, то всегда можно расшифровать только кусок файла и, соответственно, никакой зависимости сложности взлома от объёма зашифрованных данных? Вы это хотели сказать?
комментариев: 9796 документов: 488 редакций: 5664
Надеюсь, что я тоже вас понимаю :-)
Просто сначала надо выбрать лучший способ без obscurity. Идеальную модель. А затем вполне можно для подстраховки добавить немного obscurity, если очень уверены в том, что делаете. Просто можно:
a) перестараться и всё не улучшить, а парадоксальным образом ухудшить
b) вызвать подозрения во внесении backdoor у посторонних пользователей
c) есть способы организации obscurity гораздо лучше обоснованные, более эффективные и практичнее. Просто это оффтопик для темы.
При брутфорсе это так. Но я хотел сказать не это.
Если подходить максималистски, то итеративное хэширование – тоже своего рода obscurity – способ добавить фиктивной энтропии на 10 бит к паролю, но хорошо обоснованный.
комментариев: 11558 документов: 1036 редакций: 4118
/Библиотека/Статьи/СекретностьБезопасностьНеясность
комментариев: 371 документов: 19 редакций: 20
Допустим возьмем схему шифрования:
key = pkcs5(password)
enc = AES(key, data)
В этой схеме возможно доказательство правильности реализации без раскрытия исходников архиватора.
Но если применяется схема наподобии этой:
key1 = pkcs5(password)
key2 = random
enc = AES(key1, key2) + AES(key2, data)
В этой схеме доказательство без раскрытия исходника невозможно, так как возможна слабая реализация ГСЧ.
Какую именно схему использует RAR?
комментариев: 9796 документов: 488 редакций: 5664
А ещё возможно организовать утечку битов ключа через вектор инициализации и другие побочные каналы.
Если считать, что не у каждого есть unix-like ОС, то да, иначе: tar.gz.gpg
Я сомневаюсь что в rar нет технический полей для дополнительной информации, где бы можно было сохранять копию введённого пароля. Да и вообще, rar в точности не избыточен как архиватор? То есть если 1 бит заменить то уже точно не расшифровать? И как там это всё связано с шифрованием...
комментариев: 11558 документов: 1036 редакций: 4118
Как пользователь RAR с десятилетним стажем (или больше, ещё из DOS) скажу, что там даже опция есть для внесения избыточности, благодаря которой архив при повреждениях можно восстановить. Как она сочетается с шифрованием, сказать не могу, ибо шифрование в RAR никогда не использовал.
Варианта два. Если перед зашифрованием данные хэшируются, формируя MDC, который сверяется для проверки корректности расшифрования (что предполагалось выше), то малейшее повреждение/искажение шифртекста приведёт к его блокировке. Если же процедура шифрования не налагает дополнительных методов контроля целостности, тогда всё выглядит так: искажение шифртекста повреждает один-два блока (в зависимости от режима) открытого текста, это выявляется по ошибке CRC (используемой для контроля целостности), после чего ошибка исправляется штатными средствами архиватора. Отсюда же получаем проблему: учитывая слабую коллизионную стойкость CRC, становится возможным проводить watermark-атаки и вносить предсказуемые изменения в открытый текст, которые не будут обнаружены проверкой CRC-суммы.