Story 2014-03-22 3GR Move over MD5. Here's Blake2

Move over MD5. Here's Blake2

in security on (#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.
Reply 4 comments

I think I'll wait (Score: 3, Funny)

by on 2014-03-22 13:23 (#RH)

I think I'll wait for Blake7. It will be futuristic and revolutionary.

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

by 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).

Re: Good article spoiled by a frequently-repeated mistakes in the postscript (Score: 0)

by Anonymous Coward on 2015-09-05 16:54 (#KHM8)

Hash: SHA512

It's not! You're not suppose to use a direct hashing function for password storing, you should use a key derivation function, which is different and has a different reason to be. KDF's might (will) be based on hashing functions like SHA or maybe Blake, but they do compute them in such a way so that the resulting value requires a lot of computational work.
Nowadays, on *NIX systems, PBKDF2 is the preferred method for password storing (like /etc/shadow), and it's based on SHA-256/512.

The key derivation problem
Let us look at the key derivation problem in more detail. Again, at a high level, the problem is to
convert some discreet data that is hard to guess into an n-bit string we can use directly as a key
to some standard cryptographic primitive, such as AES. The solution in all cases will be to hash
the secret to obtain the key. We begin with some motivating examples.
• The secret might be a password. While such a password might be somewhat hard to guess, it
could be dangerous to use such a password directly as an AES key. Even if the password were
uniformly distributed over a large dictionary (already a suspect assumption), the distribution
of its encoding as a bit string is certainly not. It could very well that a significant fraction
of passwords correspond to “weak keys” for AES that make it vulnerable to attack. Recall
that AES was designed to be used with a random bit string as the key, so how it behaves on
passwords is another matter entirely." - (v0.2)

Get that last line "AES was designed to be used with a random bit string as the key, so how it behaves on
passwords is another matter entirely". With a KDF such as PBKDF2, you gain output randomization by adding a pseudorandom salt, and removes the possibility of a plain dict attack to your pwd.

"PBKDF2 applies a pseudorandom function, such as a cryptographic hash, cipher, or HMAC to the input password or passphrase along with a salt value and repeats the process many times to produce a derived key, which can then be used as a cryptographic key in subsequent operations. The added computational work makes password cracking much more difficult, and is known as key stretching." -

Also, check this out, it's well explained:

- - - - -
@hackancuba | GPG: 0xECF0573B1C9B59E8


I dunno (Score: 1)

by on 2014-03-24 11:41 (#RZ)

blake2sum just doesn't have the same ring to me, and with a sufficiently dirty mind, could suggest a double liason with a pair of blakes.