Рейтинг:4

Почему слишком быстрая хэш-функция небезопасна?

флаг cn

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

kelalaka avatar
флаг in
Откуда вы взяли, что "очень быстрая хеш-функция может вызвать коллизию"? О какой хэш-функции вы говорите? Какое приложение вы рассматриваете? Знаете ли вы, что алгоритмам хеширования паролей не нужна устойчивость к коллизиям?... Какую метрику вы используете для слишком быстрой работы?
Seif Ashraf avatar
флаг cn
проверьте это: https://youtu.be/b4b8ktEV4Bg?t=279
kelalaka avatar
флаг in
Я вижу, исходя из аргументов видео, я [написал на них ответ](https://crypto.stackexchange.com/a/95430/18298)
Рейтинг:22
флаг ng

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

В приложении делать растяжка ключей, включая управление доступом по паролю или получение симметричного ключа шифрования из парольной фразы, желательно иметь медленные хеш-функции. Точнее, параметр должен контролировать продолжительность, а вычислительная стоимость хэша не должна быть для злоумышленников намного ниже, чем для законных пользователей¹. В таких приложениях, когда нам удается замедлить хэш в раз $с$ для противников мы получаем эквивалент $\log_2(с)$ дополнительные биты энтропии при вводе пароля/парольной фразы. Например, когда мы увеличиваем стоимость на тысячу (для $с\приблизительно 2^{10}$ ), что касается атак со взломом пароля, мы получаем безопасный эквивалент добавления трех случайных десятичных цифр к паролю без необходимости их запоминать.

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

  • Что хэш достаточно широкий, потому что существуют общие, эффективно распределенные атаки², которые находят коллизии в $n$-битный хэш с примерно $2^{n/2+2}$ хеши. Таким образом, любой быстрый хэш с результатом менее 192 бит (плюс-минус 32) подвержен коллизии (для злоумышленников со средствами, сравнимыми с теми, которые используются некоторыми майнерами биткойнов). Когда мы делаем хэш медленнее, это увеличивает вычислительные затраты на поиск коллизии. Увеличение стоимости в несколько раз $с$ позволяет сузить хэш примерно $2\log_2(с)$ немного с точки зрения устойчивости к коллизиям (предостережение: для очень быстрых хэшей, которые могут применяться только для $с$ мимо какого-то небольшого порога). Например, если вместо SHA-224 мы использовали PBKDF2-HMAC-SHA-256 со 184-битным выходом и шестьюстами тысячами итераций (для $с\приблизительно 2^{20}$ ), мы получили бы сравнимую защиту от столкновений.
  • То, что хэш не такой быстрый, объясняется чрезмерным упрощением его внутренностей, позволяющим проводить различные специфические атаки. Как крайность, исключающее ИЛИ блоков ввода такой же ширины, как и вывод является чрезвычайно быстрым хэшем, но он тривиально не устойчив к коллизиям. Есть нападения на MD5, ША(-0) и ША-1, возможно, потому, что в их дизайне слишком много внимания уделялось скорости. И есть нападения³ против ША-256 если мы уменьшим количество раундов до 31 (вместо 64).

¹ Лучший способ добиться этого — сделать хэш плохо запоминающий, то есть его оценка должна требовать много обращений к памяти в большом объеме памяти, выделенной для этого использования в течение всей оценки. К таким функциям относятся современные Аргон2, скрипти в какой-то степени устаревшее bcrypt, но не прям плохо ПБКДФ2 (что катастрофично, потому что низкий объем оперативной памяти дает огромное преимущество злоумышленникам с ASIC, FPGA или графическими процессорами по сравнению с большинством пользователей, использующих ЦП).

² См. Пола К. ван Оршота и Майкла Дж. Винера. Параллельный поиск столкновений с помощью криптоаналитических приложений, в Журнал криптологии, 1999 г..

³ См. работы Флориана Менделя, Томислава Над и Мартина Шлеффера. Улучшение локальных столкновений: новые атаки на сокращенный SHA-256, в материалы Еврокрипт 2013

флаг za
```если бы это было сверхбыстро, это не было бы проблемой``` - [blake3 передает привет](https://github.com/BLAKE3-team/BLAKE3/blob/master/media/speed.svg)
kelalaka avatar
флаг in
@hanshenrik Blake3 — это параллельный хэш. Настоящее сравнение можно провести только с ParallelHash [который является производным от SHA3] (https://csrc.nist.gov/projects/hash-functions).
флаг za
@kelalaka blake3 поддерживает распараллеливание, да, но этот тест основан на запуске blake3 только с одним потоком, без параллелизма в этом тесте! (если бы они использовали распараллеливание, blake3 работал бы даже быстрее, чем показано на этой диаграмме)
Рейтинг:9
флаг jp

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

Это не случай «быстрого хэша == слишком мало битов вывода», как спросил OP. Просто, если хэш слишком быстрый, слишком легко найти исходный ввод (а не коллизию), что делает его небезопасным.

Maarten Bodewes avatar
флаг in
Я не согласен с этим. Например, хэширование паролей, все, что вас интересует, это *разница* скорости между сервером / предполагаемым пользователем и противником. Тем не менее, это можно исправить, убедившись, что вы используете быструю реализацию и убедитесь, что существует значительный коэффициент работы/количество итераций. Это, однако, имеет мало общего со скоростью используемой криптографически защищенной хеш-функции. Эту проблему можно решить, сделав более явной разницу между криптографически безопасной хэш-функцией и хэшем пароля.
Рейтинг:3
флаг id

Учитывая хеш-функцию, которая настраивается на «скорость» (возможно, итерации), увеличение скорости, с которой она хеширует, не Создайте больше столкновений. Проблема безопасности со слишком быстрым хэшем заключается в том, что при заданном количестве времени X более быстрый хеш будет генерировать большее количество выходных данных, поэтому у злоумышленника больше шансов найти столкновение.

Рейтинг:2
флаг in

ОП получил идею от пост на ютубе что спорит вокруг MD5.

Вот простой аргумент, если кто-нибудь смотрит видео.

Скорость не означает, что хеш-функция небезопасна, дизайн делает ее безопасной..

С годами исследователи находили слабые места в конструкции MD5 и со временем совершенствовали ее. После выпуска MD5 в 1992 году начались атаки, а в 2010 году Се и Дэнго Фэн объявили первая опубликованная одноблочная (512-битная) коллизия MD5. Конечно, улучшение процессоров и их циклов помогает проводить атаки быстрее, однако основной вклад вносят методологии атак. Учтите, что общая атака столкновений (атака дня рождения) требует $2^{64}$ Хэши MD5 с вероятностью успеха 1/2. Даже сегодня ни один обычный процессор не может $2^{64}$ в разумное время. С другой стороны, теперь у нас есть мгновенное столкновение для MD5, увидеть корками.

С другой стороны, Blake2 является очень быстрая хэш-функция, быстрее, чем MD5 и SHA-1, и не имеет атаки с расширением длины, поскольку использует ХАЙФА структура, исправления оформления МД. Это быстрее, чем MD5 и безопасно по крайней мере, в обозримой особенности. Его выходной размер достаточно безопасен для массивных параллельных атак или даже для Алгоритм квантового поиска Гровера. Серия Blake теперь имеет БЛЕЙК3, это параллельный хеш и очень быстро.

Что важно в скорости и ее отношении к безопасности, так это размер дайджеста. Общие атаки для атаки по прообразу, вторичной атаки по прообразу и общего столкновения: $2^n$,$2^n$, и $2^{n/2}$, соответственно. Если у вас есть 256- или 512-битный вывод, у вас все в порядке с общими атаками. Имейте в виду, что короткое поле ввода является проблемой для атак с предварительным изображением, и рекомендуется использовать HMAC.


PS: хеширование пароля (не требуется сопротивление столкновению), где мы хотим контролируемую скорость, твердость памятии количество потоков хэш-функции пароля. Надо читать канонический вопрос с нашего почтенного сайта, информационной безопасности.. Также, Аргон2 бумага, победитель конкурса хеширования паролей 2015 года, является хорошим выбором для чтения.


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

Рейтинг:0
флаг my

Давайте рассмотрим использование хеша для защиты пароля и рассмотрим пару примеров.

  • Первый случай: у нас есть хэш-функция, которая принимает 1 секунда выполнить на обычном компьютере. Если злоумышленник имеет доступ к 1 миллиону компьютеров (например, через ботнет), он может совершать 1 миллион попыток в секунду, 86 миллиардов попыток в день. Но 8-символьный пароль с использованием старших, младших, цифр и символов составляет около 50 бит энтропии, поэтому при текущей производительности он по-прежнему будет занимать в среднем около 18 лет взломать этот пароль, даже с этим массивным ботнетом (конечно, через 18 лет все, вероятно, ускорится довольно сильно, поэтому он будет короче, но все же). В худшем случае это займет 36 лет.

  • Второй случай: у нас есть хеш-функция, которая принимает 1 микросекунда выполнить. Тот же злоумышленник, использующий тот же ботнет с миллионом компьютеров, теперь может совершать на миллион попыток больше в секунду. Теперь это занимает 1125 секунд (менее 20 минут), чтобы попробовать каждый из примерно 2 ^ 50 возможных 8-символьных паролей. Так что в среднем примерно в половине случаев.

Если вы думаете, что ботнет с миллионом компьютеров — это фантастика, подумай еще раз.

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

Ответить или комментировать

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