Comment Re:MD5 Cannot stand up in court. (Score 1) 779
Actually you would expect to on average test 1/2 of the keyspace to find a match - since the space is 128 bits, or 2^128 combinations, half of it is 2^127 (or 1.7 * 10^38). That's a lot longer than a few years even if you do parallellize it.
Added to that, each attempt is more expensive computationally (you are trying to create a several mb file that has an md5 collision and hash it) than something simple like RC4/RC5.
IIRC, MD5 takes about 80 cycles for every 64 bytes - that's about 5 million cycles per mp3 to be conservative, never mind generating a file. So expected time for a match would be 1.7 * 10^38 * 5 * 10^6 CPU cycles = 8.5 * 10^44 cycles.
Assume a 1ghz cpu that has a single ALU with ideal pipeline for this and no memory overhead - 10^9 cycles/sec. 3.1*10^7 seconds/year. So 2.7*10^37 CPU years.
In other words, a very conservative estimate of a billion PCs taking 10^28 (ten billion billion billion) years to find an mp3 file whose MD5 hash collides with another. If you have a set of N files and you are looking for a collision with just one, divide above number by N.
Added to that, each attempt is more expensive computationally (you are trying to create a several mb file that has an md5 collision and hash it) than something simple like RC4/RC5.
IIRC, MD5 takes about 80 cycles for every 64 bytes - that's about 5 million cycles per mp3 to be conservative, never mind generating a file. So expected time for a match would be 1.7 * 10^38 * 5 * 10^6 CPU cycles = 8.5 * 10^44 cycles.
Assume a 1ghz cpu that has a single ALU with ideal pipeline for this and no memory overhead - 10^9 cycles/sec. 3.1*10^7 seconds/year. So 2.7*10^37 CPU years.
In other words, a very conservative estimate of a billion PCs taking 10^28 (ten billion billion billion) years to find an mp3 file whose MD5 hash collides with another. If you have a set of N files and you are looking for a collision with just one, divide above number by N.
