LINUX.ORG.RU

Подскажите по hash алгоритмам

 


0

3

1) Нужен быстрый алгоритм создания хеш сумм.
2) Как узнать информацию о предельном объеме данных, при которых использование хешсуммы уже не безопасно или не актуально? Имеется ввиду, что md5 на 2 гб файле уже не особо имеет смысл, а вот несколько хешсум на частях этого файла (как в торрент файлах) имеет. Вот я и хочу узнать размер этих частей.

UPD: Решение тут - Подскажите по hash алгоритмам (комментарий)

★★★★★

Последнее исправление: reprimand (всего исправлений: 4)

Имеется ввиду, что md5 на 2 гб файле уже не особо имеет смысл

А почему? Такая большая вероятность случайной коллизии?

Falcon-peregrinus ★★★★★
()

Вот тут пишут, что самый быстрый хэш - у NTLM.

Касательно предельного объема данный - не понял вопроса.

CaveRat ★★
()
Ответ на: комментарий от Falcon-peregrinus

Вероятность коллизии зависит не от объема данных, с которых снимается хэш, а от длины самого хэша, не?

CaveRat ★★
()
Ответ на: комментарий от Falcon-peregrinus

Понятия не имею. Просто знаю на примере торрентов, что на больших файлах принято хешировать чанками (т.е. частями).

Естественно, я могу взять цифру от балды типа 1024мб, но хотелось бы информации почему так делают.

reprimand ★★★★★
() автор топика
Ответ на: комментарий от CaveRat

Вероятность коллизии зависит не от объема данных, с которых снимается хэш, а от длины самого хэша, не?

я не силен в хеш алгоритмах, но разве, к примеру, md5 проходит по каждому байту файла (пусть это будет 10гб файл)?

reprimand ★★★★★
() автор топика
Ответ на: комментарий от reprimand

Я не готов сказать про внутреннее устройство того или иного алгоритма, но хэш-функция возвращает значение одинакового размера вне зависимости от размера входящего сообщения.

CaveRat ★★
()
Ответ на: комментарий от Falcon-peregrinus

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

Особенно если ценность целостности данных не 100%, а 99%...

reprimand ★★★★★
() автор топика
Ответ на: комментарий от CaveRat

хэш-функция возвращает значение одинакового размера вне зависимости от размера входящего сообщения

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

reprimand ★★★★★
() автор топика
Ответ на: комментарий от reprimand

Не понял вопроса. Да, исходное сообщение влияет на результат. Или вопрос в том, повысит оно или понизит вероятность коллизии? AFAIK, никак не отразится.

CaveRat ★★
()
Ответ на: комментарий от CaveRat

у тебя 10 гб данных

в определенной точке ты поменял какой-то бит

есть ли вероятность НЕ отражения этого на конечный результат?

reprimand ★★★★★
() автор топика
Ответ на: комментарий от reprimand

есть ли вероятность НЕ отражения этого на конечный результат?

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

CaveRat ★★
()
Ответ на: комментарий от CaveRat

спасибо большое! то, что надо! =)

reprimand ★★★★★
() автор топика
Ответ на: комментарий от CaveRat

Вообще это верно не только для криптографических хэш-функций, но и для CRC, Adler-32 и т.п.

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)
Ответ на: комментарий от reprimand

Потому что они качаются кусками. И раздаваться начинают тоже кусками

anonymous
()

Есть прикидочное правило - коллизии точно будут, когда количество хэшированных/хэшируемых элементов больше квадратного корня длины хэша. Можно почитать про birthday paradox.

CaptainFarrell
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.