Это должно хорошо усечь хеш SHA256 к 128 битам?
MD5 и хеши SHA-1 имеют слабые места против нападений коллизии. SHA256 не делает, но он производит 256 битов. Я могу безопасно взять первые или последние 128 битов и использование что как хеш? Я знаю, что это будет более слабо (потому что это имеет меньше битов), но иначе это будет работать?
В основном я хочу использовать это для однозначного определения файлов в файловой системе, которая могла бы однажды содержать триллион файлов. Я знаю о проблеме дня рождения, и хеш на 128 битов должен уступить о 1 в триллионе, случайно натыкаются на триллион файлов, что было бы два различных файла с тем же хешем. Я могу жить с теми разногласиями.
То, с чем я не могу жить, - то, если кто-то мог бы легко, сознательно, вставить новый файл с тем же хешем и теми же начальными символами файла. Я верю в MD5 и SHA1, это возможно.
3 ответа
Да, это сработает.
Для справки, существуют известные используемые атаки коллизий против MD5, но атаки SHA-1 на данный момент являются полностью теоретическими (коллизии SHA-1 никогда не обнаруживались ... пока).
Да, это сработает. Теоретически лучше выполнить XOR двух половин вместе, но даже усеченный SHA256 сильнее, чем MD5. Тем не менее, вы все равно должны рассматривать результат как 128-битный хеш, а не 256-битный.
Моя особая рекомендация в этом конкретном случае - хранить и ссылаться с использованием уникального HASH +, где uniquifier - это количество различных файлов, которые вы видели с этим хешем раньше. Таким образом, вы абсолютно не упадете, если кто-то попытается сохранить будущие обнаруженные векторы столкновений для SHA256.
Но стоит ли оно того? Если у вас есть хэш для каждого файла, то у вас, по сути, есть накладные расходы для каждого файла. Предположим, что каждый файл должен занимать не менее 512 байтов (типичный сектор диска), и что вы храните эти хэши достаточно компактно, чтобы каждый хеш занимал намного больше, чем размер хэша.
Итак, даже если все ваши файлы имеют размер 512 байт, самый маленький, вы говорите либо 16/512 = 3,1% , либо 32/512 = 6,3% . На самом деле, я готов поспорить, что ваш средний размер файла выше (если все ваши файлы не имеют 1 сектор ...), так что накладные расходы будут меньше.
Теперь объем пространства, необходимого для хэшей, линейно зависит от количества файлов, которые у вас есть. Стоит ли это дополнительное пространство столько ? Даже если бы у вас был упомянутый триллион файлов - это 1 000 000 000 000 * 16 = ~ 29 ТиБ , что много места, но имейте в виду: ваши данные будут 1 000 000 000 000 * 512 = 465 ТиБ . На самом деле цифры бесполезны, так как накладные расходы по-прежнему 3% или 6% .Но на этом уровне, где у вас есть полпетабайта памяти, имеет ли значение 15 терабайт? На любом уровне означает ли что-нибудь экономия 3% ? И помните, если они больше, вы экономите меньше. (Что, вероятно, так и есть: удачи с размером сектора 512 байт при таком размере жесткого диска.)
Итак, стоит ли экономия на диске 3% или меньше потенциального риска для безопасности. (Который я оставлю без ответа, так как это не моя чашка чая.)
В качестве альтернативы, не могли бы вы, скажем, логически сгруппировать файлы вместе, чтобы у вас было меньше файлов? (Я имею в виду, если у вас есть триллионы файлов по 512 байт, вы действительно хотите хешировать каждый байт на диске?)