>David Wagner wrote: >> Ben Laurie writes: > > >> Or, even more contrived, imagine that img1.jpg looks >> like a completely normal JPG file, but img2.jpg exploits some buffer >> overrun in the startup screen's JPG decoder to overwrite the program's >> image with some other malicious code. >> >> Sure, these scenarios are contrived and unlikely. But how do you >> know that there is not some other (possibly more complex but less >> contrived) scenario that you would consider more troubling? > >They do not relate to the known MD5 collisions - these are general >collisions, which we do not know how to create, not the restricted ones >we do know how to create.
I disagree; I think it might be possible with the current cryptanalysis on MD5. The collisions that can be currently produced only flip a couple of bits, and you can add what you want before and after the 1024-bit block. Imagine some code that reads the image (or whatever bit-string) as a textual string, in one case it doesn't read the whole bit-array because there is a null string-terminating character, in the other case (collision) the character is not present and causes a buffer overflow. I think something like that can be done today. --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
