Użytkownik "Luke" <l...@l...net> napisał w wiadomości
news:586e5454$0$15197$65785112@news.neostrada.pl...
>
>> j.w.
>> Więc chyba jednak lepiej mieć jeszcze coś w zanadrzu...?
>>
>
> Przecież to wynika z samej definicji hasha. Skoro ma on ileś bitów, to
> istnieje w teorii nieskończenie wiele dłuższych porcji danych, które
> zhashują się do takich bitów.

Otóż to. Ryzyko jest niezerowe... po prostu nie zerowe, a jedynie
przyzerowe.

>
> Tyle, że jest to teoria. A w praktyce, w zanadrzu można mieć nawet
> kilkanaście hashy (zwłaszcza tych wedle różnych teorii "kryprograficznie
> silniejszych" niż MD5) i obliczyć nawet je wszystkie. Nigdy nie zawadzi.

Nie inaczej. Dodatkowo pomyślałem sobie, że coś może dać próba spakowania do
archiwum, ZIP, RAR, czy czego tam i może tu wyjdzie inny hash? Może spróbuję
w wolnym czasie, ciekawi mnie, jak mocno będą się różnić hashe 2 różnych
plików, dających nieskompresowane taką samą sumę kontrolną/hash, które to
pliki zostaną spakowane i wtedy zdjęte "znaczniki"...?
Przy okazji tak sobie pomyślałem, choć już nawet całkiem dawno, że chcąc
znaleźć dublety wśród kilkudziesięciu tysięcy (zdarzyło się...) plików...
m.in. wykonujemy porównywanie zawartości. Bardzo IMHO nieekonomiczne -
należało by raczej zdjąć hash każdego pliku (przecież i tak wszystkie są w
całości czytane) i do porównania dać tylko te, których hashe są identyczne,
diametralnie skrócimy czas operacji. Bo chyba tylko zgodność "pobajtowa" da
pewność, że zawartość jest identyczna... więc ergo - zawsze gdzieś będzie
słaby punkt, pięta achillesowa. Mylę się?

--
...Ja biorę na siebie schody, znajdę je skubane i skopię im poręcz
tak, że nie będą wiedziały, którędy na górę. (C) Osioł ze Shreka.