Move over MD5. Here's Blake2

in security on 2014-03-22 11:06 (#3GR)

There's more than one way to compute a secure hash, from MD5 to SHA-3 to SHA-1 and beyond. So who cares about yet another: Blake2?

There are a couple of reasons you might be interested in checking out Blake2: It was rated best hash function in the SHA-3 competition, is faster than MD5, and cryptographers find that it's similar to the well-regarded SHA-2 algorithm in ways that matter.

Says developer Zooko Wilcox-O'Hearn:

Jean-Philippe Aumasson, Samuel Neves, Christian Winnerlein, and I decided that what the world needed was not just a secure hash function that was faster than Keccak, but one that was faster than MD5! This is because MD5 (and SHA-1) continue to be very widely used, even in new applications, even though MD5 and SHA-1 are unsafe for many uses. We hypothesized that offering engineers a hash function that was both faster and more secure than their beloved MD5 or SHA-1 might be more effective than haranguing them to upgrade to an alternative that is more secure but slower.

Have a look for yourself at Wilcox-O'Hearn's page.

Good article spoiled by a frequently-repeated mistakes in the postscript (Score: 2, Interesting)

by fnj@pipedot.org on 2014-03-23 06:37 (#RP)

From TFA: "P.S. Secure hash functions are not for hashing passwords! Secure hash functions are building blocks in cryptographic protocols and they should be as efficient as possible while still being secure. Password-hashing functions are for impeding brute force guessing of passwords, and they should be as inefficient as possible while still being usable."

This is complete and utter BULLSHIT. Anybody who does not use SHA512 for a *NIX login password by now is a fool. Ask DOD if you don't believe me. It's the default in RHEL6, FreeBSD10 and many other modern security-conscious distros. Nobody runs just a single round of SHA512 for passwords. As the very next paragraph in TFA admits, you can make any algorithm as bloody slow as you want by running a large number of rounds. The default in glibc is 5000. You can turn up the number of rounds for passwords in PAM, up to at least 999,999,999 if you don't mind everybody logging in having to wait and load a CPU to 100% for minutes for the password to be verified (and making sure any attacker would take millenia to brute force a single password).