mam pytanie dotyczące algorytmu szyfrowania MD5, a nuż ktoś będzie w stanie odpowiedzieć :).
dajmy na to że plik A dzielę na dwie części, A1 i A2. obie z nich hashuję algorytmem MD5, otrzymując hashe odpowiednio h1 i h2. pytanie - czy hash pliku A - h, da się jakoś efektywnie (szybko) obliczyć z posiadanych sum h1 i h2 ?
nie
najprawdopodobniej sądze że nie - jakby się dało to by była jakaś wskazówka co by czyniło IMO md5 algorytmem odwracalnym :P
Powiem nawet, że nie tylko efektywnie, ale w ogóle się tego (na 99%) policzyć. Inaczej MD5 byłby kiepskim algorytmem hashującym. Rzecz w tym, że mogą istnieć dwa różne pliki, kóre po podzieleniu przez przypadek dadzą takie same wyniki "częściowe", zaś każdy z nich może mieć inną sumę MD5. Chcesz przykład? OK, daj mi jakiś milion lat i dobrego kompa, może znajdzie :D
też mi się tak wydaje...
aczkolwiek to:
Adam.Pilorz napisał(a)
Rzecz w tym, że mogą istnieć dwa różne pliki, kóre po podzieleniu przez przypadek dadzą takie same wyniki "częściowe"
jest bez sensu :) IMO, bo wychodzimy z założenia że hashe się nie powtarzają, są unikatowe. unikatowy dla pierwszej części, unikatowy dla drugiej, tak samo dla całości.
zrobiłem test, dokładnie po połowie pliku, hehe może ktoś doszuka się zależności :P
hA1 D7042BA3E28DC7A4442A5694DC9955DC
hA2 C111D1E48BE8AA2D4B4A9364C38D138F
hA E3EF74165BA2075C8A4AF7D0CD778ACD
snw napisał(a)
jest bez sensu :) IMO, bo wychodzimy z założenia że hashe się nie powtarzają, są unikatowe.
Ludzie... następny :/
Pisałem już to w wątku o SHA-1 ale powtórzę:
Skoro hashujesz np. 1MB a wynikiem są 32 bajty, to oczywiste, że będzie wiele różnych danych wejściowych tworzących taki sam rezultat
A nie lepiej zastosowac sume kontrolna crc32?
a czemu ? czy cokolwiek by to zmieniło ? oczywiście poza samym algorytmem. zresztą, pomysł przy którym chciałem to wykorzystać, upadł ;) bo części A1, i A2 w moim przypadku są tak skrajnie różne rozmiarowo że bardziej już opłaca się obliczyć sumę dla całego pliku niż kombinować (nawet gdyby było to możliwe) z sumami częściowymi.