may not be as bad as it appears

may not be as bad as it appears

Don't count on it.

While you may be write, and it's obvious that *most* checksum collisions would be obvious and visible (for text files) and non-functional (for executables) you're not accounting for the number of ways in which MD5 and other checksums are embedded into automated processes and protocols.

Nothing is "obviously wrong" to other software; that's a human value judgement.

Also it may be that someone might be able to pad out a file with non-obvious text or no-op code while generating a deliberate hash collision. For example one might append spaces and tabs to the ends of the(compromised/forged) document or the end of each line.

We can intuit that double checksums would make the attacker's job more difficult (using MD5 *and* SHA-1). But this intuition could be flawed and would require some qualified research to assess before it could be recommended for real business use.

I would say that the current weaknesses (theoretical and practical) are still overshadowed by more pragmatic concerns.

Most of us should continue to focus on key/signature management issues (how do we verify any given checksum, how to we verify the provenance of the checksumming utility) and social issues (did the user who generated the checksum use a compromised copy of the tool).

Meanwhile there are still niches for researchers to continue developing more secure (collision resistant) hashes and for them to continue trying to break the existing and newly proposed algorithms, and for them to quantify the security/weakness of existing, proposed, and combinations of hashes.

JimD