MD5 - Not as safe as once believed

Quote:

---

Originally posted here by gore
That's more of an opinion isn't it?

---

I tink I'll go with whatever the standard is ;) Not that I don't appreciate your opinions :)

Just as a side-note... how the hell does it make a difference what people think of people? First off whatever has been said in this thread were merely ideas and thoughts based on what started out as a speculation about MD5 and what's better to use for the future... since when can that be a reason for evaluating whatever gore, Striek, myself or whoever else actually knows about the topic of cryptography?

Admittedly Striek's comment about hashing and encryption was a bit vague... but holy f!ck people! :D

Yeah, it was too vague. I never intendended it to start something like this.

Sorry about that.

Hrmmm... feet don't tase so good when you put them in your mouth.

Quote:

---

Originally posted here by chsh
I think you are failing to recognize the actual scope of the issue.

---

Hey, you're way out of line kid. Let's get some cold ****ing fizzy water on your head.
Why don't you go read the DOD-STD-5200.28 on encryption, then come back and tell thehorse how to do his job.

I've said it once and I will say it again, I welcome people to disagree with me especially when they provide reasons. Isn't that the point of a forum? As chsh has noted, I'm a big boy and I'm certainly capable of backing up my opinions. His style of responses and those similar never cost me a second of sleep. I'm comfortable with my level of knowledge and I never ever become defensive when someone challenges it.

Quote:

---

Originally posted here by !mitationRust
Hey, you're way out of line kid. Let's get some cold ****ing fizzy water on your head.
Why don't you go read the DOD-STD-5200.28 on encryption, then come back and tell thehorse how to do his job.

---

Err, don't tell me YOU don't know the difference between hashing and encryption too! I'm beginning to think it's an epidemic.

EDIT: Even aside from the above, all I could find for various terms was "DOD-STD-5200.28 DEPARTMENT OF DEFENSE TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA" located at: http://jcs.mil/htdocs/teinfo/software/did27.html which oddly enough does not mention encryption at all.

Perhaps you could link me directly, since I am apparently but a child and incapable of researching something that has nothing to do with the discussion at hand.

P.S: Since you evidently haven't gotten past a grade 8 reading level yet, I wasn't telling TH how to do his job, in fact, if you read the thread nowhere do I tell him he is wrong, I simply disagree with him on the scope of the issue, and his examples thereof.

Quote:

---

Originally posted here by chsh

EDIT: Even aside from the above, all I could find for various terms was "DOD-STD-5200.28 DEPARTMENT OF DEFENSE TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA" located at: http://jcs.mil/htdocs/teinfo/software/did27.html which oddly enough does not mention encryption at all.

---

Where the hell did you get that from, it's mentioned six times. If some could only read, some would know encryption has nothing to do with system security.
If you could read past the first couple pages that would help also. All you read was the table of contents! Like thehorse said, objectivity is the point of the forum. But what I've read from you in the past, it's safe to take catch's suggestion. Your mind is already made up, not to mention it's functioning in a closed-loop type manner.

Quote:

---

LMAO! Thanks for the sig material man!

---

Yeah, I found some sig material aswell.

Quote:

---

~catch
Ah chsh back trolling again...

The reason I ignored your questions was because I'd already answered them and to be honest, I really have better things to do with my spare time then to educate the likes of you. That is people who have already made up their mind and just wish to fight and post so much **** that it isn't practical for me to take the time to respond to every little piece.

---

He was right.

Quote:

---

Originally posted here by !mitationRust
Where the hell did you get that from, it's mentioned six times.

---

Oddly enough, I read "more than the table of contents", encryption itself does not come up at all, merely data protection methods. Feel free to quote relevant bits.

Quote:

---

If some could only read, some would know encryption has nothing to do with system security.

---

Funny thing is, you're going off on a tangent completely irrelevant to this thread, which I also pointed out and you continued to ignore.

Quote:

---

If you could read past the first couple pages that would help also. All you read was the table of contents!

---

:rolleyes:

Quote:

---

Like thehorse said, objectivity is the point of the forum. But what I've read from you in the past, it's safe to take catch's suggestion.

---

Of course it is, why let facts be such a bother when you can easily sidestep them and just flame the poster for saying something they didn't? I love that you brought up catch as an example, because frankly if you read EVERY thread we've debated in, he always runs away for "time away" or "work for a couple of weeks". He disappears when the facts stack up against him, rather convenient I might add. Hey, if you want to quote the best troll AO's had in recent memory, feel free.

Quote:

---

Your mind is already made up, not to mention it's functioning in a closed-loop type manner.

---

Funny you say that given I already asked you to point me to a better source. I'm still waiting to see the pertinent section of said documentation. That you have avoided producing it is entirely catch-like behaviour. No wonder you like the guy so much.

Quote:

---

Funny thing is, you're going off on a tangent completely irrelevant to this thread, which I also pointed out and you continued to ignore.

---

Pretty much everything posted here in the last two days has been irrelevant to the original topic of this thread. This thread was originally posted to debate the continued usefulness of MD5 as a hashing algorithm.

All opinions aside, I can only see one post on the page here which actaully says anything on the matter. This thread has turned an otherwise useful debate into an ego-bashing festival. It has served its purpose.

I for one am asking a mod to close this thread, as it is no longer contributing in a useful manner to this forum.

Before closing this thread, I'd like to take a stab at moving it back to what it was about. Keep in mind everyone that people can choose to contribute or not contribute any thread. They can also choose to decide what they want to contribute. I'll leave that to you to figure out..

That said, I have some questions for my own personal clarification:

!matationRust: The Orange Book Classification (aka DOD-STD-5200.28 DEPARTMENT OF DEFENSE TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA) doesn't seem to indicate any reference to encryption. I always understood that it dealt with Access Controls specifically and the levels or types of Access Controls (MAC, DAC, etc.). Perhaps I'm misunderstanding your point as to where it refers to it. The only thing that I could find that was close was the question of integrity of a system. Is this what you were referring to? This does lead to my next question

To all: Since MD5 is now "crackable", and thus now becomes a questionable encryption tool for usage in integrity situations, what are viable, publically available tools that can be used? And how long before the general public is aware of this? Many linuxes suggest the use of MD5 (because it's "more secure") for shadow passwords.

Are we going to see AES or others being "pushed" more now as alternatives? What about sites that use the MD5 hash as a verification of their product (which is pretty much commonplace for any Open Source project)? Is there in existence -- to anyone's knowledge -- any alternatives to tools like MD5sum? Are there projects that deal with this yet?

This is what it boils down to: we know that MD5 is now "useless". So what are we going to do as alternatives?

MD5 being cracked shouldn't really come as a surprise. It happens with all forms of encryption (or hash algorithms) sooner or later; this is why we're not using MD4 anymore.

It should not pose a huge problem to anyone. Any security policy should cover what to do when your existing methods become useless. A plan should be in place for just such an occasion, because it *will* happen.

Many Open Source sites use MD5 as a verification tool, yes. However, the more constientious sites (kernel.org and kde.org come to mind) also sign those hash lists. Although theoretically, one could calculate the MD5 of a given file and replace it with a trojan (not yet, but it's coming soon), one could not yet sign that hash file with the proper key. As such, timestamping these hash lists by a trusted third party could serve as a temporary solution. This however requires the public to routinely check the timestamp and verify it with the release date, which might not happen as often as we'd like.

A more permanent solution would be to do the same thing we always do when the current encryption techniques become useless. Move to a better algorithm. Currently, the best alternative is SHA-1, since it is also included as part of the coreutils package and is therefore available on most every system that already has MD5 algorithms available.

So if MD5 being cracked is the end of the world for you, maybe you shouldn't be working in a field that required it.

It's OK guys, one time keypads are still safe, if used properly ;)

Quote:

---

Originally posted here by MsMittens
To all: Since MD5 is now "crackable", and thus now becomes a questionable encryption tool for usage in integrity situations, what are viable, publically available tools that can be used? And how long before the general public is aware of this? Many linuxes suggest the use of MD5 (because it's "more secure") for shadow passwords.

---

Well I think there's really two issues to deal with here. MD5 as a hashing algorithm for generating file signatures, and MD5 as a password hashing algorithm.

EDIT: [...]

The trick with using this issue to exploit a system is to discover the colliding changes, and then append your arbitrary data into both the original and the malware. If Tripwire already knows the original as not having the apended data, then it will still notice. md5(x+q) = md5(y+q) doesn't mean md5(x) = md5(y+q) where x is the original and y is the collision. The most you could do without appending the data is break the app.

EDIT:
For evidence verification, I think this note about the scope of collisions is interesting:

Quote:

---

FROM: http://www.doxpara.com/md5_someday.pdf
In addition, being limited to the MD5 initial state means only hashes calculated on a per-file basis can be made to collide; a full disc or partition sum will come across the doppelganger set at a vastly different initial state and fail to collide. With the full attack we could specify our colliding blocks against the MD5 state that would be found during a full disk or partition hashing operation. Of course, then the colliding set we generated wouldn t collide on a per-file basis. Thus far we can only adapt to a single MD5 state at a time.

---

As for password collisions, there are various problems with trying to develop them if my understanding is accurate.
You have to have two hashes within the acceptable password range that are capable of producing the same hash. On linux, the maximum password length is 127 bytes (for interactively entered passwords). This yields 2^1016 or 7.0222388080559215e+305 combinations if we set aside the fact that you can't enter certain NPC combinations and operate in theory.
We already know that for a given dataset of 128 bytes in length there are somewhere near 6 possible bits that can be swapped.
Assume that the minimal size of a password for a hash collision is 512+8 which is MD5's minimum block size (can't have a collision with less than two blocks) plus one byte. This means you have to have a 65 character password to even begin to contemplate a hash collision, AND the collision must exist as the same size. Not sure how that was missed, but the last step of the algorithm is to add in a 64 bits referring to the size of the data being hashed.
The proof of this (as was previously mentioned) would show in a rainbow table. It may be mathematically impossible to find an MD5 hash collision for a dataset less than 64 bytes in size, I'm not sure, but it would seem so if my understanding is correct.

It would seem to me that it makes sense to continue using MD5 for password hashing.

Quote:

---

Are we going to see AES or others being "pushed" more now as alternatives? What about sites that use the MD5 hash as a verification of their product (which is pretty much commonplace for any Open Source project)? Is there in existence -- to anyone's knowledge -- any alternatives to tools like MD5sum? Are there projects that deal with this yet?

---

I know slackware uses GPG to provide PGP signatures for all their files.

Quote:

---

This is what it boils down to: we know that MD5 is now "useless". So what are we going to do as alternatives?

---

I think it's really only "useless" to use as data hash verification. Certainly for this other algorithms are going to take over, though IMO it will be a very slow process. For passwords it still seems to be a decent solution, unless you're in the habit of using passwords longer than 64 characters.

Msmittens: Yes, SHA1DEEP, found here is a good replacement:
http://md5deep.sourceforge.net/

Pay no attention to the project site name. It's a combination of md5deep and sha1deep. Basically..a recursive md5/sha1 tool.

Regarding all of the BS in this thread..you guys should really just grow up, and learn to disagree.

MD5 is still a viable hashing algorithm. As I said before, until NIST removes it from their standards list, it's viable and it WILL stand up in court. A junk science attack(when a lawyer reads that md5 can be 'cracked' and tries to throw it at you in court by saying "md5 has been cracked, how can you justify using it?") will do nothing more than embarrass the lawyer. The real problem there, is how well you can explain the method of how a hash is derived. And again, if it came down to it, the lawyer on your side could always subpoena someone from NIST, and get them to explain why it's a standard. Lawyers won't touch NIST.

Quote:

---

Originally posted here by hogfly
Regarding all of the BS in this thread..you guys should really just grow up, and learn to disagree.

---

If they learn to just disagree as you say they should wouldn't that mean MORE arguments, which is what you seem to be saying is stupid here? I mean seriously now, everyone says grow up, and people neg me saying to grow up.... What exactly does growing up solve? Nothing. If you think like a grown up and never question authority nothing gets done and no one would ever question a thing and misinformation would reign supreme.

I've read this and listened to how Tim was the only one who knew what he was talking about, and offered someone to prove one thing that I said as incorrect, and the only reponce I got out of that was something that was more opinion that fact based. Someone using DES over Blowfish, well, maybe that works better in the environment they operate in. I use Blowfish, it works in what I do better. 448 bit works fine which is what Blowfish can do.

One time pads are in my opinion still the best for security if you use them properly, but not every place on Earth has a high amount of keys or a way of getting them, so even though I'd say they were the most secure it doesn't mean they are going to be used.

You find something that's both secure and economical and work with it.

What I've seen so far is that the people in this thread are highly respected, except for me of course, half the people here still think I'm an idiot, including Jag, but that's OK, at least I know how to compile a Kernel and remember to type lilo when it's done instead of wondering why it won't work on IRC, and this thread still has arguments with people bitching about acting like little children.... Well so what? It's a discussion. Nothing personal hog I just can't stand the number of times a day people say grow up.

Quote:

---

MD5 is still a viable hashing algorithm. As I said before, until NIST removes it from their standards list, it's viable and it WILL stand up in court.
...
Lawyers won't touch NIST.

---

Hmm... never looked at it that way. Good point.

But as for MD5deep being a replacement for MD5 (I think that's what you meant), it still uses the MD5 algorithm, just does it recursively. How could that be a replacement if it uses the same algorithm? <insert confused look here>

I think MD5deep uses BOTH SHA1 and MD5, so you would have to have a crack for both of them to be able to do anything at all.

md5deep is capable of using any of the MD5, SHA-1, or SHA-256 algorithms. The choice is up to the user.

So if a user chooses to use MD5, that's all you gotta crack.

And we all know you can't write a program that protects against incompetence. After all, I could still use crc32 to hash evidence if I really wanted to...

Quote:

---

Originally posted here by gore


Nothing personal hog I just can't stand the number of times a day people say grow up.

---

Indeed, and I don't want this to turn in to a soapbox..but learning to disagree+growing up == agreeing to disagree without lowering yourself to a level where personal insults are thrown at eachother.

Striek:
Md5deep isn't a replacement. The project includes 3 tools. Sha1deep, sha256deep and md5deep. Each obviously creates a hash for said algo type. sha1, and sha256 would therefore be the replacement.