Ищете алгоритм хеширования, в котором небольшое изменение ввода приведет к небольшому изменению хеша

Как насчет простого суммирования? Затем ваш хэш может быть обернут до желаемого размера, и если вы примете это во внимание при сравнении хешей, небольшая разница во входных данных должна дать небольшую разницу в хешах.

Однако я думаю, что «минимальные коллизии» и «пропорциональное изменение выпуска» - цели противоречивые.

Извините, неправильно прочитал ваш вопрос. MD5 или SHA-x - это не то, что вам нужно.

Согласно Википедии, например, https://en.wikipedia.org/wiki/Substitution_cipher имеет нет лавинного эффекта (это вы имеете в виду под этим словом).

Что касается хеширования, вы можете использовать какое-то общее число.

Например:

char* hashme = "hallo123";
int result=0;
for(int i = 0; i<8; ++i) {
   result += hashme[i];
}

Надеюсь, теперь это поможет больше.

В других областях это называется перцептивным хешированием.

Один из подходов к этому заключается в следующем:

1. Получите обучающий мультимножество n-граммов. (Например, если n = 2 и ваши тренировочные данные были «Это тест», ваш тренировочный набор будет «Th», «hi», «is», «s» и т. Д.)
2. Отсортируйте и вычислите частоты указанных n-граммов по убыванию.

Тогда хеш слова - это первые биты "для каждого n-грамма в базе данных, является ли частота этого слова на n-грамм выше, чем средняя частота?"

Обратите внимание, что это может и приведет к множеству столкновений с похожими словами, к сожалению, если только длина хеша не будет абсурдно длинной.

Возможно, он ориентирован на детей, но старый В детском отделе АНБ есть несколько действительно хороших идей.

Конечно, эти алгоритмы действительно небезопасны, поэтому вы не можете использовать их вместо НАСТОЯЩЕГО шифрования. (Но вы также не можете использовать настоящий алгоритм шифрования, когда просто хотите повеселиться.)

Сетка чисел включает настройку сетки с последующим использованием координат каждой буквы:

Дальнейшие идеи:

• Смешайте буквенное расположение
• Преобразование чисел в двоичное для обфускации

Извилистый путь также использует сетку. По сути, буквы располагаются в сетке слева направо рядами вниз. Результат получается путем вертикального разреза сетки:

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

В качестве небольшого отступления о том, почему эти алгоритмы ведут себя так: они по необходимости разработаны, чтобы скрыть статистические отношения между входом и выходом, чтобы их было труднее взломать. Например, в английском языке буква «е» является наиболее часто используемой буквой; в некоторых очень слабых классических шифрах вы можете просто найти наиболее распространенную букву и цифру, которые соответствуют «е» (например, если n - самая распространенная буква, то шансы равны n = e). Фактически, описанный вами статистический шаблон, вероятно, сделает алгоритм значительно более уязвимым для атак с выбранным открытым текстом, известным открытым текстом, человеком в середине и повторным воспроизведением.

Атаки «человек посередине» и «повторное воспроизведение» были бы значительно проще, поскольку было бы намного проще редактировать зашифрованный текст для получения желаемого открытого текста, не зная ключа (особенно если у вас есть доступ к паре выбранных открытых текстов).

Если ты знаешь это

7/19/2016 1:35 transfer $10 from account x to account y

(где отметка даты используется для защиты от атаки повторного воспроизведения) кодируется как

12345678910

в то время как

7/19/2016 1:40 transfer $10 from account x to account y

кодирует в

12445678910

это довольно безопасное предположение, что

12545678910

будет означать что-то вроде

7/19/2016 1:45 transfer $10 from account x to account y

Не имея доступа к исходному ключу, вы могли бы регулярно воспроизводить этот пакет, чтобы продолжать кражу денег с чьей-либо учетной записи, просто внося тривиальные изменения. Конечно, это довольно надуманный пример, но он все же иллюстрирует основную проблему.

Насколько я понимаю, то, что вы ищете, - это статистическое сходство между файлами. Некоторым это может помочь: https://en.wikipedia.org/wiki/Semantic_similarity

Это действительно существует. Этот термин - хеширование с учетом местоположения. Конкретную реализацию можно найти здесь: https://github.com/trendmicro/tlsh. В зависимости от исходного документа вам может потребоваться цифровая криминалистика или VisualRank (от Google) для поиска похожих изображений и видео. Для текстовых данных это обычно используется в антиспаме (подробнее см. Здесь: http://spdp.di.unimi.it/papers/pdcs04.pdf). Для двоичных файлов вы можете сначала запустить дизассемблер, а затем запустить алгоритм в текстовой версии - но это только мое ощущение, у меня нет исследований, подтверждающих это утверждение, но это было бы интересной гипотезой для проверки.