I think SHA-2 should be "minor weakness discovered" (if not outright "unbroken"), not "weakened".<p>At the onset of the SHA-3 competition, everyone was nervous about SHA-2: it appeared as though a good attack was inevitable, what with the cryptanalytic attacks on SHA-1.<p>But as the competition went on, things got calmer. The attacks against SHA-2 that were so expected simply weren't coming[1]. And so now the status quo is that SHA-2 seems pretty darn safe, and the real focus of the SHA-3 competition shifted towards not necessarily having a direct replacement for SHA-2, in the sense of performance, but instead having a design that was sufficiently different to not allow SHA-2 attacks to apply to it. And Keccak is just that: quite different.<p>Anyway, my point is that SHA-2 is mislabeled. Honestly, I think cryptographers recommend it the most out of any of the hash functions currently; SHA-3's software performance is rather... lacking.<p>[1] Some may argue that this is because cryptographers were focused on the SHA-3 candidates, but I'm not so sure
If the SHA-2 family have weaknesses, and SHA-2 is used for generating Bitcoin blocks, whoever breaks this first will be an overnight millionaire, just make sure you break them slowly (about 20 a day max) to avoid suspicion that the hashing is compromised. Sell as much as possible and then release your paper.
Use of SHA-1 for digital signature generation has been deprecated by NIST since 2011. It's disallowed after 2013-- which is important for software aiming for government use.<p><a href="http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf" rel="nofollow">http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-13...</a>
>[1] Note that 128-bit hashes are at best 2^64 complexity to break; using a 128-bit hash is irresponsible based on sheer digest length.<p>Can a short hash which has not been weakened be lengthened by taking two hashes and concatenating?<p><pre><code> fixedSalt = "blah"
longerHash = (salt, input) ->
hash(salt + input) + hash(salt + fixedSalt + input)
</code></pre>
Edit: Never mind. Obviously an attacker would only have to break the first half of the resulting hash.<p>But is there any valid way to lengthen a too-short hash? Not that it's of practical importance; I'm just curious academically.
For more information on the 'weakened' state of SHA-2, see <a href="http://eprint.iacr.org/2004/207" rel="nofollow">http://eprint.iacr.org/2004/207</a><p>(Full text PDF: <a href="http://eprint.iacr.org/2004/207.pdf" rel="nofollow">http://eprint.iacr.org/2004/207.pdf</a>)
It'd be nice to have whirlpool in the list - I remember when it was seen as the great new hope for a good hash, but I haven't heard anything about it in recent years.
It's missing the most important ones: Scrypt, PBKDF2, Bcrypt.<p><a href="https://en.wikipedia.org/wiki/Scrypt" rel="nofollow">https://en.wikipedia.org/wiki/Scrypt</a><p><a href="https://en.wikipedia.org/wiki/Bcrypt" rel="nofollow">https://en.wikipedia.org/wiki/Bcrypt</a><p><a href="https://en.wikipedia.org/wiki/PBKDF2" rel="nofollow">https://en.wikipedia.org/wiki/PBKDF2</a><p>Scrypt being an absolute nightmare to bruteforce, even for short passwords.<p><a href="http://i.stack.imgur.com/sOMvu.png" rel="nofollow">http://i.stack.imgur.com/sOMvu.png</a>