MD5 To Be Considered Harmful Someday

Effugas writes "I've completed an applied security analysis (pdf) of MD5 given Xiaoyun Wang et al's collision attack (covered here and here). From an applied perspective, the attack itself is pretty limited -- essentially, we can create 'doppelganger' blocks (my term) anywhere inside a file that may be swapped out, one for another, without altering the final MD5 hash. This lets us create any number of binary-inequal files with the same md5sum. But MD5 uses an appendable cascade construction -- in other words, if you happen to find yourself with two files that MD5 to the same hash, an arbitrary payload can be applied to both files and they'll still have the same hash. Wang released the two files needed (but not the collision finder itself). A tool, Stripwire, demonstrates the use of colliding datasets to create two executable packages with wildly different behavior but the same MD5 hash. The faults discovered are problematic but not yet fatal; developers (particularly of P2P software) who claim they'd like advance notice that their systems will fail should take note."

damn

I guess I know what I'll be coding now - SHA-1 just got a lot more important in my priority list... :(

Re:damn

Another option is to hash against two very different algorithms, that even if both are partially insecure, the chances of being able to trick both are exponentially higher.
-nB

Re:damn

You're using a different definition of a secure hash than everybody else. It's rather obvious that for files larger than the length of the hash (128 bit for md5), there must be quite a lot sharing the same hash, for a given file length about 2^(filelength in bits - hashlength in bits). However for a hash to be considered secure, it's only required that finding two files with the same hash must be as hard as trying (in md5's case 2^127 different files), but in md5's case you can compute those collisions much cheaper under certain circumstances.

Another condition is obviously that the message should not be reconstructable from the hash.

Almost forgot

Whirlpool is a 256-bit hashing algorithm, derived from the Rijndael encryption algorithm. Rijndael is known to be strong, and has been approved by NIST, but the conversion to a hash function has not been sufficiently tested.

Where time isn't critical (eg: creating and validating checksums for files), I'd say use both. The overhead isn't great, and you'd get much more security.

Where time is critical AND you don't have to be concerned with computers not under your control, use Whirlpool. Rijndael is fast, SHA-1 is slow. Whirlpool also offers a longer hash string than SHA-1.

In any other situation, use SHA-1. Whirlpool might turn out to be the greatest algorithm out there, but that doesn't help if you're trying to talk to a remote computer that doesn't support it.

Re:damn

There will ALWAYS be collisions with any kind of hashing algorythm.

Yes, but a good hash makes it *extremely* difficult to find them. MD5 is looking pretty mediocre right now.

Two files with the same md5 hash?

I can only hope I live that long.

Re:Two files with the same md5 hash?

See you in the next life. [tcs.hut.fi]

MP5 harmful? No way!

Aha! So it was MD5 and not MP5 [scottsdalegunclub.com]...

Exploit?

So does this mean that it's possible to find a useful MD5-equivalent file for any file? Just because someone alters a file does not mean they have done anything destructive. Would one be able to take a binary, make a change of some sort, and then run a tool to determine the block of data to add to the binary to both allow the change to take effect and cancel out the MD5 change? How complex would it be to construct this tool?

Re:Exploit?

It doesn't have to be harmful to break a ptp system. There's a pretty common exploit on Kazaa where people have a file just containing random junk that registers as a match to a popular file. If you download taht file, and get any portion of it from the fake, the file is corrupted and useless. Somebody could use these fake files to "poison" popular torrents, making it very unlikely that anybody on them will get uncorrupted files.

Re: Exploit?

Somebody could use these fake files to "poison" popular torrents, making it very unlikely that anybody on them will get uncorrupted files.

This would worry me, except that BT uses SHA1, not MD5, so this is irrelevant. MD5 has seemed suspect for years, & Bram's the sort to pay attention to that sort of thing.

I checked; Edonkey is based on MD4. Gnutella variants might use MD5.

Re:Exploit?

Yep, you are still wrong. I've tried some code and the (precalculated) different blocks MUST be at the start of the code. So it's more like

file1: xxxxccccccc....
file2: yyyyccccccc....

%file1 = %file2

Which is the example given in the article.

However, Wang said she could get to a collision from any intermediate hash code within the hour (according to the article). That would mean:

file1: ccccxxxxccccccccc......
file2: ccccyyyyccccccccc......

%file1 = %file2

Where xxxx and yyyy are (pre?)calculated and cccc.... is the payload.

If _I_ am not mistaken.

In english

Is there a translator from ultra-nerd to english?

Re:In english

Short version: A common technology for verifying that a file you've downloaded is legitimate and untampered-with, known as MD5, isn't as secure as people thought.

Slightly longer version: MD5 is a way of generating a checksum -- a single, comparable value -- from a file. Ideally it is supposed to give you different numbers for different files, so if a web site advertises the checksum a file should have, you can compare that with one generated from the file you actually got to see whether the file you've downloaded has been modified, potentially maliciously.

The research shows that it is possible for someone to construct a drop-in replacement for the file you thought you had that generates the same MD5 checksum as the original, so anyone attempting to validate the file this way would think they had the real thing. If it turns out that you can construct a damaging replacement for a common file -- perhaps an installer for a popular application like Firefox or OpenOffice that's usually downloaded from a public server -- then this could open a loophole for viruses, worms, etc. that would slip through the security net often used by cautious people when downloading such programs.

What does this mean

Does this mean that I can take a given binary file, like kde.rpm, and change it so that its' contents are different, and harmful, yet the MD5 hash is the same? This has never been done before? Sounds like an interesting 4th-year engineering project to me. I'd think it'd be really easy to mess up a file and keep the same MD5 hash (like screwing up an avi file shared ona p2p network). But to actually change the file so that it behaves a certain way, wow.

Good analysis

By examining the MD5 hash using a sophisticated Fourier schema followed by deconvolution with a bit binary-inequal collision analysis, it is quite obvious I have no freaking clue what this stuff is about.

I am glad somebody does.

Re:Good analysis

Hibbert: Homer, I'm afraid you'll have to undergo a coronary bypass operation.
Homer: Say it in English, Doc.
Hibbert: You're going to need open heart surgery.
Homer: Spare me your medical mumbo jumbo.
Hibbert: We're going to cut you open and tinker with your ticker.
Homer: Could you dumb it down a shade?

http://www.tvtome.com/tvtome/servlet/GuidePageServ let/showid-146/epid-1355/ [tvtome.com]

Let's face it

Someone with the knowledge and will and time can come up with a way to circumvent almost any protective scheme they come up with. Likely the only way to really safeguard something like this is to do a very time consuming and cpu intensive comparison of the two files. It will come back to "do you trust the source of the file".

Cryptographic stacking potentially harmful

Let's say you break a file into blocks, encrypt those blocks with Rijndael or Serpent using a chaining method that authenticates the prior block, digitally sign the result using (seperately generated) RSA, DSA and ECC signatures in turn, and generate SHA-1 and Whirlpool checksums of both the encrypted and unencrypted file. True, you'd spend longer validating and decrypting the unholy mess generated than you'd spend downloading it, but I think you'd be fairly safe in assuming that the file was what it claimed to be.

Maybe, maybe not. The new technique would certainly be more difficult to analyse mathematically, but just stacking complicated but flawed methods does not necessarily result in a more secure method: typically, the security of the weakest link determines the security of the whole system.

What you say reminds me of Don Knuth's experience when he wrote his first innocent 'super' pseudo random number generator (reported in his Art of Computer Programming, Volume 2, page 4: "Algorithm K" ;-): he composed all sorts of complicated operations, but had to learn the resulting number sequence was far from more (pseudo-)random, in fact much worse than the the standard 1-line modulo function.

Another case of (false sense of) security through obscurity?

--
Try Nuggets [mynuggets.net], our SMS search engine which uses question answering technology; now available across the UK.

md5 vs sha1 vs ?

http://en.wikipedia.org/wiki/Md5

here is a very good link about the algo... :)

This is almost appropriate...

If your cursor finds a menu item followed by a dash,
And your double-clicking icon puts your window in the trash,
And your data is corrupted 'cause the index doesn't hash,
Then your situation's hopeless and your system's gonna crash!

Correct me if I'm wrong, but...

If I'm translating this properly, a malicious person can do two things with this knowledge:

He can create a file that MD5sum's to the same result as a legitimate file, but does not have full control over the content or size of the result (making this a mostly useless avenue of exploitation except for people who want to spread trash on P2P networks -- I.E. it shouldn't particularly bother anyone except people who already don't care about security).

Or he can create two files that MD5sum to the same result. But he has to have control over both files, which offers effectively no advantage to someone who is trying to spread malware or tamper with existing archives that have been MD5summed.

Consequently, while this is of academic interest I don't see what the big deal is; any time you reduce a large file to a fingerprint you will inevitably run into problems like this because it is impossible to represent one-to-one every individual possible combination of a large set of data in smaller sets ("fingerprints"). You can reduce the risk by increasing the set domain with a larger variadic function but it is impossible to escape this constraint without using fingerprints as large as the data itself.

Re:Correct me if I'm wrong, but...

The Wang et al attack does not apply to passwords. Their attack applied to situations where the md5 input plaintext was known. Collisions are nowhere near common enough when using less than 16 character inputs to md5 to provide a feasible means of cracking passwords. Nobody has ever found a collision with under 128 bits of input, and the attacks in the article take considerably more than that.

Re:Correct me if I'm wrong, but...

When you're dealing with cryptography, it should be very, very, very hard to find collisions. If you find enough of them, you can proabably find something bad with the same hash value. For example, if you sign a digital document that says you're going to pay me $1 for my pencil, and I find a suitable hash collision, I could make it look like you signed a promise to pay me $3,000 for some used tissue. I wouldn't rule out that someone could find a harmful collision for a program distributed online, and substitute a trojan. If the prize gives enough reward, people will throw a lot of computational power at it, and will likely hit pay dirt.

Secondly, this is quite a signifigant break. Once a hash function has had an attack like this discovered, it often becomes completely useless not long down the road. I work in cryptography, and the people I know have written off MD5. Heck, the people I know are also quite worried about SHA-1, and the current best attack against that one isn't nearly as strong.

The upshot of this is that this hash function should NOT be considered secure any more. For now, if you are not protecting anything of high value, you're probably fine. Tomorrow? Possbily. But soon, you're not going to be protected at all, and so you should start worrying about that now, instead of when you're already in trouble.

Lea

You're wrong.

He can create a file that MD5sum's to the same result as a legitimate file, but does not have full control over the content or size of the result (making this a mostly useless avenue of exploitation except for people who want to spread trash on P2P networks -- I.E. it shouldn't particularly bother anyone except people who already don't care about security).

Suppose you're storing passwords as encrypted hashes, so that intercepting the hashes doesn't tell you what the password is. But if you can generate a password to match that MD5...

You know that GPG keys are identified and signed by their MD5 hashes? Suppose that I can generate a GPG key that would be identified as yours, and distributed it.

Or he can create two files that MD5sum to the same result. But he has to have control over both files, which offers effectively no advantage to someone who is trying to spread malware or tamper with existing archives that have been MD5summed.

There's a coin-flipping protocol that goes as follows. Suppose that Alice and Bob want to flip a coin (over the Internet), but they don't trust each other.

1. Alice generates a file with random data.
2. Alice sends Bob the MD5 hash of the file.
3. Bob picks a bit in the file, and whether he thinks it's a 0 or a 1.
4. Bob wins if and only if he picked right.
5. To verify, Alice sends Bob the file she generated at the beginning.

Now, suppose that Alice generated multiple files in step 1. When Bob makes his guess, she tries to pick a file that will make her win. If she generated only two files, completely randomly, this would let Alice win 75% of the time.

These are just the first ideas I thought of. If I were looking for other problems, I'd think about undeniable signatures [rsasecurity.com], keysigning (which as GPG and X.509 SSL are heavily based on) and other specialized signature systems. In particular, I expect that the first type of crack could cause issues with SSH keys, both user keys (used for authentication) and host keys (to prevent man-in-the-middle attacks).

Digital signatures are used for much more than just testing for file tampering.

I have a novel solution

Buy it instead.

I'm kidding. I download Linux distro's via bittorrent all the time and willfully ignore the MD5 sum, and now I come to find that it's compromisable. OH SNAP!

I can envision something being added on to bittorrent to prevent bad blocks being passed around via ... magic. Okay. I can't really envision it, but I'm sure it can be done.

On to the next topic I'm not qualified to comment on...

Not just MD5

Other weaknesses were reported in various other secure digests, including MD4, RIPEMD, HAVAL-128, SHA-0.

SHA-256 is a good replacement. SHA-1 should be fine but if you are going through the trouble of an upgrade, why not make it sufficiently future proof?

If I Had A Million Terabytes...

If I had a million terabytes of storage, y'know what I'd do?

Two files with the same MD5 hash at once. Aaw yeah.

FYI

The MD5 algorithm is like a hash function and the MD5 sum is the hash key of the data in the file. If the hash key is smaller in size than the data item then collision (i.e. two data items having the same key) is always possible.

The exploit has used the properties of the MD5 algorithm to create two executable files with the same MD5 sum.

The "Detailed Summary"

[This is the author]

I've been doing some analysis on MD5 collision announced by Wang et al. Short version: Yes, Virginia, there is no such thing as a safe hash collision -- at least in a function that's specified to be cryptographically secure. The full details may be acquired at the following link:

http://www.doxpara.com/md5_someday.pdf

A tool, Stripwire, has been assembled to demonstrate some of the attacks described in the paper. It may be acquired at the following address:

http://www.doxpara.com/stripwire-1.1.tar.gz

Incidentally, the expectations management is by no means accidental -- the paper's titled "MD5 To Be Considered Harmful Someday" for a reason. Some people have said there's no applied implications to Joux and Wang's research. They're wrong; arbitrary payloads can be successfully integrated into a hash collision. But the attacks are not wildly practical, and in most cases exposure remains thankfully limited, for now. But the risks are real enough that responsible engineers should take note: This is not merely an academic threat, systems designed with MD5 now need to take far more care than they would if they were employing an unbroken hashing algorithm, and the problems are only going to get worse.

Some highlights from the paper:

* The attack itself is pretty limited -- essentially, we can create "doppelganger" blocks (my term) anywhere inside a file that may be swapped out, one for another, without altering the final MD5 hash. This lets us create any number of binary-inequal files with the same md5sum.

* MD5 uses an appendable cascade construction -- in other words, if you happen to find yourself with two files that MD5 to the same hash, an arbitrary payload can be applied to both files and they'll still have the same hash. This leads to...

* Attacks are possible using only the proof of concept test vectors released by Wang -- the actual attack is not necessary.

* Stripwire emits two binary packages. They both contain an arbitrary payload, but the payload is encrypted with AES. Only one of the packages ("Fire") is decryptable and thus dangerous; the other ("Ice") shields its data behind AES. Both files share the same MD5 hash.

* Digital Signature systems are vulnerable, as they almost always sign a hashed representation of data rather than the data itself.

* This is an excellent vector for malicious developers to get unsafe code past a group of auditors, perhaps to acquire a required third party signature. Alternatively, build tools themselves could be compromised to embed safe versions of dangerous payloads in each build. At some later point, the embedded payload could be safely "activated", without the MD5 changing. This has implications for Tripwire, DRM, and several package management architectures.

* HMAC's invulnerability has been slightly overstated. It's definitely possible, given the key, to create two datasets with the same HMAC. Attacker possession of the key violates MAC presumptions, so the impact of this is particularly questionable.

* Very interesting possibilities open up once the full attack is made available -- among other things, we can create self-decrypting executables (fire.exe and ice.exe) that exhibit differential behavior based on their internal colliding payloads. They'll still have the same MD5 hash.

* Several doppelgangers may (relatively quickly, as per Joux) be computed within a single multicollision-friendly block. As such, the particular selection of doppelganger sets within a file can itself be made to represent data. It's relatively straightforward to embed a 128 bit signature inside an arbitrary file, in such a way that no matter the value of the signature, a constant MD5 hash is maintained. This is curiously steganographic.

* Many popular P2P networks (and innumerable distributed content databases) use MD5 hashes as both a reliable search handle and a mechanism to ensure file integrity. This makes them blind to any sign

Cash Money?

Was there a cash money prize for someone who could produce a pair of strings with the same MD5 sum? I remember reading or possibly hearing that No One had Ever discovered a hash collision with MD5. Is this the first ever hash collision found?

--grendel drago

I studied different hashes..

I found out the darker and moister it was, the more powerful it was. Of course any form of hash was much stronger then regular leaf pot and you could get far more reusable resin when you were done with the pipe.

______ with be harmful/obsolete in the future..

Really no big surprise, all currently implemented algorithms for security and digital signatures will be rendered useless or easily hackable in the future. The fact that a compromise seems to be soon is the part thats interesting.. however the parent fails to address how serious it is.

For the most part, big deal, all of current security procedures will be harmful ie compromised in the future...

Solution: Use more than one hash algorithm

This kind of attack can be mitigated into non-existance by just using two dissimilar hash algorithms.

Using MD5 with SHA1, or even the older MD2 or MD4 will reduce the probability of creating a compatable binary with the same checksum to virtually zero.

If only one checksum is required then just XOR the resulting checksums from each algorithm.

birthday attack

Can someone explain to me how this is something more complicated than the birthday paradox?

(heh, Wang)

Switching to SHA1

I've made the switch to SHA1 for all my website work where I'm storing passwords and session IDs and the like. It's just a simple change from 32 to 40 characters, and a search/replace for:
md5_hex to sha1_hex

It actually easy to see this

I was a bit suprised recently when I tried to
sort 15,000 jpg image files to remove duplicates.
Since the names varied, and it is not uncommon
to have many images with the same length, it
seemed like a good idea to use md5 hashes.
So I coded it up in python to do the md5 hash,
and then stuffed the file name into a table
keyed by the md5 hash. Big suprise when multiple
different files landed in the same hash.
Some property of jpgs probably reduces the
randomness of the files and increases the
probability of hash collisions.

Time is of the essence

It's all about the famous IMPS (Infinite Monkey Protocol Suite, RFC2795), if you give the CPU enough data, and enough time, it will eventually crack what ever encryption you are using. To be safe, deploy a stegography technique to hide your data, such as in the meta field of a picture, or within some MIME data on a harmless looking email, but be clever about it (theres a lot of junk in harmless looking SWAP file).

Inherent to any hashing mechanism

Of course. I've run into this type of thing with all sorts of data hash/checksum type of algorithms. If there are a numerically smaller amount of hash values than source data values, it is a mathematical certainty that multiple source data from generating the same hash value.

If you have a 4-byte hash value of a 1000-byte character string, you have 4+ billion possible hash values. But the number of possible 1000-byte strings? What's 256^1000? So, on average, there would be 256^4 / 256^1000 source values that would generate each individual hash value. The only way to avoid this is to have a hash value that is as long as the source value, which eliminates much of the benefits of a hash.

I like the idea someone else posted about using multiple algorithms because it would dramatically reduce the number of possible values that would generate the same hash value using 2 different methods.

hash, equals

Testing the equality of hash codes is not a replacement for testing equality. It should be used as an optimization to limit the set of items for which equals need be applied. e.g.

Thing search(Thing thingToFind) {
thingList = hashSearch(hash(thingToFind));
for each thing in thingList
if (thing == myThing) // IMPORTANT!
return thing;
return null;
}

MD5 To Be Considered Harmful Someday

Think of the children! We cannot allow some MD5 to put our children in the harm's way! Initiate operation AntiMD5, deploy the bombers.

Maybe start consider adopting magnet links

Magnet links [sourceforge.net] is an open standard (specification draft [sourceforge.net]) and an alternative to primarly eDonkey2000, eMule, and Overnet hashes that are based on a precursor to the MD5 algorithm, and I doubt very safe anymore?

I personally think any clients that don't support magnet links should really start consider adopting those -- DC++, most Gnutella clients, and Shareaza already do.

A magnet link can look like something like this:

magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO 5C

... see "sha1" above -- the standard doesn't define which hash algorithm to use.

what about stuff that's harmful NOW?

Like, say, Windows?

Yeah, yeah, Obligatory Microsoft Slam. But I don't see any great stampede to isolate and neutralize the threat that this Typhoid Mary of OS's presents to communication stability. Why are we preparing for a threat that barely exists, when we refuse to deal with the present, much greater threat?

Is a two-pass just as vulnerable?

I haven't had time to think this out, so I'm throwing it out for you guys:

Is doing a 2nd pass helpful?

In other words, if
ABCfireDEF
and
ABCiceeDEF
hash the same, does
ABCfireDEFABCfireDEF
necessarily, or even frequently, hash to
ABCiceeABCiceeDEF?

Even if it were to provide protection, in practical terms,
1) other hashing althorithms are likely faster than "MD5 times two"
2) there may be some - hopefully a lot fewer - places in a long file where where
ABCfireDEFABCfireDEF
can be replaced with
ABCiceeDEFABCmeltDEF

I'm beginning to like the "pick two algorithms and call me in the morning" approach.

My humble proposal for a solution.

MD5 every single byte (or better yet every bit) in the file and put the result alongside the original file. Voila! No smartypants would ever attempt to temper with that, bwahahahahah!

Dijkstra Considered Dead

really. and it's about time this stupid meme died. it's all too easy to toss it about for dramatic effect when attention whoring.

You are missing the point.

The real threat for it is for the p2p network. not because you will download a different version of the file, but the file is broken in various pieces. Imagine somebody released, dunno, some linux distro, over bittorrent. you will download the real file, and the fake one at the same time, leaving the final file useless, and probably ruining the release.
I could see game and movie companies releasing bogus versions of their pirated apps to break the releases. after all, you cant de-compress corrupt zips, rars and etc. the musics would have cracks and noises because of the bogus versions. P2P as it is now would be ruined

Jesus, I hope I'm wrong... I would have to acctualy buy MS crap.

Re:You are missing the point.

Jesus, I hope I'm wrong... I would have to acctualy buy MS crap.

Your statement is ironic in the extreme. The big risk here is NOT P2P apps. Here's the real risk.

Using one of these collision generators, I can create two x.509 certificate requests which have the same MD5 hash. One request says, "I am John Smith, kshdfkhs8i76y238888888" and the other request says, "I am Microsoft Corp., oiushir87dsfhgkjshdfg"

Now, I get Verisign to issue me a certificate for the first request. Since the hash is the same, I can rewrite the certificate to say that I am Microsoft Corp, and nobody will ever be able to tell the difference. Now, I am able to sign code as if I were Microsoft, and Dominate The Earth.

Time to move on

Time to move on. And, while we're at it, let's skip SHA1 etc. as well and go directly to SHA512. That should last for a while.

Everything is considered harmful eventually

Eggs, .NET, Apple, whatever.. it's basically ripe to become another in-joke here at Slashdot. In Korea, only old people are considered harmful someday.

what kind of language is this?

"..to be considered harmful someday"? I mean, gimme a break, dude, if you think its harmful just write "MD5 is harmful", but "to be considered...someday"?

The biggest problem is still human falibility

Be honest. How many of you have checked the MD5 sums on a file with a TRUSTED source, as opposed to from the same source you got the file? How many of you do this regularly?

THAT is the biggest problem with MD5 for most users.

what's next....

okay, so if MD5 has issues that can now be explioted, or at least tampered with, is it time for a new checksum? being clueless in this respect can we call it MD6?

Asymetric Key Encryption

MD5 isn't the right way to detect tampering.

Asymetric key encryption is. You have a trusted authority issue a key, and sign it. You can verify the key file hasn't been tampered with, and they can revoke the certificate. It's harder to fake, even if they can spoof a MD5, because you can connect out to the certificate authority and ask if the certificate is valid, and they can revoke them if there's problem.

If you're downloading a package, presumably you're wanting to know that it's the right package, and that it's from whomever it says its from. An MD5 hash does not get you that capability, asymetric encryption does.

Only someone who knows your distribution's private key can produce your distribution's packages. The public key is verified by a neutral 3rd party that can revoke accidents or hackers once they're discovered.

So you know both that the distribution wasn't tampered with (because it decrypts) and that the distribution is from who they say it is from (because it decrypts), and you have a neutral 3rd party vouching for the facts who has a vested interest in retaining business by not letting people fake other people's signatures.

Double Hashes?

From what I read, creating a hash-equivalent file for one hashing mechanism requires different and incompatible changes to those required for making a hash-equivalent file for a second hashing mechanism.

Would it therefore be safe to calculate two hashes (MD5 and SHA-1) for the file, distribute the file and the two (or three, or four) separate hashes, and use the incompatible nature of the hashes as an extra "guarantee" of data integrity?

A: MD5 of an empty string

I'll take Secure Hasing Trivia for $500, Alex.

Q: What is d41d8cd98f00b204e9800998ecf8427e ?

MD6

That's OK..just invent MD6!

What's the big deal?

I don't see the big deal. What happened to CRC?

All that means is that we will move to another digest algorithm when this one will become too easy to tamper with. A lot of people already provide sha-1 or a signiture of the files they provide. And that will be our solution until it fails. Just like cryptography.

Strong -> stong -> weaker -> weak -> time to move on

What about SHA-1?

Does this have implications for SHA-1, or is it still secure?

Two hashes

I'm guessing using two different hashing methods and putting both checksums up would make it harder to use exploits like this.

old news

MPAA-hired thugs spamming the P2P networks with utter crap have been doing stuff like this for a long time

Someday? maybe not in your life time.

If you read the original paper, you'll find that it's simply not true that you could easily find a collision to a given hash. Wang et al's contribution is a more efficient algorithm than the canonical birthday attack to find random collisions in a family of hash functions (SHA-* and MD5 are the same family), while this guy's contribution seems to be only confusion. For the attack to be useful, you'll need to find a easy way to create hash collision to a given file.

28bc8c78881b2f89bbeab4f9bb8fbeda is the md5 of "clue", I can bet my hash farm and a hash laced brownie that you'll never find anything other than "clue" that hashes to the same md5, at least not "someday" in your life time.

Re:Already Happening

Bullshit.

I'll give you $50 if you can back that claim up. I want to see two video files. They must start out the same, but have a difference about half-way through. And they have to have the same md5 sum. Just post where I can download the two files, and your paypal address.

The way I see it, you've got a 1/2^64 chance of being right. So I'm risking $50/184467440737095516, which isn't a whole lot.

Re:Already Happening

I bet a lot of their subscribers were upset when they didn't get to see the money shot. ;)

Re:MD5 is obviously less secure

While this is technically true (there are an infinite number of passwords that hash to the same value), it's not of much practical use. There are only 256^8 possible 8-character passwords (less, if you don't allow un-typeable characters). There are 2^128 possible MD5 hashes. 256^8 is much, much, MUCH less than 2^128, thus the probability of discovering another valid passwords of 8 characters or less is negligible.

Sure, there are an infinite number of possible passwords, but they're all impossibly huge. I can come up with a password which is one trillion characters long and which hashes to the right result, but that's not practical.

Re:Already Happening

Maybe you used a (slightly) different decoder. I've seen this happening after switching between (different versions) of decoders. I'll bet another 50 if you can back up your claims, no problem. Unless Wang is working for your competitor.

Re:Already Happening

Sounds like a bug in your system. Nothing works until it's been tested.

Re:MD5 is obviously less secure

What is this, some kind of techno-troll? What you've said is true, but like the other replies have implied, it's basically inconsequential.

Re:Already Happening

I know exactly what you mean! One of my "friends" also has a large collection of mpeg movies and halfway through he will pretty much always loose his.... I mean... Stop watching at least. Although in most cases that actually happens way before the half-movie mark.