Если моя длина ввода меньше выходной длины хэша, существуют ли какие-либо алгоритмы хэширования, которые не гарантируют никаких столкновений.Алгоритмы хеша SQL Server
Я знаю, что односторонний хеш может иметь коллизии на нескольких входах из-за потери характера хэширования, особенно если учитывать размер входного сигнала часто больше выходного размера, но все же он применяется с меньшими размерами ввода?
Используйте симметричный блочный шифр со случайным образом выбранным статическим ключом. Шифрование никогда не может создать дубликат, поскольку это предотвратит однозначное дешифрование.
Эта схема заставит определенную длину вывода быть кратной размеру блока шифрования. Если вы можете использовать вывод переменной длины, вы также можете использовать шифр потока.
Ваш вопрос звучит так, будто вы ищете идеальную функцию хэша. Проблема с идеальными хеш-функциями заключается в том, что они, как правило, адаптируются к конкретному набору данных.
Ниже предполагается, что вы не пытаетесь скрыть, безопасный или зашифровать данные ...
думать об этом еще один способ, самый простой способ «создать» идеальную хеш-функцию, которая будет принимать ваши входы состоит в том, чтобы сопоставить данные, которые вы хотите сохранить в таблице, и связать эти входы с суррогатным первичным ключом. Затем вы создаете уникальное ограничение для столбца (или столбцов), чтобы гарантировать, что входные данные, которые вы отображаете, сопоставляются только с одним суррогатным значением.
Суррогатный ключ может быть int, bigint или guid. Все зависит от количества строк, которые вы хотите сохранить.
Если ваши длины входного сигнала известны как маленькие, например 32 бита, то вы можете фактически перечислить все возможные входы и проверить полученные хэши для коллизий. Это будет всего лишь 4294967296 возможных входных данных, и не нужно долго ждать, чтобы перечислить их все. По существу, вы бы строили стол радуги, чтобы проверить наличие столкновений.
Если есть какая-то защита, основанная на этом, одна из проблем заключается в том, что злоумышленник знает, что ваши длины ввода ограничены, что облегчает им также выполнение одного и того же перечисления для создания карты/таблицы, которая будет отображать хэш возвращается к исходным значениям. «Нападающий» - довольно ужасный термин здесь, хотя из-за того, что у меня нет контекста того, как вы используете эти хэши, и обеспокоены ли вы тем, что можете их отменить.
Я бы посмотрел на эти сообщения [ссылка 1] (http://stackoverflow.com/questions/4676828/when-generating-a-sha256-512-hash-is-there-a-minimum-safe-amount -of-data-to) [ссылка 2] (http://stackoverflow.com/questions/4676828/when-generating-a-sha256-512-hash-is-there-a-minimum-safe-amount-of-of- данные к). – Xedni
@ Xedni, ваши ссылки, похоже, предназначены для того же поста –
@ Dave.Gugg Один для каждого глаза? – AaronLS