Я предпочитаю думать о криптографии как об инфраструктуре. Мы должны стремиться развивать инфраструктуру, которая сводит к минимуму количество предостережений при использовании.Задача криптографии не в том, чтобы определять, что является «значащими» сообщениями в вашем приложении. Можете ли вы посмотреть на конкретное столкновение $м_1, м_2$ и с уверенностью сказать, что нет применение хеш-функции будет Когда-либо придать этим значениям $m_1$ и $m_2$?
Какую хэш-функцию вы бы предпочли использовать, с гарантией «трудно найти Любые столкновения» или с гарантией «трудно найти столкновение, кроме как иногда среди строк, которые представляют собой JPG песчанок и gzip-файлы Шекспира»? Я бы не хотел водить машину с предупреждающей наклейкой, которая гласила: «Машина может взорваться, вы едете со скоростью 88,1 мили в час с включенным левым указателем поворота и радио, настроенным на 88,1 FM», даже если бы это предупреждение было правильно узким, и я бы никогда не стал делать эти 3 вещи одновременно.
Вот почему определения криптографической безопасности считают коллизию Любые два сообщения, которые удовлетворяют $ Н (х_1) = Н (х_2) $, подделка подписи Любые сообщение является атакой, шифрование Любые открытый текст должен выглядеть неразличимым и т. д. Если вы хотите, чтобы ваша криптография использовалась, убедитесь, что вы стремитесь к гарантии безопасности, которая ставит каждый вольно.
Вторая практическая причина для беспокойства по поводу «неструктурированного» столкновения в $Ч$, заключается в том, что, когда он найден, расширение методов для поиска «структурированных» столкновений часто является вопросом времени. Например, поиск структурированных коллизий в случайной функции (используя классическую атаку коллизий Юваля) примерно такой же сложности, как и поиск неструктурированных коллизий (используя стандартный перебор и привязку к дню рождения).