In practice the algorithm described "only" takes 2**69 to produce the same hash instead of (brute-force)2**80. It's still a *long* time for a desktop PC. The problem I see is that if you are using Ant to generate a checksum as part of your ultra-secure-NSA-application, then you really need to consider switcing to a different hash algorithm *now*. Indeed as SHA-1 was so trusted, pretty much everyone uses it, so a lot of things will need to be upgraded (not just for hashes to verify the file contents).
But can the forged file with identical MD5 masquerade as the original file, i.e. still be a Zip file, or tar'd gzipped or bzipped file?
Sure, what you describe sounds bad, but I'm trying to figure out (without too much research of my own ;-) if it's a real problem in practice. --DD
Would it be feasible to publish instead of just the SHA-1 all, the SHA-1, MD5 and the size of the file.
Is Modifying a file while fulfilling all of the following conditions: - the file format valid - the size the same - the SHA-1 the same - the MD5 the same - the working of ant not obviously broken practically possible?
And would it be worth the wile to spend that much effort on forging it on the ant distribution (in the release timeframe?)
I don't think that this is the major problem. It's very very very unlikely that anyone would want to tamper with Ant (why bother, a user can always get teh source and build themselves?). The problem is that when using Ant to build new code (and to generate a checksum for that distribution), now you as the developer of new-shiny-applictaion have to decide whether anyone is going to take the time to create a fake version of your app. If so, use a different checksum technique and don't rely on Ant's checksum task.
At least that's how I see it. www.schneier.com for more details
Kev
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
