I have studied PBKDF2 for the application of hashing passwords, and frankly I don't understand the justification for the complexity of PBKDF2 over iterative hashing with a cryptographic hash function.
Here is an example: (obviously if you want a longer/shorter hash, choose a longer/shorter digest)
|| - concatenation operator let password be a user supplied byte sequence let salt be a random byte sequence supplied by the runtime let iteration_count be a positive integer in the millions Algorithm: iteration = SHA256( salt || password ) for ( 2 to iteration_count ) iteration = SHA256( iteration ) let hash = final value of iteration // Store hash, salt and iteration_count
As long as the iterations are tuned to take a target amount of CPU for the security policy, for what purpose justifies using a more complex routine than that?
On my computer with Java, it takes approximately 2 million iterations to fill about 1 second of CPU time to generate the hash.
The biggest advantage to me with this design is, next year when the computer is running faster, I can update my entire user table statically, stretching the iteration count a little further. In fact, if I had a huge operation and performance was going to be a problem, I could run a constant depth extension of the hashes, to wit:
update table USERS set ITERATION_COUNT++, set hash = SHA256( hash )
Besides simply telling me not to roll my own, can some experienced experts please convince me why this security design is poorer than the venerated PBKDF2? Thank you very much in advance. I am eager to learn something new here.