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

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

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

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

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

Вы можете:

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

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

ОТВЕТЫ

Ответ 1

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

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

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

  • SHA256 был достаточно одинок, если возникли проблемы; мы должны были увидеть их к настоящему времени.
  • Это не "более сильный" per se, у него меньше шансов произвести столкновение (если это ваши критерии для более сильного, то да, это сильнее).
  • SHA-256 работает медленнее; да. Гораздо медленнее? В зависимости от ваших потребностей. Для 95% людей; его производительность приемлема при условии, что вы используете правильную реализацию.
  • В общем, усечение хэша SHA2 является хорошо, что нужно делать.

Ответ 2

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

У хорошо набитого жесткого диска может быть 1M файл. Для эксперимента предположите, что есть 10M файлов. Скажем, что население мира составляет 10.000 млн. Человек, каждый с одним компьютером, и каждый файл отличается.

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

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

2E14/24/365/13500E6 = 1,69

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

Ответ 3

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

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

Ответ 4

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

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