( egmont | 2010. 01. 17., v – 11:25 )

Legyen N a lehetséges hash értékek száma (tehát például md5 esetén N = 2^128).
Legyen k az adatblokkok száma (több tíz gigabyte osztva kábé 1 megával, az párszor 10000, de te biztosan pontosabb becslést is tudsz készíteni. Az adatok időbeli változását is vedd figyelembe, tehát ha ez naponta vadiúj ekkora adathalmaz, akkor szorozd a napok számával!)

Az első md5 kiszámolásakor az ütközés esélye korábbiakkal 0. A másodiknál 1/N az esély hogy ütközik az előzővel. A harmadiknál 2/N (és itt elkezdünk picit csúsztatni, elhanyagoljuk azt az esetet hogy az első kettő már ütközött), és így tovább, az utolsónál (k-1)/N. Annak az esélye hogy egyáltalán volt ütközés ezek összege (ismét az előző csúsztatás befigyel), vagyis kábé k^2 / (2N). Ez a képlet N-hez képest kis k esetén (tehát a te esetedben, amikor épphogy csak azt akarod leellenőrizni hogy kell-e reálisan félni ütközéstől) tökéletesen jó közelítés.

Mindemellett ne feledd, hogy ez a valószínűséges sztori véletlen adatokra vonatkozik. Slashdot-on pár éve volt cikk arról, hogy sikerült konstruálni két fájlt azonos md5 összggel, ráadásul két érvényes postscript fájl volt egymásnak ellentmondó szerződésszöveggel. Nagyon nem mindegy tehát, hogy adataid véletlenek, vagy támadó által tökéletesen kontrollálhatóak. Utóbbi esetben érdemes utánajárni, hogy melyik algoritmus ellenállóbb, illetve a már létező hash algoritmusokat egy titkos komponenssel megbolondítani, például a checksumolt fájlok elé egy közös kis blokkot odabiggyeszteni, vagy egy másik checksum pár bitjét is hozzáfűzni.