LINUX.ORG.RU

Итерации хешей, насколько это криптобезопасно?

 , sha-2, ,


0

1

Поясните вот про что. Как я понимаю, сами алгоритмы шифрования вроде AES достаточно хорошо исследованы, но что с алгоритмами их практического применения?

Например, в luks и truecrypt с некоторыми отличиями в деталях, но пароль пользователя хэшируется (обычно sha256/sha512) много раз (например сто тысяч раз и более) для замедления подбора. Этим хэшем потом шифруется (расшифровывается) MasterKey, используемый для всего контейнера.

Но доказано ли, что итерации хэша не сужают в итоге количество вариантов (не уменьшают энтропию)?

★★★★★

Последнее исправление: praseodim (всего исправлений: 2)

Но доказано ли, что итерации хэша не сужают в итоге количество вариантов (не уменьшают энтропию)?

Что уж там, можно равенство классов P и NP сразу доказать.

melkor217 ★★★★★
()

Там есть PBKDF (в LUKS, по крайней мере), которая это несколько нивелирует.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от melkor217

При чем тут?

Кстати, правильно заданный вопрос - это половина ответа =) После того как сформулировал тему сумел найти https://habr.com/post/100301/

Там разобрано сужение объема пространства результата. Получается, что оно хотя и происходит, но очень медленное. Для 2.097.146 итераций только на 20 бит сужается. Что для 256 и тем более 512 битных хешей не очень принципиально.

praseodim ★★★★★
() автор топика
Ответ на: комментарий от melkor217

Хотя строгого доказательства не видно.

Вообще интересно получается - доверяют алгоритму aes (к примеру), но забывают, что на практике есть еще одна потенциальная точка уязвимости - хеш.

praseodim ★★★★★
() автор топика

итерации хэша не сужают в итоге количество вариантов

AFAIR оно не так работает. Они значала нецензурно раздувают пароль(например в 100Краз и более), а потом это скармливают хешу. Результат настолько надёжен, насколько хеш равномерен и необратим, и почти всегда лучше, чем то, что пользоавтель способен запомнить/ввести.

DonkeyHot ★★★★★
()

Но доказано ли, что итерации хэша не сужают в итоге количество вариантов (не уменьшают энтропию)?

Не доказано. И скорее всего, уменьшают, но совсем незначительно.

А вообще, да - все эти линейные способы замедлить перебор - та еще фигня, хороший пароль и с 1 итерацией хеша не сбрутишь. Собственно, увеличение длины случайного пароля на 3 символа будет куда круче увеличения кол-ва итераций хеша в 200к раз.

Ну а если пароль словарный - то уже ничего не поможет.

segfault ★★★★★
()
Ответ на: комментарий от segfault

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

хороший пароль и с 1 итерацией хеша не сбрутишь.

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

Но вообще в Luks меня смущает то, что они оставили возможность прямой проверки корректности введенного пароля, а вот dm-crypt напрямую

praseodim ★★★★★
() автор топика
Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от praseodim

Однако скорость брута в этом случае может достигать миллиардов хешей в секунду даже на домашней машине с мощной видеокартой.

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

длинный несловарный пароль очень трудно запомнить.

Так сложно запомнить 20 случайных символов?

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

Десятки тысяч в секунду на той самой домашней машине с мощной видеокартой. Если выбирать 2 слова из словаря на 40к, то вариантов будет около 1.6е9, т.е. на 10 суток перебора. И это без учета вероятностей слов и применения вычислительных кластеров...

segfault ★★★★★
()
Последнее исправление: segfault (всего исправлений: 2)
Ответ на: комментарий от segfault

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

Вопрос в том, кто управится? Если использовать не видеокарты, а специальные асики для подбора, то скорость будет еще раз в 100 выше. Кластер из 1000 асиков в этом случае может развить скорость в триллион хешей в секунду или даже 10 триллионов. Понятно, что очень немного найдется организаций с такими ресурсами, но мы вроде как теоретически рассуждаем об устойчивости. А если асиков будет больше 1000? ИМХО, но получается, что перебор 10^18 ... 10^19 степени паролей за месяц работы - это в принципе технически ожидаемая атака.

Так сложно запомнить 20 случайных символов?

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

Если выбирать 2 слова из словаря на 40к, то вариантов будет около 1.6е9, т.е. на 10 суток перебора. И это без учета вероятностей слов и применения вычислительных кластеров...

Кхм, да, это я не подумал. Но если еще одно слово, то уже три слова будет нереально подобрать без суперкомпьютерных мощностей.

praseodim ★★★★★
() автор топика
Ответ на: комментарий от praseodim

ИМХО, но получается, что перебор 10^18 ... 10^19 степени паролей за месяц работы - это в принципе технически ожидаемая атака.

Если говорить про 16-символьные случайные пароли (про 20 я загнул, у меня таких нигде нет, хотя и не вижу с ними проблем), то там перебор уже порядка 10^30.

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

Сочувствую. Но не станет ли то же самое с паролями из слов?

segfault ★★★★★
()
Последнее исправление: segfault (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.