Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by timothy on from the loose-ends-may-appear-under-the-microscope dept.

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."

6 of 134 comments (clear)

  1. I don't trust new, untried crypto. by SuricouRaven · · Score: 5, Funny

    Give it, oh, five more versions.

  2. links to NIST by girlinatrainingbra · · Score: 5, Interesting

    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.

    1. Re:links to NIST by Anonymous Coward · · Score: 5, Informative

      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.

    2. Re:links to NIST by marcansoft · · Score: 5, Informative

      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.

    3. Re:links to NIST by Anonymous Coward · · Score: 5, Informative

      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.

  3. Re:Missing the point by Georules · · Score: 5, Insightful

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