Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Meaningful MD5 Collisions

Zonk posted more than 9 years ago | from the bam-crash-boom dept.

Security 312

mrogers writes "Researchers at Ruhr-Universität Bochum have found a way to produce MD5 collisions between human-meaningful documents. This could be used to obtain a digital signature on one document and then transfer it to another. The same technique is theoretically applicable to other hash functions based on the Merkle-Damgård structure, such as SHA-1." From the article: "Recently, the world of cryptographic hash functions has turned into a mess. A lot of researchers announced algorithms ("attacks") to find collisions for common hash functions such as MD5 and SHA-1 (see [B+, WFLY, WY, WYY-a, WYY-b]). For cryptographers, these results are exciting - but many so-called 'practitioners' turned them down as 'practically irrelevant'."

cancel ×

312 comments

Sorry! There are no comments related to the filter you selected.

Common sense (2, Insightful)

gtrubetskoy (734033) | more than 9 years ago | (#12783106)


Unless I'm missing something, all these guys are doing is using a format that can contain an infinite amount of extraneous information that has no effect on how it's ultimately rendered, so same thing can be done with a .doc, or an HTML file, and this isn't really a cryptographic discovery of hash function weakness of any kind, just common sense for most of us - the secure hash algorithms should be applied to the English (or whatever language) textual contents of the document, no the source code of it, such as PostScript used in the article, PDF, HTML or whatever. I guess the most important lesson here is that this technique can be applied to binaries pretty easily as well.

no help (2, Insightful)

LiquidCoooled (634315) | more than 9 years ago | (#12783163)

Anything you hash together will ALWAYS result in collisions.

Extracting the formatting and code from the document will just make it EASIER to create a duplication.

"Hello World!" might match with "Hello World!!!!!! this is extra stuff"

at least leaving the exact formatting instructions in gives you a chance that the collision which leaves a compatible file is much more difficult than the hash of the simple raw text.

Re:no help (1)

ergo98 (9391) | more than 9 years ago | (#12783200)

Extracting the formatting and code from the document will just make it EASIER to create a duplication.

From a pure data perspective it makes it no easier or more difficult. However, I think his point was moreso that if one were to hash some text, it would be significantly more difficult to find a collision while maintaining plausible text - e.g. you can just add a comment block and add variable sizes of bytes.

Re:Common sense (2, Informative)

ergo98 (9391) | more than 9 years ago | (#12783177)

and this isn't really a cryptographic discovery of hash function weakness of any kind

It's an example of the hash collision weaknesses recently documented, giving a practical example of how it could be used for malicious purposes.

Traditionally we haven't had to worry about nonsensical things like applying the hash only to easily verifiable English text, because the hash is supposed to practically protect against intentional searches for collisions.

Re:Common sense (1)

3770 (560838) | more than 9 years ago | (#12783195)

They said that they have a method to make it easier to find collissions.

While you are right that you always will have collissions they say that they can find it in a reasonable time.

What is interesting though is that in their example they have control of both documents and they may use that to find a collision.

This means that they may have a harder time to find a collision for an arbitrary document. If that is the case i don't know. I'm just speculating.

Re:Common sense (2, Insightful)

loose_cannon_gamer (857933) | more than 9 years ago | (#12783453)

Your common sense seems a little ridiculous. Are we saying that all documents have to be reduced to text before applying our encryption? What about nontextual documents, like, say, process flowcharts, spreadsheets, powerpoint slides, multimedia?

There are a lot of formats out there that allow additions of random undisplayed information, and so I presume that many of these formats are vulnerable to these attacks.

I wonder how long it will take before there are exploits out there that take advantage of these techniques... Of course, I also wonder how many there already are...

Oh well. The key concept behind security is, has been, and always will be trust. You should always ask yourself when you receive something from someone else how much you trust the source, and act accordingly.

Re:Common sense (1, Insightful)

Anonymous Coward | more than 9 years ago | (#12783579)


Your common sense seems a little ridiculous. Are we saying that all documents have to be reduced to text before applying our encryption? What about nontextual documents, like, say, process flowcharts, spreadsheets, powerpoint slides, multimedia?

What's a little ridiculous is your lack of security knowledge. Yes, signatures MUST be applied to meaningful parts of the document files, and exactly how to do it right varies from format to format - simply running md5sum on a file is rediculously risky!

On the contrary... (5, Insightful)

Chris Pimlott (16212) | more than 9 years ago | (#12783520)

This attack shows us all once again that there is that the procedures for using cryptography are as important as the mathematical theories and proofs on which cryptography is based. People like to believe that it's just the algorithm that's important, and once you have such an algorithm it's equally applicable to messages of all sorts and formats. As this shows, it's clearly not the case.

You may believe it's common sense, but to the average user, encrypting a simple letter like the memos used in the article expressed as a Word document is no different than encrypting a simple text email. Heck, many of these users probably have no idea that much of the plain-looking email they send and recieve is actually HTML, which is capable of hiding beneath its rendered surface all sorts of additional information.

When's the last time you saw an email program that read in a Word document, extracted just the plain text content, signed or encrypted it and then repackaged it into some new format in a cryptographically sound way that would automatically be reconstituted as a Word document on the other side? Most just have a handy "Sign" or "Encrypt" button that will happy accept .ps or .doc just as readily as a simple text file.

If you read the Slides link for the Eurocrypt 2005 (1)

Calyth (168525) | more than 9 years ago | (#12783686)

They did point out that they were exploiting the fact that if the MD5 hashes of X1 and X2 collide, then the MD5 hashes of X1+S (read: X1 concatenated with S) and X2+s also collide.
As much as you didn't like it, Lucks and Daum had just turned that into a possibly-practical hash function weakness. If they can do this with Word...

Speaking of 128 bit collisions (0)

Anonymous Coward | more than 9 years ago | (#12783109)

What happens when databases using GUIDs finally become large enough that GUID collisions are everyday occurances? Will we have to switch to using 256 bit keys?

do you know how big 2^128 is? (4, Insightful)

frovingslosh (582462) | more than 9 years ago | (#12783244)

Collisions are NOT and accidential everyday occurance. What is being discussed here is a deliberate md5 match, created by making just the right changes to a document to intentionally get an md5 match.

2^128 is huge. It's larger by far than the number of all the files in all of the computers in the world. It larger than the number of stars in the universe. Chance collisions will not become an everyday occurance. No accidental collision has ever been found yet. Switching to larger keys will not change anything. Sure, they might make it slightly harder to make a deliberate collision (although I don't know for a fact that they make it harder at all, there were some reports of someone in Japan being able to create a collision by hand with only pencil and paper), but just wait 2 months and the computing power will catch up with that. It's not a matter of the size of the hash function.

Re:do you know how big 2^128 is? (5, Funny)

RealityMogul (663835) | more than 9 years ago | (#12783284)

2^128 is huge. It's larger by far than the number of all the files in all of the computers in the world

Pfft, let me show you my porn collection.

also a matter of algorithm strengh (1)

tota (139982) | more than 9 years ago | (#12783554)

As you rightly pointed out, collisions are a natural phenomenon linked to the limited space of the hash.
What is important -and the reason for moving away from md5 and sha1- is the fact that flaws in these algorithms can be used to derive collisions more easily than it should be possible to.
Problem is that it is extremely hard to prove that an algorithm is strong, it is much easier to disprove: just find an example. Science at its best!

Re:Speaking of 128 bit collisions, UUIDs and GUIDs (1)

dmeranda (120061) | more than 9 years ago | (#12783455)

The GUID (as called by Microsoft) has it's history in the UUID, which was first "invented" by OSF as part of it's big DCE specs (long before Microsoft adopted the format and gave it a spiffy new name).

The UUID and GUID look alike, but the UUID was constructed in a much different manner than GUIDs seem to be nowdays. GUIDs are basically 128-bits of random data (usually made by passing pseudo-random seeds through a hash). UUIDs on the other hand contained structured data too in addition to randomness, to try to prevent accidental reuse. For instance the rightmost 48 bits come from the Ethernet MAC address if available. Other bits contained date/time information, process/thread ids, etc.

There was an expired Draft RFC [ietf.org] written in February 1998 which explained a lot of the technical details of GUIDs and UUIDs (surprisingly authored by Microsoft). You may still be able to find copies of it out on the net (the filename was "draft-leach-uuids-guids-01.txt")

First post (-1, Offtopic)

xintegerx (557455) | more than 9 years ago | (#12783116)

The problem with MD5 is that it is possible that two files will have the same MD5, but highly unlikely. Instead of worrying about this, we should worry about our kids.

Re:First post (1)

rbarreira (836272) | more than 9 years ago | (#12783373)

Well, you're of course a troll, but for people who might not be very informed about this... That unlikely event that you talk about has just been purposely produced. And they could have used any different collision they wanted for this effect, since if you append the same content (ANY content will do) to two files which are an MD5 collision, you end up with... two files which are an MD5 collision.

big oops (0)

Anonymous Coward | more than 9 years ago | (#12783122)

Does this mean that MD5/SHA1 should no longer be used? What about AES's hash's?

Re:big oops (2, Informative)

tota (139982) | more than 9 years ago | (#12783623)

sha-256 and later have not been found to be weak yet. It does not mean that they are unbreakable (or I should say: possible to derive collisions) but it is definitely better.

Another solution that should work quite well is to combine hashes: (md5+sha1) is definitely much stronger as you would need to find a collision that works for both algorithms at the same time.
Possible, but not likely.

Wow...this is nerdy even for /. (1)

William_Lee (834197) | more than 9 years ago | (#12783123)

Anyone want to explain the real world applications of this to someone who is considering turning in his nerd credentials after being unable to get the gist of this from the write up...and please don't tell me to RTFA, this is after all /.!

Re:Wow...this is nerdy even for /. (2, Funny)

k4_pacific (736911) | more than 9 years ago | (#12783168)

Basically, they used a high-powered particle accelerator to create MD5 collisions between human-meaningful documents, thus forging the missing link between thermodynamic and informational entropy.

I hope that clears things up.

Re:Wow...this is nerdy even for /. (2, Informative)

William_Lee (834197) | more than 9 years ago | (#12783181)

Thanks for clearing that up. Now it all makes perfect sense!

Re:Wow...this is nerdy even for /. (4, Informative)

jjares (141954) | more than 9 years ago | (#12783296)

Basically, when you do an md5 for a string, you transform an existing text with a variable length to a fixed length string. Now, imagine the variable text is 200bytes long, but the fixed string is 20 bytes long, you are obiously loosing information, and that there may be a combination of 200 bytes that produce the same 20 byte sequence, but the amount of combinations in 20 bytes (160 bits) make it highly unlikely that you will find a repeated sequence. What this investingators found is a way to replicate this sequences. The problem being that usually we check integrity with this md5 hashes, so teoretically, someone could alter a text and produce a new one that seems (from the md5 hashes) identical to the first one. This is specially nice for putting backdoors in source code downloaded from the net, as we often check it against an md5 hash.

Re:Wow...this is nerdy even for /. (0)

Anonymous Coward | more than 9 years ago | (#12783568)

you are obiously loosing information

you are obviously unaware of the proper use of loose and lose

Re:Wow...this is nerdy even for /. (0)

Anonymous Coward | more than 9 years ago | (#12783315)

The potential is that someone could post a "mirror" of your favorite software, say Win XP SP3 (thinking future), that has the same MD5 hash as the real thing but is in fact a massive virus (or trojan, or some other malware). Of course, for this example, that would be redundant.

Consider it to be an example... (3, Informative)

Otto (17870) | more than 9 years ago | (#12783384)

If you don't know what a hash function is, then turn in your nerd credentials now.

Basically, they provided an example case where one of these recent methods to generate hash function collisions can be turned into a "real world" attack.

It's a very simple example case, but it demonstrates the point effectively. The point is that these recently discovered methods to generate collisions quickly are a real threat to any software using them as a method for digital signatures and such.

The real world application here is that it is possible, probably in several good ways, to generate a couple of different files that have the same hash and also have meaningful data in them. The attacks found that generate seemingly random data with the same hashes can be used in ways that will let them apply to non-random, purposefully designed data.

The example they use is where some secretary gets her boss to sign a document, and then uses his signature on another document which gives her access she shouldn't have. It's a way to forge a digital signature on a document by having them sign another one that you specially crafted.

Re:Wow...this is nerdy even for /. (2, Insightful)

Ann Elk (668880) | more than 9 years ago | (#12783509)

  • Download something critical, say, the current Linux kernel from kernel.org.
  • Insert a trojan/backdoor/whatever.
  • Manipulate the tar archive so the hashes match. This is the subject of TFA.
  • Somehow upload the trojaned kernel back to kernel.org.
  • Since the hashes for the original kernel and the trojaned kernel are identical, they both appear valid when checked against the signature.
  • ????
  • Profit!

Before someone starts bitching about "lack of trust" in open source, please replace kernel with security update and kernel.org with microsoft.com in the above text.

These are important attacks.. (5, Insightful)

Ckwop (707653) | more than 9 years ago | (#12783126)

As an amateur cryptographer, I must say that labeling these attacks as 'practically irrelevant'
is at the very least misguided and at worst a shocking display of incompetence.

Stop the fixation with plain-text messages, most messages are not plain-text. Your average word document
contains loads of invisible data that doesn't get rendered. Pdf's contain "junk" data that doesn't get rendered either. Would
you notice a single bit difference in an MP3? Or a single pixel colour change in a jpeg? Hell, you can even do it in HTML <div style="visibility:hidden">Junk goes here</div>.
Mark my words, people will find in the next couple of months find two meaningful computer
documents that hash to the same value but are different byte-wise.

People undervalue these attacks because the attacker has to generate the collision before hand to use it.
To properly appreciate the power of these attacks consider the following senario.

Imagine we're agreeing a contract of employement and I'm your employer.
I give you the first word document that includes all the standard terms, however, I've also drafted
a Word document that contains a load of draconian clauses like banning you from working in any IT position five years
after leaving the company. By adding junk that doesn't render to both documents, I've managed to find to make the hash
of the two documents collide. Thinking I'm a nice employer, you sign the first document, which you do by signing the hash of
document. However, I now have your signature on BOTH documents. I now make sure the company IT system "forget" the first document
and I've successfully screwed you.

This is a human example, but there are other examples that apply in computer systems. The problem is that in many situations
the attacker can choose when you encrypt. Say you encrypt your e-mail conversation with your friend using S/MIME, many people click
"Reply" and the message body of the other persons method appears in the new message. Because of these attacks,
It's now no certainty that an attacker couldn't use this fact to construct collisions that an attacker could use.

As another security researcher said (paraphrased) It's like you're in building and you've just heard the fire alarm go off.
You can't see smoke but it's time to make your way calmly to the exit. That sums up the position with SHA-1 and MD5. Swap out the primitives
before you start seeing smoke.

It's not like we don't have alternatives anyway. Whirlpool uses the same wide-trail design principles has AES. It's slower than MD-5 or SHA-1 but it's much better designed. And beside, people would do well to realise you have to spend CPU cycles to get security.

Simon.

Re:These are important attacks.. (1)

Reality Master 101 (179095) | more than 9 years ago | (#12783155)

However, I now have your signature on BOTH documents. I now make sure the company IT system "forget" the first document and I've successfully screwed you.

Er, only if you're stupid enough not to keep a copy of a document that you sign.

Re:These are important attacks.. (1)

ryturner (87582) | more than 9 years ago | (#12783404)

So if it goes to court, how do you determine which of the two documents was the one signed by the employee?

Re:These are important attacks.. (0)

Anonymous Coward | more than 9 years ago | (#12783426)

That won't work either since they can accuse you of fabricating your copy of the document.

Re:These are important attacks.. (4, Informative)

deanoaz (843940) | more than 9 years ago | (#12783634)

If two documents exist with the same hash, then they were both produced by the same source, since there is no practical, known way of finding a collision without having control of the content of both documents. Therefore, your signed copy of the original document proves that the employer created both versions.

Re:These are important attacks.. (1)

LiquidCoooled (634315) | more than 9 years ago | (#12783192)

Your right.
How exactly could they create junk documents that also match the expected filesize.

Add in that restriction and md5 could become a difficult problem again :)

Re:These are important attacks.. (1)

compm375 (847701) | more than 9 years ago | (#12783259)

You could also use stronger hashes, or more powerful hashes. All you really need to do is stay ahead of the technology. Just use a hash type that will take at least a certain number of years to crack.

Re:These are important attacks.. (1)

Ckwop (707653) | more than 9 years ago | (#12783276)

There are 2^128 hashes and for a document of one megabyte there are 2^1048576 documents. That means that there are roughly 2^1048576/2^128 = 2^1048448 collisions for documents of the same size.

Factor in the fact that it take 2^64 time to *brute-force* a collision in MD5 and the fact that we now have an attack that can find any collision in minutes on a laptop then I'd say it's pretty reasonable that someone can do it.

Simon.

Re:These are important attacks.. (1)

arkanes (521690) | more than 9 years ago | (#12783432)

You need a document which is either exactly the same size (if there's size checks built into verification), or close enough in size that it won't raise suspicion. Incidently, this is a major weakness in crappy bloated formats like .doc and .pdf, where people don't blink twice about a 2 page text document being 4 megs in size.

Given that restriction, you then need to be able to generate a collision. And not just any collision, but a *specific* collision that has your malware or subtle contract alterations or whatever in it. Hashing is used as verification, so simple corruption is useless.

The flaws being found are not totally irrelevent, by any means, but they're theoretical mathematical attacks on hashing. The practical security of hashing as verification is not especially weakend.

Re:These are important attacks.. (1)

MBGMorden (803437) | more than 9 years ago | (#12783587)

Simple solution would be to use multiple hashing algorithms. You'll have to bust your butt trying to create a meaningful document with the same MD5 hash as the original, but if we check with two alorithms, say MD5 & SHA-1, then it's going to be damn hard (I'd almost say impossible, but I'll not go that far without a mathematical proof) to get anything meaningful that produces the same MD5 hash AND the same SHA-1 hash as the original does.

Re:These are important attacks.. (2, Informative)

cpeikert (9457) | more than 9 years ago | (#12783611)

How exactly could they create junk documents that also match the expected filesize.

The collisions that have been found for MD5 are for pairs of documents that are the same size. The size constraint is not a problem.

Re:These are important attacks.. (1)

swillden (191260) | more than 9 years ago | (#12783301)

Your average word document contains loads of invisible data that doesn't get rendered. Pdf's contain "junk" data that doesn't get rendered either. Would you notice a single bit difference in an MP3? Or a single pixel colour change in a jpeg? Hell, you can even do it in HTML.

I think that's insufficient to be able to mount the attack.

To do what these guys did, you need a format that can:

  • Contain "junk" data that is never displayed.
  • Contain two different "messages" only one of which will be displayed.
  • Be able to select which message to display based on the result of a calculation involving the junk.

MP3s don't meet these criteria, nor do JPEG images. HTML files do, if you allow for Javascript or the like. I think "plain" HTML is inadequate.

Say you encrypt your e-mail conversation with your friend using S/MIME, many people click "Reply" and the message body of the other persons method appears in the new message. Because of these attacks, It's now no certainty that an attacker couldn't use this fact to construct collisions that an attacker could use.

Given HTML e-mail, plus Javascript, yes. OTOH, interpreting Javascript in e-mails is a bad idea anyway.

Re:These are important attacks.. (1)

Ckwop (707653) | more than 9 years ago | (#12783369)

Well, you can have two MP3s that sound the same even though they're different and you can have two jpegs that look the same even though they're different.

There's plenty of scope for changing the files, we only need to select roughly 128-bits in each file to message about with to drive a collision.

I agree with your suggestion to use Javascript over HTML to "disguise" the change.

Simon.

Re:These are important attacks.. (1)

swillden (191260) | more than 9 years ago | (#12783644)

Well, you can have two MP3s that sound the same even though they're different and you can have two jpegs that look the same even though they're different.

But you can't practically generate two MP3s or JPEGs that have *meaningful* differences, yet hash to the same value.

Re:These are important attacks.. (1)

Idimmu Xul (204345) | more than 9 years ago | (#12783645)

MP3s and JPGs do allow tags to contain extra data that will not effect how the music sounds or what the image looks like at all.

That's pretty irrelevent though as the whole point of this hack is that you change the sound or the image anyway, then add the extra data to make it hash correctly to a specified hash

The junk would be obvious (1)

PIPBoy3000 (619296) | more than 9 years ago | (#12783367)

If things went to court, it should be fairly easy to obtain a copy of the forged electronic document and look for added junk.

A novice might miss it, but a trained eye could easily see the garbage.

What worries me more is executeables where you're depending on the hash to match. If the file sizes are approximately the same, it would be very easy to trick someone into running something that is actually something else.

Re:The junk would be obvious (1)

MAdMaxOr (834679) | more than 9 years ago | (#12783466)

If things went to court, it should be fairly easy to obtain a copy of the forged electronic document and look for added junk.

Lets imagine a more devious employer. What if the junk was on the legitimate document? The employer has you sign the one with junk, and then when it goes to court, the employer claims that YOU generated a hash collision to write yourself an easier/better contract.

It works both ways. The junk could be on either document, and both parties have motives to forge a document.

Re:The junk would be obvious (1)

kallisti (20737) | more than 9 years ago | (#12783641)

The junk could be on either document, and both parties have motives to forge a document.


Since this is an attack in which you create two documents, the party which created the document must be the would-be forger. I think your evil employer would have a hard time convincing the court that I wrote the document they had me sign.

Re:These are important attacks.. (2, Informative)

pz (113803) | more than 9 years ago | (#12783458)

I now make sure the company IT system "forget" the first document and I've successfully screwed you.

Not quite, beacuse of reasonable doubt and the fact that the hypothetical employee would have copies of the document.

However, Alice can get Bob to sign an innocuous recommendation letter that in the hidden version is a power of attorney for Bob's bank accounts. Alice can then take the fraudulent letter to Bob's bank and with apparent legality, take all of his money. (The difference being that a third party is involved who is naive to the document Bob signed and his intents.) This is effectively the scenario suggested in TFA, and because there is no alternate version of the document, Bob has no recourse (unlike the parent poster's suggestion).

To exploit this hole in MD5 (SHA-1, or whichever hashing function you like), you need to create two completely different documents, not two which are different versions of the same thing and can be compared by humans. That's the real hole: these documents need to be printed out (or rendered on a screen) and interpreted by humans who assume that the rendering process is trustworthy because it is complete and veracious. If humans natively read PostScript with the same ease we read English, for example, this kind of exploit wouldn't be possible.

Re:These are important attacks.. (1)

St. Arbirix (218306) | more than 9 years ago | (#12783478)

As an amateur cryptographer

I'm curious, do you get to take classes in that or is it graduate work? I'm currently in my undergrad at a school that doesn't have any cryptology courses. When I graduate in December I'll be heading off to the Navy to (hopefully) do crypto, but I wonder where civilian cryptology programs are.

Civilian cryptology training (0)

Anonymous Coward | more than 9 years ago | (#12783700)

Here's a short article Bruce Schneier wrote on how to become a cryptographer (as a civilian): http://www.schneier.com/crypto-gram-9910.html [schneier.com]

Re:These are important attacks.. (1)

Locke2005 (849178) | more than 9 years ago | (#12783600)

people would do well to realise you have to spend CPU cycles to get security.

This should be obvious to anyone. Any reasonably fast and efficient hash or encryption algorithm can be brute forced given enough time on a sufficiently large parallel machine. This means 1) Any truly effective hash or encryption must be slow, even on the latest hardware, and 2) any algorithm is reasonably secure today won't be secure against a dedicated attack by somebody with sufficient resources 10 years from now. Given the constantly advancing state of the art, any usable algorithm will eventually be broken; nothing can stay encrypted forever.

Completely OT (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#12783132)

Look what i just read
http://www.cbsnews.com/stories/2005/06/10/world/ma in700979.shtml [cbsnews.com]

(AP) Israel is considering using an unusual new weapon against Jewish settlers who resist this summer's Gaza Strip evacuation - a device that emits penetrating bursts of sound that leaves targets reeling with dizziness and nausea.

Security forces could employ the weapon to overcome resistance without resorting to force, their paramount aim. But experts warn that the effects of prolonged exposure are unknown.

The army employed the new device, which it dubbed "The Scream," at a recent violent demonstration by Palestinians and Jewish sympathizers against Israel's West Bank separation barrier.

Protesters covered their ears and grabbed their heads, overcome by dizziness and nausea, after the vehicle-mounted device began sending out bursts of audible, but not loud, sound at intervals of about 10 seconds. An Associated Press photographer at the scene said that even after he covered his ears, he continued to hear the sound ringing in his head.

because it wont get posted by the editors untill next week. Does this not scare ths shit out of every person alive?

Re:Completely OT (0)

Anonymous Coward | more than 9 years ago | (#12783429)

Is that the same device that was used against WTO protestors in the United States?

Go America! One day you will be as oppressive as China.

--- Slashdot can't count:

Slow Down Cowboy!

Slashdot requires you to wait 2 minutes between each successful posting of a comment to allow everyone a fair chance at posting a comment.

It's been 25 minutes since you last successfully posted a comment

I couldn't agree more... (1)

huckda (398277) | more than 9 years ago | (#12783135)

- but many so-called 'practitioners' turned them down as 'practically irrelevant'."

A critical event... (1)

jsight (8987) | more than 9 years ago | (#12783164)

See Schneier's Blog [schneier.com] for more thoughts on the subject. I am sure it will get fleshed out more as more details emerge.

Security Through Obscurity (0, Offtopic)

Trolling4Columbine (679367) | more than 9 years ago | (#12783165)

"Encryption" is just another flawed method of concealing information behind obfuscated algorithms. History has proven time and again that such techniques are inevitably compromised, and therefore useless.

My suggestion: if you want your data to be protected that well, don't transfer it over electronic media.

Re:Security Through Obscurity (0)

Anonymous Coward | more than 9 years ago | (#12783399)

You're a very good troll. I hope someone mods you up by mistake :D

Re:Security Through Obscurity (3, Informative)

Dachannien (617929) | more than 9 years ago | (#12783403)

We're talking about cryptographic hashes here, not encryption. Encryption is meant to be a reversible process, and is therefore one-to-one. In other words, there's no concern over collisions with encryption.

With cryptographic hashes, you're throwing away nearly all of the data to obtain a hash (a number) which represents the larger data set in such a way that (hopefully) the hash will never turn up again in practical usage. The article here indicates that there are ways being devised to force two data sets to have a hash collision while keeping the practical parts of the data sets the same.

As for accusing encryption of being "security through obscurity", you're misusing that term. If knowing the encryption algorithm allowed you instant access to all data encrypted with that algorithm, then yes, the only security present would be dependent upon the secrecy of the algorithm itself. But that's not the case here. Encryption typically works by public key exchange, meaning that a key (a number) used to encrypt messages is shared with the encrypting partner, while the key to decrypt and recover the data is kept private (is never transmitted). Recovering the private key through brute force is not a compromise of the algorithm itself - given enough time, any private key can be recovered, regardless of the algorithm, but by increasing the key size arbitrarily, the time taken to find that key can also be increased arbitrarily.

OT - Repy to tagline troll (-1, Offtopic)

orasio (188021) | more than 9 years ago | (#12783428)

Capitalism is fueled by Greed. Socialism is fueled by Envy. Which is your sin?


Capitalism is fueled by greed, and it works, at least it works if people are greedy.
Socialism doesn't work if people are envious.
Socialism wasn't created by people who were envious. Usually socialists (not just people who call themselves that) are people who might like their place in society, but would rather be a piece of a better society. In general the "sin" of socialists is to not understand that human nature makes socialism a much harder task than it was though, it might even be impossible.

Re:Security Through Obscurity (2, Informative)

MyTwoCentsWorth (593731) | more than 9 years ago | (#12783450)

Dear me,

Your ignorance is so appalling that I have a hard time deciding where to start.

First - this is about digital signatures, not about encryption - sharing the documents (by sending them over electronic media or otherwise) is needed.

Second - obfuscated algorithms ??? Open any book on encryption to learn that the strongest encryption algorhitms rely on completely documented algorhitms - security through obscurity is so 80's...

My suggestion - try to have something worth saying before making suggestions.

Happy Posting.

Re:Security Through Obscurity (3, Informative)

loose_cannon_gamer (857933) | more than 9 years ago | (#12783632)

I think that's a big shortsighted... I agree that if we let history take a crack at it, that any encryption put together by smart people will eventually be breakable by smart people.

However, most data that I deal with day-to-day is time relevant. Do I care if someone figures out my credit card number on an account I closed 5 years ago? Is it terrible if someone hacks an old email only to find out I was begging a professor for a passing grade in 1997?

Encryption is meant to hide things, and for many things, the need to hide is temporary. If the hidden thing stays hidden as long as it needs to stay hidden, there is nothing wrong with it.

Know the limitations on the technology you use, and know the parties with which you exchange information. Those two rules alone, if followed, will probably provide more than adequate real-world defense. Perfect? No. Good enough. Statistically, yes.

Re:Security Through Obscurity (1)

bturnip (761620) | more than 9 years ago | (#12783658)

And if this was a time before electronic media, would the suggestion be "don't write it down on physical media"? ;)

What are the alternatives? (2, Insightful)

CyricZ (887944) | more than 9 years ago | (#12783169)

If MD5 is found to be insecure, what are the alternatives we can use when signing our open-source packages? Is there any other alternative that is even approaching the widespread use of md5sum?

Re:What are the alternatives? (4, Informative)

specialbrad (884393) | more than 9 years ago | (#12783243)

The signing of open-source packages are to prevent download corruption usually. If a download is corrupted, the data will be different, and hence the hash will be different. Most of these attacks are malicious in that you have to go great lengths to find a collision to use. If your connection corrupts the download in such a way to produce a collision, your modem obviously hates you.

Obvious solution (1)

gr8_phk (621180) | more than 9 years ago | (#12783310)

The obvious solution is to encrypt the file/document/OSSpackage with a private RSA key. The only way to view it then is to use the public key - which is published just like a MD5 sum.

There are 2 reasons people do this. 1) decryption takes longer than computing a checksum. and 2) this would force everyone to decrypt the file in order to use it. Only paranoid people and those who realize bits get corrupted bother to verify checksums now.

Reliable solutions are entirely available, people just need to start using them. BTW, I'm no expert but I think there are simpler ways than that suggested above.

Re:What are the alternatives? (2, Informative)

rbarreira (836272) | more than 9 years ago | (#12783372)

I may be wrong but I think that for that purpose, the use of MD5 is still quite secure. What those researchers did was make 2 files with the same MD5, they didn't choose the md5 value itself. In order to crack the schemes you're mentioning the md5 value is a given value for which you want to generate another file (many times with the additional restriction that the file sizes must match).

Read about collision attacks versus preimage attacks here [cryptography.com] .

Unless you're assuming that at least one of the people responsible for redistributing the software have bad intentions?

Re:What are the alternatives? (1)

tjw (27390) | more than 9 years ago | (#12783498)

'gpg -ba THEFILE'

This generates a detatched signature named "THEFILE.asc".

The .asc file can used to verifiy the authenticity of THEFILE by the end user with the command:

'gpg --verify THEFILE.asc'

This method is already in pretty widespread use for open source software distribution. For example, Slackware has used for all official packages since 8.1.

Text of Letters (3, Informative)

pete-classic (75983) | more than 9 years ago | (#12783172)

For those who can't convientently view PostScript files, the text of the two letters:

Julius. Caesar
Via Appia 1
Rome, The Roman Empire
Alice Falbala fulfilled all the requirements of the Roman Empire
intern position. She was excellent at translating roman into her gaul
native language, learned very rapidly, and worked with considerable
independence and confidence.
Her basic work habits such as punctuality, interpersonal deportment,
communication skills, and completing assigned and self-determined
goals were all excellent.
I recommend Alice for challenging positions in which creativity,
reliability, and language skills are required.
I highly recommend hiring her. If you'd like to discuss her attributes
in more detail, please don't hesitate to contact me.
Sincerely,
Julius Caesar

Julius. Caesar
Via Appia 1
Rome, The Roman Empire
May, 22, 2005
Order:
Alice Falbala is given full access to all confidential and secret
information about GAUL.
Sincerely,
Julius Caesar

Re:Text of Letters (1)

pete-classic (75983) | more than 9 years ago | (#12783201)

Oops. Missed a couple of lines from the first letter:

May, 22, 2005
To Whom it May Concern:

So it should read:

Julius. Caesar
Via Appia 1
Rome, The Roman Empire
May, 22, 2005
To Whom it May Concern:
Alice Falbala fulfilled all the requirements of the Roman Empire
intern position. She was excellent at translating roman into her gaul
native language, learned very rapidly, and worked with considerable
independence and confidence.
Her basic work habits such as punctuality, interpersonal deportment,
communication skills, and completing assigned and self-determined
goals were all excellent.
I recommend Alice for challenging positions in which creativity,
reliability, and language skills are required.
I highly recommend hiring her. If you'd like to discuss her attributes
in more detail, please don't hesitate to contact me.
Sincerely,
Julius Caesar

huh? (-1, Offtopic)

illtron (722358) | more than 9 years ago | (#12783178)

I find it hard to believe that even Slashdot readers find this interesting.

Re:huh? (2, Funny)

Captain BooBoo (614996) | more than 9 years ago | (#12783242)

Are you kidding? ANY article with the word "hash" in it is going to grab the attention of even the weakest synapse. ôô

Re:huh? (1)

rbarreira (836272) | more than 9 years ago | (#12783309)

Care to explain why?

Re:huh? (1)

Compact Dick (518888) | more than 9 years ago | (#12783322)

I find it hard to believe that even Slashdot readers find this interesting.

This latest development should not only concern us nerds, but the rest of us as well. You see, this time they demonstrated that two messages can have the same hash, and neither of them need look like gibberish.

In other words, one might read "Bow before me and my enormous todger!" while the forgery could be "Warning: you need an electron microscope to view my penis". How can one tell which is real and which is fake?

Explanation of the attack (4, Informative)

swillden (191260) | more than 9 years ago | (#12783179)

What these researchers did was not to improve the known attacks on MD5, but to demonstrate a clever way of turning the known attack, generally considered to be of theoretical interest only, into an attack that could potentially really be used.

The way they did it was to create a postscript document that actually contains two documents, one that the sender would be willing to sign and one that he presumably would not. The full text of both is contained in the file, but near the beginning of the file is a bit of code that compares two blocks of random-appearing bits, call them A and B. If A == B, the postscript interpreter will select the innocuous message and display that. If A != B, the interpreter will display the other message.

The researchers then generated a pair of blocks with the same MD5 hash. In one copy of the postscript file, they used one of these blocks as both A and B. In the other copy, they used one block as A and the other as B. Because every bit of both documents before and after the two blocks is identical, and because those blocks hash to the same value, the documents hash to the same value.

It's an interesting attack. It only applies to documents that are also programs, in some sense, but we use lots of document formats that fit that description.

A simple countermeasure that makes such an attack more difficult is to compress the documents before signing.

Re:Explanation of the attack (1)

rbarreira (836272) | more than 9 years ago | (#12783265)

Yes, that shows a drawback of the method - evidence of the attack is present on both files, you just have to hex edit them and look for their content...

Nevertheless, it's a good way to shut the mouths of the ones who say that hash function attacks are still theoretical...

Re:Explanation of the attack -- enforcement issues (2, Interesting)

Eclectic Engineer (830396) | more than 9 years ago | (#12783457)

It is an interesting attack, and IANAL, but I'd be curious about the legal ramifications. If I slip a carbon (ah... the way-back machine) in a stack of papers and ask someone to sign the top one without thus informing them, I think my stealth probably invalidates the additional document(s).

You could argue that there's a noticeable difference between pen and carbon -- making the copy hard to enforce -- but I'd argue the digital version is even easier: at least in the PS example, both "copies" of the document need to be present to preserve the hash.

In normal (pen/paper) signature situations, I get a copy of what I signed. The same ought to apply to digital sigs, resulting in a simple legal challenge to the validity of the document.

Not exactly useful for fraud... (4, Insightful)

argent (18001) | more than 9 years ago | (#12783629)

Clever, but it means the attack is not a general way to forge an MD5-signed document... you couldn't use this (for example) to seed a P2P network with malicious files that look like safe ones. It only works if you generate both documents, and it can only be used maliciously if it's never examined by an expert: the signer can't retain a copy of the signed document or obtain a copy through discovery.

really? (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#12783184)

4EBADA6A2AF2BCBA53DED1D7B414F081

It's been around long enough... (1)

amalcon (472105) | more than 9 years ago | (#12783219)

Maybe now, people will finally start migrating to a different hash algorithm for signatures. MD5 has been around long enough that people have known this sort of thing is possible for some time. It's only now that they finally sat down and did the proof-of-concept.

Of course, MD5 passwords are probably still safe, for now (between maximum password lengths and the fact that this attack will have a hard time actually doing that), but it's only a matter of time.

3n(ryp710n 15 0v3rr473d (-1, Redundant)

roman_mir (125474) | more than 9 years ago | (#12783231)

ROT13 zhfg or rabhtu sbe rirelbar

BASE64 bXVzdCBiZSBlbm91Z2ggZm9yIGV2ZXJ5b25lIHdobyBjYXJlcy BhYm91dCB0aGUgYmluYXJ5

HEX 6d 75 73 74 20 62 65 20 65 6e 6f 75 67 68 20 66 6f 72 20 65 76 65 72 79 6f 6e 65 20 77 68 6f 20 69 73 20 68 69 64 69 6e 67 20 64 61 74 61 20 66 72 6f 6d 20 61 72 74 73 20 73 74 75 64 65 6e 74 73

01000010 01101001 01101110 01100001 01110010 01111001 00100000 01101101 01110101 01110011 01110100 00100000 01100010 01100101 00100000 01100101 01101110 01101111 01110101 01100111 01101000 00100000 01110100 01101111 00100000 01101000 01101001 01100100 01100101 00100000 01100100 01100001 01110100 01100001 00100000 01100110 01110010 01101111 01101101 00100000 01110100 01101000 01101111 01110011 01100101 00100000 01110000 01100101 01101111 01110000 01101100 01100101 00101100 00100000 01110111 01101000 01101111 00100000 01100100 01101111 01101110 00100111 01110100 00100000 01100111 01100101 01110100 00100000 00100111 01110100 01101000 01100101 01110010 01100101 00100000 01100001 01110010 01100101 00100000 00110001 00110000 00100000 01101011 01101001 01101110 01100100 01110011 00100000 01101111 01100110 00100000 01110000 01100101 01101111 01110000 01101100 01100101 00100111 00100000 01101010 01101111 01101011 01100101 00101110

and I can't post in Morse because /. lameness filter sucks.

Re:3n(ryp710n 15 0v3rr473d (0)

Anonymous Coward | more than 9 years ago | (#12783534)

In this case, I think the lameness filter has been a little lenient...

Kids in Finland don't agree (5, Insightful)

StreetFire.net (850652) | more than 9 years ago | (#12783248)

Regarding being "practically irrelevant"

"every time [some software engineer] says, 'nobody will go to the trouble of doing that,' there's some kid in Finland who will go to the trouble."
Taken from Kevin' Mitnik's "The Art of intrusion"
http://www.amazon.com/exec/obidos/tg/sim-explorer/ explore-items/-/0764569597/0/101/1/none/purchase/r ef%3Dpd_sxp_r0/104-8074733-7395136 [amazon.com]

Re:Kids in Finland don't agree (1, Informative)

Anonymous Coward | more than 9 years ago | (#12783474)

Nice referrer link.

Possible solution (2, Insightful)

orb_fan (677056) | more than 9 years ago | (#12783280)

Is the answer then to create a hash that is in fact the sum of two distinct hashing alogrithms? For example, use MD5 and SHA1. Since the alogrithms use different methods, the set of collisions from one would not overlap the set from the second (or rather the overlap would be vanishingly small). And if the overlap was larger than you wanted - just keep adding different hash alogrithms until you are satisfied.

I realise that the computations involved aren't cheap, but it becomes a trade-off between security and speed - the more sure, the more time it will take.

7 bits difference (2, Informative)

lavalyn (649886) | more than 9 years ago | (#12783282)

Compare the two files, and you see that there were only 7 bits that changed, all on the 5th most significant bit of the affected byte.

I guess it's obvious from looking at the ps file in text form, but if it's that easy to mangle postscript to display two different layers (or is it changing comments or pointers? I am not a binary postscript parser.) I still don't think it's time to throw md5 away yet. Six months.

What other hashing alternatives are there these days? SHA-1 apparently has the same kinds of weaknesses.

Perhaps its time for another layer of protection. (3, Funny)

vonstauf (827404) | more than 9 years ago | (#12783292)

We could just couple it with another widely used industry standard [rot13.com]

Okay, I'm impressed. (4, Interesting)

ave19 (149657) | more than 9 years ago | (#12783348)

At first I thought: Postscript! Well, obviously. To find a collision, you've probably got to hide a clump of randomness in the document, and then rotate that clump until the hashes collide. If you tried to hide random data in a text file, it would be obvious to the person signing it. You need some format to hide the random bits from the viwer.

I bet the random parts are REALLY BIG! I mean, you'd probably need a lot of random data before you could find a collision...

Then I downloaded the files...

There's almost nothing to them! I can't read PS, so I'm not sure how many of that handful of bytes at the beginning might be tweakable... but it's a lot less than I expected.

Collisions must be very easy to find! I am now offically very worried about this.

Re:Okay, I'm impressed. (1)

gtrubetskoy (734033) | more than 9 years ago | (#12783507)


I bet the random parts are REALLY BIG! I mean, you'd probably need a lot of random data before you could find a collision...

You only need as much random data as fits in the size of the hash signature. I.e. for MD5, 128 bits is enough for at least 1 collision.

So you're saying I shouldn't implement MD5 ... (3, Interesting)

malcomvetter (851474) | more than 9 years ago | (#12783351)



in my next big project?

In all seriousness, I believe Schneier's right. We need a competition for a new hash function [schneier.com] .

Nah, let's just wait for 24 [techweb.com] to drop the words "MD5" before we know it's really bad.

Re:So you're saying I shouldn't implement MD5 ... (1)

Qzukk (229616) | more than 9 years ago | (#12783517)

You should provide some mechanism by which a user can select N hash methods to be used, with perhaps a warning against chosing MD5 or SHA1 alone. Then rather than users having to worry about this or that hash/encryption being broken, they can just switch, with warnings when they use the old algorithms (maintained for backwards compatibility).

I suspect that in the near future, signing will be done using two different hashes to seriously restrict the collision space.

Relative Resources: The Attackers' Advantage (4, Interesting)

G4from128k (686170) | more than 9 years ago | (#12783357)

The core problem is that the resources of the defender are inevitably overwhelmed by the resources of the attacker.
  1. Relative expected values of gian vs. loss: The attacker thinks "I know I can gain a #BIG_NUM million dollars" and devotes their full effort to the attack. The defender thinks "I'm safe, there's a low probability, and I'm sure I'll catch the problem before it becomes real money, " and does not not devote effort to security becuase a Gartner report told him it was over-hyped. Thus, the attacker's perceived expected value is much higher than the defenders perceived expected loss and each invests accordingly.
  2. Rising Complexity: As IT systems become more complex, they become less secure. Each new device, new networking protocol, new physical layer, new OS feature, new networked application provides new opportunities for the attacker and a dilution of security resources for defenders.
  3. Time: The attacker has the advantage of time. New algorithms, new mathematical theories, new exploits, and faster processors all favor the attacker. What once was supposed to take the age of the universe to crack can be decrypted with a quickly declining number of networked (even zombied) PCs.
  4. Curse of Compatibility: Because so much crypto and security is networking related, it is subject to implementation delays caused by the need to be compatible. Defenders continue to use old, vulnerable systems to maintain compatibility with key partners. Patches don't solve the problem because the patch itself can introduce incompatibilities that make defenders leary of applying the patch with a very real chance of causing problems to avoid a hypothetical security issue.
The bottom line is that the defender must protect all vulnerabilities while going about the day-to-day business of using the computer. In contrast, the attacker can devote full time to any weakness of their choice.

From a prior discussion... (3, Interesting)

erroneus (253617) | more than 9 years ago | (#12783390)

I forget where or when exactly, so please feel free to run a search if you care to... it was here on Slashdot though.

There was talk about someone being able to foil P2P networks by seeding bad stuff through random data formulated to fit the MD5/SHA1 code from legitimate files shared on those networks. The consensus was that it was BS and that even if it weren't BS there could be updates to make such attacks more difficult or impossible to perform.

Am I missing something or are these two stories relevant to each other?

Works for certificates, too (4, Interesting)

cpeikert (9457) | more than 9 years ago | (#12783402)

Lenstra and others came up with a way to generate syntactically-correct X509 certificates that collide under MD5.

Here's a link to the paper: Lenstra et al [iacr.org] .

It was only a matter of time (1)

m50d (797211) | more than 9 years ago | (#12783410)

I hope all those who said the previous MD5 attacks were nothing to worry about will take it back. A theoretical break or partial break is almost always followed by a practical break. The lesson to learn from this is not to do the same thing with SHA1 and, I would suggest, AES. The vulnerabilities might be impractical now but they won't stay that way. Move now, while you're still at least partially secure, rather than once there's a practical break.

Re:It was only a matter of time (0)

Anonymous Coward | more than 9 years ago | (#12783676)

Ok, admittedly the MD5 hash of the sum my knowledge of hash algorithms quite likely collides with the MD5 hash of /dev/null.

But isn't this just showing a theoretical weakness of any hash algorithm? Use two hashes, then. One of the normal file and one of an encrypted version. One might collide, but both won't. Think this is a stupid idea? Well, then kindly reread the first paragraph. ;)

[summary] (1)

823723423 (826403) | more than 9 years ago | (#12783464)

[1]
[LdW] A. Lenstra, B. de Weger: On the possibility of constructing meaningful hash collisions for public keys
http://www.win.tue.nl/~bdeweger/CollidingCertifica tes/ddl-full.pdf [win.tue.nl]

[2]
Using the length extension property present in MD5 and all other hash functions following the (almost omnipresent) Merkle-Damgaard design principle, we constructed a pair of documents to display either the letter or the order.

My New Hash Function (1)

MobileMrX (855797) | more than 9 years ago | (#12783472)

I am currently working on a hash function that returns the exact value of the hashed value. The algorithm works a little something like this:

MyHash(ValueToBeHashed) = ValueToBeHashed

I have done extensive testing on this algorithm and have not been able to produce any collisions yet... I'll keep you guys updated. (I also used this new function to hash this message for verification!)

--------

MobileMrX Hash:

I am currently working on a hash function that returns the exact value of the hashed value. The algorithm works a little something like this:

MyHash(ValueToBeHashed) = ValueToBeHashed

I have done extensive testing on this algorithm and have not been able to produce any collisions yet... I'll keep you guys updated. (I also used this new function to hash this message for verification!)

Stupid Forced Collision (1)

ch0p (798613) | more than 9 years ago | (#12783500)

Compile the following untested code twice, once with the name md5collision, and again with some other name. Check the hashes, and check the output. This is the same as the above postscript example.
#include <stdio.h>

int main(int argc, char *argv) {

if (argv[0] != "md5collision") {
printf("This was a dumb, forced, collision that would never happen in real live.\n");
} else {
printf("This is a legitimate file, with the same hash as that other file I compiled.\n");
}
exit(0);
}

Re:Stupid Forced Collision (-1, Redundant)

airrage (514164) | more than 9 years ago | (#12783531)

Interesting ...

practically irrelevant... (0)

Anonymous Coward | more than 9 years ago | (#12783541)

MD5 seemed like a good way to check for duplicate jpg images, sometimes an image with the same data had a different name.
But equivelent MD5 hashes of different images made a mess of that scheme.
Oddly enough SHA had the same problem, though I didn't check to see if it was for the same set of images...
I thought it was maybe a problem with the python MD5 and SHA libs and abandonded the idea.
I wonder if the nature of jpg compression significanlty reduced the (mathmatical) image "space" and thus
raises the probability of hash equivelence for non identical images.
One should be able to see the effect with a many thousand jpg images.

From Schneier's Blog... (1)

sam5550 (841429) | more than 9 years ago | (#12783564)

Other attacks on MD5 [schneier.com]

The provided exploit documents can be edited! (3, Insightful)

rar (110454) | more than 9 years ago | (#12783576)

What I haven't seen mentioned yet, and people perhaps haven't realized, is that in providing these two postscript files, they have essentially provided you with an postscript signature exploit kit!

All you need to do is download the two postscript documents and do *exactly corresponding edits* in both of them, and you get two documents saying different things and still have the same md5sums!

I just tried exchanging Alice's name for my own, and surely it did work.

Now, if they released a pdf-file hack, I would be genuinely worried :)...
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>