Collision attacks on digital signatures After reading this document about MD5 collision attacks, I still don't understand how collisions can make digital signatures insecure. In the paper, the researchers created two files with the same hash, one innocent and one malicious. The malicious party first sends the good file, gets it signed, and then copies the signature to the bad file to be used against the victim. My question is this: since it is impossible to create a collision without a giant jumbled mess somewhere in the file (though not necessarily immediately visible to the user, for example if preceded and followed by """ in a Python file), why can't users simply ensure that files don't contain blocks of seemingly random bytes if they're digitally signed? For example, why can't SSL certificates hash with MD5 and then use client-side code to verify they don't have any weird strings in them?
Manual detection of such blobs of random bytes is rather easy to circumvent, as soon as the file is either too long or non-human-readable. So for something like this to work, you would need to automate the process.

The problem is, that it's really hard to find a valid ruleset on what is a blob of random bytes and what is valid data.

An automatic detection algorithm would have to understand all file formats that should be checked. So lets say, that program could detect a Python triple-quoted comment. Now you let it check a Java file. Java does not do triple-quoted comments, but instead uses /* do denote multiline comments. So your checker does not understand that. Or you could let it check a JPEG-file, which just looks like random bytes, if your checker does not understand JPEG.

Also, triple-quoted strings with random bytes often serve a real purpose, e.g. if you have a look at get-pip.py, it has a blob of Base64-encoded binary at the end, which contains a full installation of pip. Or any RSA-keys, they also look like random bytes and it would be really easy to put something into these fields, that causes an MD5 collision.