Как вам мой алгоритм хэширования?

Question

[Tolik]

Создал свой собственный алгоритм хэширования. При смене одного бита полностью меняется хэш, длина его всегда 64 (если не считать пробелов). На диапазоне 00000..99999 ни одной коллизии. Правда работает медленно (относительно sha* например). Но с другой стороны, это защита от подбора или поиска тех самых коллизий. Вот собственно код.

P.S. Делал всё как-нибуть и по этому константы являются рандомными числами, получеными питоновским скриптом:
["%.8X" % random.randint(0, 2 ** 32 - 1) for i in range(0, 8)]

P.P.S. Если понравился, можете спокойно юзать. Я не из АНБ :)

Модеры, вы зачем ответы удаляете? Я так ржал, а вы убрали и всё. Даже если там жесткая критика, смешно ведь. Если можно, верните ответы=)

UPD: Коллизии -- одно. Но я встречал в хэшах по 3-5 однаковых цыфр под ряд (в одном из восьми чисел, из которых состоит хэш). Я уверен, что это дыра. Попробую ее заделать

Answer 1

[jcmvbkbc]

Внутреннее состояние в unsigned int и char *data -- это ошибки: char бывает знаковым и беззнаковым, а int может иметь разную ширину в зависимости от системы.
Дальше, вы замешиваете входные данные в хэш побайтово, это дыра для дифференциального криптоанализа.
Дальше, состояние вы тащите в интах, а за время хеширования одного байта у вас состояние не прокручивается полностью (ваши сдвиги, максимум на 3, за цикл хеширования сдвинут состояние максимум на 24 бита из 32). Мало того, что это неряшливо, это также значит, что старшие и младшие части слов хеша будут иметь разную структуру.
Короче, даже без углубления в анализ видно, что алгоритм непродуман и слаб.

Правда работает медленно (относительно sha* например).

При том, что даже sha1 делает больше раундов, чем ваше произведение.

если не будет совпадений, то возможно он нормальный

К тому же вам, очевидно, не хватает знаний о том, как оценивается качество криптографических хеш-алгоритмов.

Comments

[Tolik]

Спасибо, на данный момент это самый полезный ответ. Я всего лишь учусь в школе (последний класс) по этому быть криптографом мне пока не суждено. Написал что смог

[jcmvbkbc]

@Diel Чтобы избежать известных глупых ошибок имеет смысл изучать существующие алгоритмы/их реализации, задаваясь вопросом, почему то или иное место сделано так, как сделано. И это применимо не только к криптографии (:

[Tolik]

@jcmvbkbc а согласитесь всё-таки, подбирать мое дело не просто:) Только если большой дядька не найдет большую дыру

[jcmvbkbc]

> согласитесь всё-таки, подбирать мое дело не просто
@Diel если вы готовы назначить денежный приз за нахождение коллизии, скажем $1000, я бы поучаствовал. (:

[Tolik]

@jcmvbkbc сам могу поставить ноут на ночь, пусть пишет в файл. На следующий день бы поискал одинаковые строки. Или бы написал полностью автоматический скрипт

[jcmvbkbc]

@Diel конечно можете, однако это упражнение даст вам не ответ на вопрос "сложно ли подобрать строку, дающую коллизию", а ответ на вопрос "нет ли коллизий среди рассмотренных вами строк".

Answer 2

[Push Pull]

Спасибо, давно так не смеялся, без обид, но таких хеш функций можно в день штук 10 делать.
По коду ничего особенного не вижу. Вам скучно было, вот и поделились?

Comments

[Tolik]

Как-то так

Answer 3

[Spetros]

Длина 64 в каких единицах? В битах? Тогда диапазон 00000..99999 входных значений для поиска коллизий слишком мал.

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

Comments

[Tolik]

Как вы поняли, "длина 64" это 8 unsigned int'ов. Ну а на счет счетчиков, могу поставить unsigned long long length или переделать что бы хэшировалось пока какая-то глобальная переменная имеет конкретное значение (в то время другой поток подает данные)

Answer 4

[throughtheether]

Во-первых, для школьника неплохо. Во-вторых, лично мне непонятна сфера применения этой хэш-функции. Для проблем, связанных с безопасностью, уже есть проверенные решения. Для проблем, связанных с детерминистским распределением объектов по контейнерам (пример: разделение нагрузки а-ля etherchannel, ECMP) она слишком медленная. В-третьих, автор будет еще большим молодцом, если самостоятельно найдет коллизии.

константы являются рандомными числами

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

Comments

[Tolik]

Хотелось бы использовать ее вместо извесных sha* и др. "популярных" алгоритмов. Это потому что большинство этих алгоритмов написаны АНБ и плюс лень разбиратся как их использовать, уж легче свое написать:) Правда если удастся довести ее до совершенства, на что шансов мало...