BLAKE2 Claims Faster Hashing Than SHA-3, SHA-2 and MD5

hypnosec writes "BLAKE2 has been recently announced as a new alternative to the existing cryptographic hash algorithms MD5 and SHA-2/3. With applicability in cloud storage, software distribution, host-based intrusion detection, digital forensics and revision control tools, BLAKE2 performs a lot faster than the MD5 algorithm on Intel 32- and 64-bit systems. The developers of BLAKE2 insist that even though the algorithm is faster, there are no loose ends when it comes to security. BLAKE2 is an optimized version of the then SHA-3 finalist BLAKE."

Comments

ORAC

[MickyTheIdiot]

He was always good with codes...

I don't trust new, untried crypto.

[SuricouRaven]

Give it, oh, five more versions.

links to NIST

[girlinatrainingbra]

The BLAKE hash function was an also-ran finalist for the NIST Hash function competition ( http://en.wikipedia.org/wiki/NIST_hash_function_competition ). There is not yet a wikipedia page for BLAKE2, but the winner of the NIST competition was Keccak now known simply as SHA-3 since it won the competition.
.
Why would an optimized (optimized for run time speed? optimized for low memory footprint while running? optimized to minimize the likeliness of hash collisions) version of the same BLAKE entrant be more useful? Perhaps an improved algorithm that made it better competition for Keccak would make more sense. I don't know enough math to say completely, and still need to read the details.

Re:links to NIST

[Anonymous Coward]

It is optimized for runtime speed, though they also claim a slightly lower memory footprint.
The chance of hash collisions is about the same for any unbroken cryptographic hash.

Keccak has good performance in dedicated hardware, but was one of the slower SHA-3 candidates in software implementations. Compared to MD5, the best SHA-3 implementation is between 2 to 4 times slower on recent Intel processors, or 5 times slower on a recent ARM CPU.

Note that NIST has stated that any of the five SHA-3 finalists would have been an acceptable SHA-3. Keccak was selected in part due to having a very different composition than the SHA-2 family, decreasing the risk that both are broken at once. That does not mean Keccak is superior to Blake for all purposes - if software speed is the main issue, it is almost certainly worse.

Re:links to NIST

[marcansoft]

For password hashing, that is correct. However, cryptographic hash functions are not designed for such use (and yes, all the websites and services out there using plain hashes for passwords are Doing It Wrong, even if they are using a salt). You can build a good password hashing scheme out of a cryptographic hash function (for example, PBKDF2), but plain hash functions are not suitable (precisely because they are too fast).

Fast cryptographically secure hash functions are a Good Thing, so you can hash a given block of data (and thus compute its digest and e.g. verify its digital signature) as fast as possible. This speeds up things like GPG, SSL, Git*, good old sha1sum checksums, etc. If you then want to use such a hash function as the core of a password hashing scheme, you can compensate for the extra speed by simply increasing the number of iterations. Making a hash function slower is always easy.

*Git is pretty much stuck with SHA-1 for now, but future incompatible versions of the repo format could conceivably switch to a faster hash function if it made sense.

Re:links to NIST

[Anonymous Coward]

A common misconception, but untrue. Cryptographic hashes can be used for many purposes - for storing passwords, to sign documents, to verify file integrity, as a short unique identifier for content, etc.

The only of these for which slower is better, is password storing.
If you are using e.g. cryptographic hash functions with a 512-bit output, it is irrelevant for practical security that one hash function is a billion times faster than another. Either way, you will not find a collision in the lifetime of the universe without finding a weakness in the hash.

Now, this applies when we can assume that any needed keys are of good randomness. This is not the case with passwords, because human-chosen passwords have low enough entropy that they can be guessed.
However, it is very simple to make a slow hash from a fast one by using a key derivation function like PBKDF2, which iterates over the hash function a configurable number of time, often hundreds of thousands.

In short, many applications benefit from a fast hash algorithm, and none suffer, because you can always easily make a slower one.

Re:Missing the point

[Georules]

Fast hashing has its uses as well. Such as verifying data transmissions. Passwords aren't the only things that we hash.

Re:Faster?

[Anonymous Coward]

Faster hashing is better. The good guys have to pay a cost of X for hashing at b bits. The attacker has to, ideally, pay a cost of 2^b*X (well, a little less due to the Birthday paradox, but it'll still be exponential). Halving X helps the good guys, because hashing is now faster for everyone. It doesn't help the attacker because you should have chosen b to be so big that halving X makes just absolutely no difference because 2^b is so big that it's completely impractical even if X is just the time for a single cycle on a CPU.

Here's another way of looking at it: trying to impede the attacker by increasing X is the wrong idea because you ALSO have to pay for X. Instead, you want to focus on b because here your cost grows slowly with b while the attacker's cost grows exponentially with b. So smaller X is better, that is, faster hashes are better.

Re:Time

[Gaygirlie]

So use a generic hashthis() function (or class, whatever), and then you don't have to replace sha3() or blake2() or whatever through your code, merely modify the hashthis() function to use the new algorithm instead. Forward thinking amirite?

Otherwise yes, but it would make all the existing data unreadable. If you make it easy to change the hashing method like that then you will also have to always track what data was hashed with what method.