You missed Digest::SHA. If the modules are otherwise equal, you should probably use Digest::SHA since people will be able to use the slower Digest::SHA::PurePerl as a drop-in replacement if they have problems installing Digest::SHA. Also, Digest::SHA's functional interface provides simple and easy access to common tasks.

By the way, while the [cpan://] is useful for searching, [mod://] is much better when linking to a specific module. e.g. [cpan://Digest::SHA] vs [mod://Digest::SHA]

Digest::SHA's functional interface provides simple and easy access to common tasks.

Don't do it that way. Instead, use Digest as a base module, and you can use any compatible Digest::* module as a plug-in. That way, your code doesn't have to change when switching between hash implementations — only the specification of what hash to use (a string), in the call to new.

See also the speed comparison table in that same module.

use Digest as a base module

I'm a novice when it comes to modules, so I'm not sure what you mean. Are you suggesting something different than just putting use Digest::SHA or use Digest::SHA::PurePerl at the top of my script? They both say they use the same interface as Digest::

TheEnigma

I don't think I can use Digest::SHA, since this is hosted on a 3rd party hosting service, and I wouldn't be able to recompile it. But, you're right, Digest::SHA would be better if I can use it, and if Mark Shelor's program turns out to be the module of choice.

Thanks for the tip about the link! I was being lazy and going on memory for what to use, I should have looked it up.

TheEnigma

If you can't compile the module, then that only leaves you with (the slow) Digest::SHA::PurePerl. The three others are all written in C.

As a user of cryptographic systems -- as I assume most readers are -- this news is important, but not particularly worrisome. MD5 and SHA aren't suddenly insecure. No one is going to be breaking digital signatures or reading encrypted messages anytime soon with these techniques. The electronic world is no less secure after these announcements than it was before.

If switching to SHA256 interests you, or helps you be more knowledgeable and up-to-date, then that's a good reason to switch, but I don't think you should think of use of MD5 in debugged and running code as a significant security hole in this context.

Yeah, just go ahead and cut corners. I mean it's just like nobody would ever need more than two digits to represent a year . . .

If it was existing code, sure it's not worth ripping out everything to change. However given that it's new code, go ahead and start correctly. Use Digest and you won't even need more than a configuration change in 17 months when SPECTRE breaks SHA-256 with the quantum computer they stole from the NSA and you have to go to SHA-1024.

If it's new code, I certainly agree, go with what's current and flexible. On the other hand, if the OP's (TheEnigma's) statement

I've got it working, using MD5

means that it's working in production, and switching would mean changeover, debugging and testing, then you have to weigh that cost against the risk of continuing with MD5, which apears minimal if, as the OP says, there are no secrets and no money involved.

Are there people who work with cryptographic tools and have access to a fair amount of computer horsepower who are also likely to be motivated to attack the web site of your homeowners association?

Well, there's that evil homeowners association just down the road... They're so competitive... ;)

Seriously, I know exactly what you're saying; in my case any kind of encryption at all is probably more than enough. After all, there's no money or secrets involved.

I was fat, dumb and happy using MD5 crypt until during testing, I noticed that only the first 8 characters of passwords seemed to matter. I found info on the web that MD5, (or at least the implementation I'm using, Digest::MD5), crypt only uses the first 8 characters. <update> I considered using MD5 instead of crypt. </update> Further searching revealed that MD5 and SHA1 have been broken, and if you're coding something new, you might as well go with SHA256. Since I havent't released my script yet, and since I want the whole password to count, I figured I should go with SHA256. And you're right, another reason is for me to learn.

My main concern here is if these modules implement SHA256 properly.

Thanks syphilis for pointing out my mistake

TheEnigma

I noticed that only the first 8 characters of passwords seemed to matter

Have you got some code that demonstrates that ? Here is some code that negates that statement:

use warnings;
use strict;
use Digest::MD5 qw(md5_hex);

my $pass1 = '12345678zy';
my $pass2 = '12345678ab';
my $pass3 = '12345678mn';

print md5_hex($pass1), "\n", md5_hex($pass2), "\n", md5_hex($pass3), "
+\n";
[download]

For me, it produces:

653080cea849964e8bd43ef33355c01b
b86ffaf7de29e8aa87785572741025f3
25c8c10a5673749bb097eea0e407addb

I defy anybody to come up with an MD5 collision for any strings of equal length.

Cheers,
Rob

#!/usr/bin/perl
# by Tachyon 
use Crypt::Blowfish;
use Crypt::CBC;

$KEY = 'GNUisnotUnix';  # Blowfish will take 56 bytes (448 bits) of ke
+y 
my $cipher = new Crypt::CBC( $KEY, 'Blowfish' );

my $enc = encrypt('Hello World');
my $dec = decrypt($enc);
print "$enc\n$dec\n";

sub decrypt { defined $_[0] ? $cipher->decrypt_hex($_[0]) : '' }
sub encrypt { defined $_[0] ? $cipher->encrypt_hex($_[0]) : '' }
__END__
[download]

Although I agree with the sentiment that you are not negligent using MD5, since it takes alot of cpu power to crack MD5, and the spy-guys have easier ways to get your passwords if they really want them. They keep it a big secret how they do it, but it's pretty easy, and even Blowfish won't help you against them.

Encrpytion and hashing solve different problems. In this case, hashing is much better. If the database is ever compromised, the passwords will be much safer if they have been hashed, as opposed to encrypted.

This answer applies to zentara's Blowfish solution as well.

The major problem with the use of these hashing mechanisms is the way they are used rather than with the hashing mechanisms themselves. You might be interested in the technique used in my challenge.

The essence of which is to append the md5_hex of the text, to that text, and then generate a new md5 from that combination. The effect is to considerably increase the difficulty of finding an alternative text that matches both the outer and inner md5 and renders a useful (to the bad guy), alternative text.

To my knowledge, none of the current attacks (yet) has an approach to this technique.

You might be interested in the technique used in my challenge

Unfortunately, it seems that satisfying the terms of your conditions might be about as difficult as finding a collision. Here's the full code I ran (based on 2 different text strings supplied earlier by ikegami):

use warnings;
use strict;

use Digest::MD5 qw( md5_hex );

my $text1 = "\xA6\x64\xEA\xB8\x89\x04\xC2\xAC"
          . "\x48\x43\x41\x0E\x0A\x63\x42\x54"
          . "\x16\x60\x6C\x81\x44\x2D\xD6\x8D"
          . "\x40\x04\x58\x3E\xB8\xFB\x7F\x89"
          . "\x55\xAD\x34\x06\x09\xF4\xB3\x02"
          . "\x83\xE4\x88\x83\x25\x71\x41\x5A"
          . "\x08\x51\x25\xE8\xF7\xCD\xC9\x9F"
          . "\xD9\x1D\xBD\xF2\x80\x37\x3C\x5B"
          . "\x97\x9E\xBD\xB4\x0E\x2A\x6E\x17"
          . "\xA6\x23\x57\x24\xD1\xDF\x41\xB4"
          . "\x46\x73\xF9\x96\xF1\x62\x4A\xDD"
          . "\x10\x29\x31\x67\xD0\x09\xB1\x8F"
          . "\x75\xA7\x7F\x79\x30\xD9\x5C\xEB"
          . "\x02\xE8\xAD\xBA\x7A\xC8\x55\x5C"
          . "\xED\x74\xCA\xDD\x5F\xC9\x93\x6D"
          . "\xB1\x9B\x4A\xD8\x35\xCC\x67\xE3";

my $text2 = "\xA6\x64\xEA\xB8\x89\x04\xC2\xAC"
          . "\x48\x43\x41\x0E\x0A\x63\x42\x54"
          . "\x16\x60\x6C\x01\x44\x2D\xD6\x8D"
          . "\x40\x04\x58\x3E\xB8\xFB\x7F\x89"
          . "\x55\xAD\x34\x06\x09\xF4\xB3\x02"
          . "\x83\xE4\x88\x83\x25\xF1\x41\x5A"
          . "\x08\x51\x25\xE8\xF7\xCD\xC9\x9F"
          . "\xD9\x1D\xBD\x72\x80\x37\x3C\x5B"
          . "\x97\x9E\xBD\xB4\x0E\x2A\x6E\x17"
          . "\xA6\x23\x57\x24\xD1\xDF\x41\xB4"
          . "\x46\x73\xF9\x16\xF1\x62\x4A\xDD"
          . "\x10\x29\x31\x67\xD0\x09\xB1\x8F"
          . "\x75\xA7\x7F\x79\x30\xD9\x5C\xEB"
          . "\x02\xE8\xAD\xBA\x7A\x48\x55\x5C"
          . "\xED\x74\xCA\xDD\x5F\xC9\x93\x6D"
          . "\xB1\x9B\x4A\x58\x35\xCC\x67\xE3";

if($text1 ne $text2){print "Texts are different\n"}
else {print "BOZO ... the texts are the same\n"}

print length($text1), " ", length($text2), " ", md5_hex($text1), "\n";

if(md5_hex($text1) eq md5_hex($text2)){print "The 2 hashes are the sam
+e\n"}
else {print "BOZO ... the hashes are different\n"}

$text1 .= ' ' . md5_hex($text1);
$text2 .= ' ' . md5_hex($text2);

print length($text1), " ", length($text2), " ", md5_hex($text1), "\n";

if($text1 ne $text2){print "Texts are still different\n"}
else {print "BOZO ... the texts are the same\n"}

if(md5_hex($text1) eq md5_hex($text2)){print "The 2 hashes are still t
+he same\n"}
else {print "BOZO ... the hashes are different\n"}
[download]

$text1 and $text2 are different but have the same hash (let's call it $hash). The hash of $text1 . $hash is still the same as the hash of $text2 . $hash.

I note that the original strings in the code above have a length of 128 - and perhaps that's critical to the existence of such a solution. I suspect that the same solution does not apply to the particular phrase that you chose for your challenge, because its length is not 128 (or a multiple thereof). But if you like to generalise your challenge a little, I reckon I could submit the above code and get a free lunch.

Cheers,
Rob

The possibility of finding two lumps of random garbage, even with equal length, has *always* been a given with any mechanism that represents a larger range of possible inputs with a smaller range of possible outputs.

With an input space of 128²⁵⁶ = 2790951116e530

And an output space of 2¹²⁸ = 3.4e38, it could not be otherwise. There have to be at least 8 inputs for every output.

Maybe you missed the emphasis I placed in my post?

The effect is to considerably increase the difficulty of finding an alternative text that matches both the outer and inner md5 and renders a useful (to the bad guy), alternative text.

To generalise my challenge in the way you suggest would be to ignore the point I was trying to make, and that ikegami partially made subsequent to his first post--

• it's one thing to brute force two texts with the same md5.
• It is an entirely different scale of problem to find a second text that has the same md5 as some existing text.
• Much harder still to generate a second text, that say's something meaningful and useful that has the same md5 as an original text (derived from a 3rd party source).
• And finally, generating a second text, that is meaningful and useful to your nefarious purpose, that satisfies the criteria of have the same md5 as the original 3rd party text when it own md5_hex digest is concatenated to it.

Each of those requirments has a multiplier effect upon the difficulty of the task at hand for the bad guy. It is this same multiplier effect that stuff like double-DES and triple-DES exploit for their greater security.

So sorry, but your gonna have to work a little for that free lunch :)

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.