Односторонний хэш (не для крипто / безопасности), используйте SHA256 (не MD5, SHA-1)?

Question

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

Вспомните, что Scons использует MD5,и Git использует SHA-1.

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

ВОПРОС: Вы бы использовали SHA256 (не MD5 или SHA-1) для однонаправленного (не крипто / безопасности)хэш в новой системе?

Проблемы:

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

Меня особенно заинтересовал бы ответ, согласующийся с тем, что сообщества Scons или Git говорят: «Мы будем оставаться нашими навсегда!» или «Мы хотимВыйдем в новый хэш как можно скорее! " (я не уверен, каковы их планы?)

Answer 1

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

Git пошел с SHA1, потому что они используют его как имена файлов; и они хотели, чтобы он был маленьким и компактным. SHA256 производит намного больший дайджест; занимая больше места на диске и больше данных для передачи по проводам. Этот вопрос конкретно касается того, что произойдет, если git столкнется со столкновениями.

Чтобы посмотреть на ваши очки:

1. SHA256 был в дикой природе достаточно долго, чтобы, если были проблемы; мы бы уже видели их.
2. Само по себе оно не "сильнее", оно с меньшей вероятностью приведет к столкновению (если это ваш критерий "сильнее", тогда да, оно сильнее).
3. SHA-256 медленнее; да. Намного медленнее? Зависит от того, что ваши потребности. Для 95% людей; его производительность приемлема, если вы используете правильную реализацию.
4. В общем, усечение хэша SHA2 - это хорошо, что нужно сделать .

Answer 2

Вероятность не злонамеренного столкновения исчезающе мала, даже с MD5.Вот мысленный эксперимент:

Хорошо заполненный жесткий диск может содержать 1 МБ файлов.Для эксперимента представьте, что есть 10M файлов.Предположим, что численность населения мира составляет 10 000 миллионов человек, каждый из которых имеет один компьютер, и каждый файл отличается.

Мы будем бороться с несколькими различными файлами: 10E6 * 10E9 = 1E17, <2 ^ 57 </p>

Вероятность столкновения MD5 в таком надуманном случае будет меньше, чем 1 в 2 ^ 71, или меньше, чем в приблизительно 2E21!Чтобы представить это в перспективе, для вероятности столкновения 1 на 10М нам пришлось бы повторить эксперимент примерно 2E14 раз, то есть заменить каждый файл, каждый час после Большого взрыва, а затем продолжать работу еще несколько миллиардов лет..

2E14 / 24/365 / 13500E6 = 1.69

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

Answer 3

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

Вы также можете подумать о большемхэши, такие как деревья, используемые Glacier (Amazon) или Branch Cache Hash (Microsoft) или некоторыми одноранговыми сетями, такими как BitTorrent или другие конструкции на основе Merkle или Tiger Tree.

Answer 4

Зависит от того, что вы делаете. Вычисление хэша SHA-256 занимает намного больше времени. Не имеет большого значения для многих приложений, но что, если ваше приложение пытается вычислять сотни или тысячи в минуту? Вы можете найти дополнительное время слишком много.

С другой стороны, у SHA-1 вероятность столкновения намного выше, чем у SHA-256. Однако следует понимать, что такие шансы ничтожны (1 в 2 ^ 160/2, я думаю, для SHA-1) и, вероятно, никогда не будут затронуты большинством приложений. Тем не менее, чем больше вещей вы хэшируете, тем выше вероятность. Если вы хэшируете миллионы или миллиарды вещей, это может быть проблемой.