Алгоритм хэширования

Привет.



Подскажите алгоритм хэширования!



У меня много файлов (на разных компах), мне надо найти

изменённый, (...)

Я хочу найти хэш файла а потом сравнивать!



Скажите какой хороший??? Чтобы без коллизий !

Спасибо!



слышал про SHA?? это оно?

 

а нельзя ли просто время посл. модификации фиксировать?

 

неа, хекс-редакторы да и обычный патч восстанавливают даты (GetFileTime\SetFileTime)



MD5 в три раза быстрее SHA1, обычно используют именно его

 

Посмотри спецификацию Tiger, он быстро вычисляется и вроде без слабостей и коллизий.

 

если требуется определить только модификацию, достаточно использовать crc32, поговаривают, что по скорости он сравним с md5, но зато реализация много проще.
а если трбуется хорошая хеш-функция, чтобы без коллизей и стойкая (на сегодняшний день), я бы смотрел в сторону sha256.
Читай Шнайдера, пока его еще более-менее легко найти в продаже.
А если тебе кажется удобным читать с экрана - на drmist.narod.ru в самом низу ссылка на электронную версию (исходные коды прилогаются).
В аттаче к этому посту ты найдешь исходники crc32, sha1 и sha256 на си.

 

CRC-32 на асм

Код (Text):

1. format PE GUI 4.0
2. entry start  
3.  
4. include 'win32a.inc'
5. section '.data' data readable writeable
6.   CrtTable rd 256
7.   test_str db '123456789'
8.  
9. section '.code' code readable executable
10.   start:
11. xor ebx, ebx
12. mov edx,CrtTable
13. InitTableLoop:
14. xor eax, eax
15. mov al, bl
16. xor ecx,ecx
17. entryLoop:
18. test eax, 1
19. jz no_topbit
20. shr eax, 1
21. xor eax, 0edb88320h
22. jmp entrygoon
23. no_topbit:
24. shr eax, 1
25. entrygoon:
26. inc ecx
27. test ecx, 8
28. jz entryLoop
29. mov dword [ebx*4 + edx], eax
30. inc ebx
31. test ebx, 256
32. jz InitTableLoop
33.  
34. mov eax,-1
35. mov esi,test_str
36. mov ecx,9
37.  
38. computeLoop:
39. xor ebx, ebx
40. xor al, [esi]
41. mov bl, al
42. shr eax, 8
43. xor eax, dword [4*ebx + CrtTable]
44. inc esi
45. loop computeLoop
46. xor eax, 0FFFFFFFFh
47.  
48.   exit:
49.     invoke ExitProcess,0
50.  
51.  
52. section '.idata' import data readable writeable
53.   library kernel32,'KERNEL32.DLL'
54.   include '\apia\kernel32.inc'

 

в разделе исходников не так давно выкладывали сорсы крипто- и хэш-функций. там все это имеется.

 

Совсем без коллизий НЕЛЬЗЯ, это все-таки ХЕШ, а не побайтовое сравнение. На практике для такой задачи вполне достаточно CRC-32... да даже CRC-16 вполне потянет.

 

iamlamer
там под коллизиями обычно понимается не то, что один хеш так или иначе может соответствовать двум буферам, а то, что можно иначе, нежели перебором, подобрать два одинаковых хеша к одному буферу. кажется так.

К исходнику Crazy_Death хочу добавить, что CrtTable как правило считается зарание. Кроме полинома 0edb88320h иногда используется 004c11db7h, то есть уществует как минимум две функции crc32 с разными таблицами.

 

0edb88320h это перевётрнутый 004c11db7h
11101101101110001000001100100000
100110000010001110110110111

 

2 drmist "Кроме полинома 0edb88320h иногда используется 004c11db7h"

а в чем разница? 0edb88320h - использутеся в zip,rar
а 004c11db7h где?

 

Используйте любой неприводимый в поле GF(2) полином 32й степени... И будет вам счастье)

 

asmfan

Используйте любой неприводимый в поле GF(2) полином 32й степени... И будет вам счастье)

Только это будет уже не CRC-32, потому что "CRC-32" это не только аббревиатура от "циклического изыбточного кода", а что-то типа торговой марки, жестко зафиксированного наименования для жестко зафиксированного алгоритма, описанного в разных там IEEE, ISO, RFC и пр. Можно юзать любую подходящий порождающий полином, даже если для него математически строго доказано, что он не хуже стандартного. Но называть то, что получилось, "CRC-32", IMHO, нельзя.

З.Ы. Особенно меня прикалывают некоторые статьи из, кажется, не помню, 29A с фразами типа "давайте рассчитаем CRC, для этого просто просуммируем все байты" и т.п.