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.

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

by spallshurgenson@pipedot.org 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 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).

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

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

-----BEGIN PGP SIGNED MESSAGE-----
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.

"8.9.1
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." - http://toc.cryptobook.us/ (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." - https://en.wikipedia.org/wiki/PBKDF2

Also, check this out, it's well explained: https://crackstation.net/hashing-security.htm

Cheers!
- - - - -
@hackancuba | GPG: 0xECF0573B1C9B59E8
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJV6x3/AAoJEGc3+qtqoUirnDUP/09Z/YMH3rET+guAmHFZ4kes
3KEWsOZBGg1b03sGq8sDVG1eLTc9mhKhphGkHGFGVmCI7a9uvXvCd7O7gJZ3kvJ8
O2AQV9Un2tmZNv6K5HbFavDsHQfp5P3ZhRLCgIrSNtdQra4am/YCWbNi8UD7np08
8BxzHVo4QPAWHVolE3Twl6jMsTw+SsJtZbfAH4Qg16CL21u9BdHuH6V+Kz1PLf2J
PsZ2RbauzD6EfKdhYLZevXdQ2Z3ddFsq+q/SZPGf+lL9KSRPYnYFSJCBnk0QS8gQ
Bl/2gMzPY07s31B5IrqIohSdW52r6MqPxYU6sNd5vyPQ02kj0NkOSB/sCy4mUF2R
VR5VOtI6QP6U24HL95Bo1RZ+rWExprjjPvLzuVaDlznEgWLmKL3yRNiP5MvYD3G6
FbDpL6VexdWf7WYF5cb/nBIyxtXe0eYU4Fg08kxfRkrzrE8oxKqg5DBg+/h1qVLH
ngFwYBP2HV7ym5czxdKgS0ltyYpx8gocd8FHQf0oYHa7YiMQCgWgtsn6PnprblcJ
zd/Ev75l06RCJ3v7nr2cgCvJ2hIx3DG0HXzAwyjWeeo96xlVWMOXLKIppGpBoOWT
hQTLGlRxm0RXT+uFSH4h5JUznr9XHlB8nOzimLToY98KX3Sa5SWkAcKGpA9lGiGR
ECYHubwQMdc1YXwSJQn6
=cVb+
-----END PGP SIGNATURE-----

I dunno (Score: 1)

by insulatedkiwi@pipedot.org 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.