Live data from Hacker News

The long tail of MD5

tedunangst.com

51–58 of 58 posts

Re: The long tail of MD5

#51
post #11
post #7

Earlier quoted context omitted.

Depends on what you place in the expression broken. Md5 is useless in anything remotely related to security. An as a non secure function it is slow.

> Md5 is useless in anything remotely related to security There are serious flaws with MD5, and I would never recommend its use today. But there is no known attack that can generate a malicious binary with an arbitrary hash. The attacker needs to control both files to generate collisions, which is a huge limitation. Maybe those attacks will exist some day. But I wouldn't be setting fire to all your legacy software wi…

Given there are SHA256 engines that produce terahashes per second, you could probably do tens to hundreds of terahashes depending on sophistication.

At that point even a sloppy brute-force approach would have a high probability of a collision on at least one key of a sufficiently large key-set. Against a specific target it may or may not be viable.

Re: The long tail of MD5

#53
post #4

Earlier quoted context omitted.

I know, but this does not make MD5 as broken as ROT13.

Rot13 is actually useful. I have perl scripts which download my bank statements, running from cron. Gets the latest every month. These perl scripts use passwords, but without knowing that they are there, who would find them? The trouble is, they have to pass the name of the form field to the server on the other side, which is some variation of "password". So anyone doing a simple string search will eventually find th…

You're deluding yourself. Security through obscurity is barely worth the effort.

If you want this done in a fashion that's secure, deploy it on a small device like a Raspberry Pi and firewall that thing so aggressively you can barely get in. It's hard to hack what you can't connect to.

Re: The long tail of MD5

#54
post #50

Earlier quoted context omitted.

Rot13 is actually useful. I have perl scripts which download my bank statements, running from cron. Gets the latest every month. These perl scripts use passwords, but without knowing that they are there, who would find them? The trouble is, they have to pass the name of the form field to the server on the other side, which is some variation of "password". So anyone doing a simple string search will eventually find th…

That's pretty heavy security through obscurity. A more robust solution would be to have all of those passwords encrypted with a master key. You can make the script prompt you for the master key when you start it up, then it runs without needed any more input, but you aren't storing sensitive information.

Yes.

A master key. Which would have to be included in the perl script... so that when they find the script, they have all my passwords instead of just a few. You've solved it. Why didn't I think of that?

> You can make the script prompt you for the master key when you start it up,

Why the fuck would I want to sit around being a meat robot inputting 9 passwords at the beginning of each month just so I can have a copy of my bank statements and electric bill?

The whole point was that this was in a crontab.

Re: The long tail of MD5

#55
post #20

Earlier quoted context omitted.

Rot13 is actually useful. I have perl scripts which download my bank statements, running from cron. Gets the latest every month. These perl scripts use passwords, but without knowing that they are there, who would find them? The trouble is, they have to pass the name of the form field to the server on the other side, which is some variation of "password". So anyone doing a simple string search will eventually find th…

Note to self: add "cnffjbeq" to my password-finder scripts.

Might as well add rot-1 through rot-25 to it as well... not like there's a storage constraint, is there?

Re: The long tail of MD5

#56

Earlier quoted context omitted.

Well, ROT13 is at least immune to collision attacks.

Generating a collision for the "encrypted" phrase "unpx" is not hard.

It's not hard--it's impossible. The only value that ROT13 returns "unpx" for is "hack." There is no possible collision.

Re: The long tail of MD5

#57

Earlier quoted context omitted.

Generating a collision for the "encrypted" phrase "unpx" is not hard.

It's not hard--it's impossible. The only value that ROT13 returns "unpx" for is "hack." There is no possible collision.

Congratulations, you found a collision.

What's meant by that is if you can find a source string that hashes to the same thing. Using ROT13 is pointless since it's trivial to generate those.

MD5 is only slightly harder.

Re: The long tail of MD5

#58

Earlier quoted context omitted.

It's not hard--it's impossible. The only value that ROT13 returns "unpx" for is "hack." There is no possible collision.

Congratulations, you found a collision. What's meant by that is if you can find a source string that hashes to the same thing. Using ROT13 is pointless since it's trivial to generate those. MD5 is only slightly harder.

Reproducing the message is not a collision. In a collision attack, you find a message that produces the same hash as another message. You can't take the exact same message and call it a collision. ROT13 is immune to collision attacks by its nature, and the humor is in the fact that its "immunity" comes from not being a one-way hash. It's immune...but it's also practically useless for obfuscating the message, thus it doesn't protect your message at all. Thanks for taking great pains to make sure the joke got ruined.
Post reply on HN