I made a PHP script that will let you sort all the available hashes on your system by generation time or by the length of the hash. It shows a general correlation on my system (longer hashes take longer to calculate) but some are faster than others, for example, sha512 makes the (joint) longest hash, but is actually only ninth slowest (from 43 hashes available on my machine)
As I understand it, the strength of a hash is dependant on the number of collisions that it has (where two input values produce the same hash) so with an infinite number of input values but a finite number of hashes, there are a (theoretically) infinite number of collisions. But, if you have a longer hash, then you're dividing infinity by a larger number, so you'll have fewer collisions.
In reality the number of collisions will be limited by the minimum and maximum password lengths that you choose to allow, so that if you enforce a policy where passwords must be exactly a certain length (20 characters for example) you'll have a large number of unique passwords, but a smaller number of potential inputs than you have hashes coming out, so that should prevent collisions entirely. In theory.
Tl;dr: I think that longer hashes are better.
Anyway, here's the code:
<?php
$data = "hello";
foreach (hash_algos() as $v)
{
$time=microtime(1);
for ($i = 0; $i < 10000; $i++)
{
$r[$v] = strlen(hash($v, $data.$i, false));
}
$t[$v] = microtime(1)-$time;
}
switch ($_GET['sort'])
{
default:
ksort ($r);
$array = 'r';
break;
case 'length':
asort ($r);
$array = 'r';
break;
case 'time':
asort ($t);
$array = 't';
break;
}
echo '<pre> <a href="?sort=alph">Name</a> | <a href="?sort=length">Hash Length</a> | <a href="?sort=time">Time taken for 10000 hashes.</a>'."\n";
foreach ($$array as $key => $value)
{
echo $key;
for ($i = strlen ($key); $i <= 19; $i++)
{
echo ' ';
}
echo '| '.$r[$key];
for ($i = strlen ($r[$key]); $i <= 11; $i++)
{
echo ' ';
}
echo '| '.$t[$key]."\n";
}
echo '</pre>';
?>
