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.

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.

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

Considering that the sentence continues with something that is clearly a joke (the SHA-3 standardisation isn't finalized yet, let alone wasn't thought of 20 years ago), some hyperbole is to be expected.

And the point is fair, there's not really anything today where MD5 is an obvious choice.

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 without first understanding exactly how they use MD5, and if that is vulnerable to any known attack.

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.

I think with practical chosen prefix attacks this may have changed.

As a non secure function its "killer app" is being everywhere on every platform and being massive overkill for many applications.

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 the perl scripts, and have access to my passwords (supposing they have root).

If I rot13 the form field name, and then have the name be rot13('cnffjbeq') in the script, this makes is unsearchable.

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?

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.

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.