Which is the most secure hashing algorithm?

From OP's comment:

"Secure" as in, based on a mathematical problem that has no known fast solution. "Most secure" as in, based on the most complex of such problems. A hashing algorithm is considered "strong" when breaking it would require a major contribution to cryptology/mathematics. It sounds as if you have been reading Thomas Ptacek's "Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes", and now you're wondering which modern cryptographic hash optimised for password storage is considered 'the most secure'. I don't think there is a clear-cut answer to get the most secure hashing algorithm. As far as I know, some of the current favourites in the programming community (scrypt & bcrypt) haven't been rigorously peer-reviewed as password hashing functions. At least, they have not been peer-reviewed by a large number of cryptographers comparable to how the NIST hash function competition entries are vetted.

That said, the current Hacker News consensus is that the order is:

scrypt. Because it is both memory-intensive and CPU-intensive, scrypt is thought to have the highest safety margin of current password hashes. You can see more about its design here. bcrypt was the previous champion, as mentioned in Thomas Ptacek's blog post above.PBKDF2 and multiple rounds of SHA2 (fx Unix Crypt with SHA256) are thought to be third-best (which one of these is 'best' depends largely on the number of iterations used). (Note that "Hacker News" is mostly a programming community, and not as the name might imply to some a security specialist community (even though some of those hang out there too).) If you look around on this site, under the cryptography passwords and hashing tags fx, then you will see that there usually isn't a single 'best' password hash mentioned. I guess that's in part because the real cryptographers have no clear-cut consensus on which one is 'strongest', due to the relatively limited peer-reviewing.Here is a fairly even-handed and easily read comparison (which doesn't include scrypt, presumably because it's still too new). Speed is irrelevant because I'm iterating the hash over a fixed time (rather than a fixed number of iterations). With some of these hashes, you can't really do that. You supply a "work factor" when you call the library, and the library takes care of the rest.