Столкновение с хэшем и солью - PullRequest
4 голосов
/ 09 марта 2009

Я помню, как один парень сказал мне, что, если я позволю ему изменить 4 байта, он может сделать для файла любую контрольную сумму, какую захочет ( CRC-32 ).

Я слышал упоминание о засолке хеша. Мне интересно, если бы кто-то совпадал с моим файлом, мой файл засолил бы хеш MD5 или SHA-1 и изменил бы результат, чтобы оба файла больше не сталкивались? Или это только изменение конечного хеш-значения?

Ответы [ 4 ]

6 голосов
/ 09 марта 2009

Вы смешиваете два разных использования хеш-значений:

  • Контрольная сумма для защиты от случайных (не вредоносных) ошибок.

  • Вычисление криптографических дайджестов сообщений для хранения паролей, подписи сообщений, сертификатов ...

CRC - хороший выбор для первого приложения, но совершенно не подходит для второго, поскольку вычисление коллизии легко (в математике: CRC являются линейными). Это то, что ваш друг по сути говорит вам.

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

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

4 голосов
/ 09 марта 2009

Атака (против CRC-32) не имеет значения, если используемый вами хэш не является CRC-32 - MD5 и SHA-1 не подвержены такого рода атакам (еще).

Текущие атаки на MD5 - это когда злоумышленник создает два документа с одинаковым хешем.

Соли используются для проверки пароля - они не позволяют злоумышленнику выполнить автономную атаку на базу паролей - каждый пароль пользователя имеет соль, присоединенную к простому тексту перед хэшированием - затем предварительно вычисленную радужную таблицу открытого текста <- > Хешированный текст бесполезен.

1 голос
/ 09 марта 2009

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

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

0 голосов
/ 09 марта 2009

Соление обычно используется в хешах паролей, чтобы избежать атак по словарю. Существует множество веб-словарей обратного хеширования, в которых вы вводите хеш (например, 1a79a4d60de6718e8e5b326e338ae533) и возвращаете текст: «пример». С солью это становится почти невозможным. Если вы добавите пароль со случайной солью, атака по словарю станет более сложной.

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

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

...