Forgot your password?
typodupeerror
Encryption Security

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

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • ORAC (Score:5, Funny)

    by MickyTheIdiot (1032226) on Tuesday December 25, 2012 @02:24PM (#42388901) Homepage Journal

    He was always good with codes...

  • by SuricouRaven (1897204) on Tuesday December 25, 2012 @02:24PM (#42388903)

    Give it, oh, five more versions.

    • So, you want to wait until the version string the tool reports is at least 1.0.5?

      Done!

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      He's waiting for Blake's 7.

      http://en.wikipedia.org/wiki/Blake%27s_7

  • links to NIST (Score:5, Interesting)

    by girlinatrainingbra (2738457) on Tuesday December 25, 2012 @02:26PM (#42388913)
    The BLAKE [wikipedia.org] hash function was an also-ran finalist for the NIST Hash function competition ( http://en.wikipedia.org/wiki/NIST_hash_function_competition [wikipedia.org] ). 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 [wikipedia.org].
    .
    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: (Score:3, Insightful)

      by Nexion (1064)

      Yeah... I was under the impression that more hashes faster was a bad thing. That is something for which crackers tune their code, but they didn't explicitly mention password storage. Perhaps it is targeted more for checksum like usage.

      • Re: (Score:2, Informative)

        by nazsco (695026)

        Time to encode is not always related to time to decode. So it would benefit dictionary attacks only,

        • by Anonymous Coward

          If you can decode a hash, your hash is very very broken.

        • Re: (Score:2, Informative)

          by Anonymous Coward

          There is no "decode" - breaking hashes is done by brute force (or by using dictionaries + modifiers).

        • by Anonymous Coward

          >> Time to encode is not always related to time to decode.
          What do you mean with "decode" ?

          >> they didn't explicitly mention password storage
          a very fast hash is bad for password storage. Password storage needs very slow hashes. generic hashing of a lot of data needs fast hashes.

          • by Anonymous Coward

            A fast cryptographically secure hash function is always nice to have, for example, deduplication in a filesystem. You want it to be as difficult as possible to create a hash collision, while not needlessly wasting time and CPU cycles.

            For authentication, you'll of course be adding a salt and as much recursion as necessary to ensure brute force attacks aren't feasable. Nobody is going to depend on the hashing function alone.

            • by sqlrob (173498)

              No, nobody SHOULD depend on the hashing function alone.

              There's a big difference between "shouldn't" and "doesn't"

      • That also means you can hash more often in the same time, it cancels out. I'm not a crypto expert or even non-doofus, but basically you keep inreasing the number of iterations as processing power increases, e.g. calibrate it to take at least N seconds once a year. Which has nothing to do with the algorithm used really; I just like to throw dangerous half-knowledge out there to see what happens haha.

      • Re:links to NIST (Score:5, Informative)

        by marcansoft (727665) <hector@mar c a nsoft.com> on Tuesday December 25, 2012 @03:25PM (#42389439) Homepage

        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.

        • I need some good crypto advice.

          I happen to be at the point in writing a P2P application framework where I need to select a hash function for authenticating messages. Of course, I'll make it selectable in the future, but I need to choose a default hash. I was about to settle on SHA-2. However, I'm not happy with the performance of SHA-2 and SHA-3 compared to SHA-1, and frankly I need MD5 speed. Blake2p sounds like it fits the bill. I've downloaded the code and it seem simple enough to include in my proj

          • by Jorl17 (1716772)
            Why not Ask Slashdot?
          • First of all, you mention the TCP/IP checkum, at the same time as key exchanges, long PSKs, and money transfer. Which is it, simple message integrity or message authentication? If you need authentication, you shouldn't even be mentioning TCP/IP checksums. If all you need is integrity, then just append an MD5.

            Assuming you need authentication: I don't have any opinion on Blake2, but you should use an HMAC instead of just appending the shared secret key and taking the hash. HMAC can be built on top of any hash

          • Follow this simple rule: don't invent your own crypto. And that goes double for protocols. It's hard. I mean, really, really hard to get it right. If you are not an expert, then there are almost certainly known attacks which will undermine the security of your entire system. If you are an expert, there are still probably subtle attacks (but fewer of them which may not be discovered for years).

            I understand most standard modern crypto and protocols quite well. I have studied and worked with it long enoug

            • Not to mention liability issues: using standards and getting exploited anyways is much different than trying to roll your own and being the only one vulnerable to the attack ... "the buck stops ... hopefully somewhere else".

      • Don't confuse a hash with a key derivation function. A hash is just a cryptographic primitive, you shouldn't use it directly (like you don't use block ciphers directly). It should be fast, and if you need it to be slower, you can iterate its output through itself and slow it artificially.

        A MAC like HMAC uses a hash, but it accepts a secret key as a parameter and it does some stuff to prevent so-called length-extension attacks (whereby given Hash(x) you can determine very quickly Hash(Concat(x, y)) for some

      • by Anonymous Coward

        You obviously have never used full disk encryption, ZFS, etc.

        Faster hashes will be _very_ welcome!!!!

      • Fast hashes are bad for passwords. Slow hashes are bad for data integrity checking, message authentication codes, and other such things. They are similar constructs, but used for very different purposes.

        If you want to verify your 1TB video collection got transmitted properly you want a fast hash to keep it from taking a long time. That same hash would be totally unsuitable for password hashing.
    • Re: (Score:3, Funny)

      by Zero__Kelvin (151819)
      Yes. I hate optimized versions of things. Why does everyone think it's better just because they made it better?
    • Re:links to NIST (Score:5, Informative)

      by Anonymous Coward on Tuesday December 25, 2012 @03:01PM (#42389227)

      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.

    • NIST's comments on their selection of Keccak to be SHA-3: [nist.gov] (PDF)

      Additionally, KECCAK complements the existing SHA-2 family of hash algorithms well. NIST remains confident in the security of SHA-2 which is now widely implemented, and the SHA-2 hash algorithms will continue to be used for the foreseeable future, as indicated in the NIST hash policy statement. One benefit that KECCAK offers as the SHA-3 winner is its difference in design and implementation properties from that of SHA-2. It seems very unlikely that a single new cryptanalytic attack or approach could threaten both algorithms. Similarly, the very different implementation properties of the two algorithms will allow future application and protocol designers greater flexibility in finding one of the two hash algorithms that fits well with their requirements.

      So, Keccak wasn't necessarily chosen because it was "superior" to the other finalists (note that it's slow when implemented in software, especially in comparison to the other finalists), but because it was different enough that, should SHA-2 be found to be fundamentally broken, SHA-3 should remain unaffected.

      An optimized version of BLAKE would be useful because it can run faster than SHA-3 in software, while also being (theoretically) stronger t

    • by aysa (452184)

      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?

      BLAKE2 is an improved version of the SHA-3 finalist BLAKE. Like BLAKE or SHA-3, BLAKE2 offers the highest security, yet is fast as MD5 on 64-bit platforms and requires at least 33% less RAM than SHA-2 or SHA-3 on low-end systems. I can find applications in cloud storage, software distribution, host-based intrusion detection, digital forensics, revision control and embedded systems https://blake2.net/blake2_20121223.pdf [blake2.net]

  • by Anonymous Coward

    If security is important to you, don't use it until its been around for a few years at least. Boy was it annoying replacing all the md5 usages in various codebases... and that's been around for more than "a few years."

    • 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?

      • Re:Time (Score:5, Informative)

        by Gaygirlie (1657131) <gaygirlie@hot m a i l.com> on Tuesday December 25, 2012 @03:24PM (#42389429) Homepage

        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.

        • Which is exactly what /etc/shadow does, and it's been around for a long time. These are all solved problems if anyone would pay attention.

          • Which is exactly what /etc/shadow does, and it's been around for a long time. These are all solved problems if anyone would pay attention.

            No one was talking about unix passwords here. Data can be almost anything that needs to be hashed and it may be stored in SQL - databases, random text files, proprietary binary files and so on. In other words your referral to /etc/shadow is irrelevant.

            • People were talking about storing the hash algorithm with the hash (and implying it was a bad thing, or too much to ask for a simple programmer), which is what /etc/shadow does (which they did back before we had as much power and space as we do now.) The fact that /etc/shadow is storing passwords is, as you said, irrelevant. It stores info about the hash with the hash so that later you know what hash to use to verify.

            • by aliquis (678370)

              Because it's so hard to store hash,MD5 or hash,SHA3 or whatever in two fields in a database.

        • You have to do that anyway...

          For passwords, I'd assume (but probably be wrong...) that you'd convert the password to the new hash either when the user signs in next, or when the user changes their password next, but you still have to be able to check against the old hash, so you'd always need to know what type of hash that is. Seems to me that the best place to store that is in a field in the database right next to the hash itself.

          One would assume that hashthis() would be implemented to either be aware of

        • I almost said something like that, along with the solution, but figured people could figure it out on their own.

          With password hashes, the type of hash tends to be part of the end result (e.g. $B$ indicates a hash of type B, while $A$ indicates a hash of type A; not real examples, 'cause I can't be bothered looking them up). You could easily do something similar with generic hashes.

          zippthorne (in a sibling to this post) gave some other thoughts.

        • by mysidia (191772)

          There is a common method of doing this, by inserting a "HASH TYPE" header in front of a password. RFC2307

          SHA256 CRYPT() with 10000 rounds - {SHA256-CRYPT}$5$rounds=100000$hK.9TGSGMfuVhMY1$ukBEvc3eTCJNgiK.BIsNIWmq9JU3D8tMapmqwJB6ip0

          Cleartext password - {plain}password {clear}password
          Traditional Unix crypt - {crypt}FHrLg6eHMx2nA
          Unsalted MD5 - {md5}
          Salted MD5 - {smd5}p47J0UeLzLY+/Lk7q0ohOnMJTGI=
          Unix MD5 Crypt - {md5-crypt}$1$QgAqzRlm$Wo69omVJhJHZR2aOKJ4qs1
          Unsalted SHA - {sha1}...
          Unsalted SH

  • Missing the point (Score:1, Interesting)

    by Anonymous Coward

    There are 3 aspects that are important to the security of hashing algorithms.

    1) one-directional. You cannot get back to the original from the hash.
    2) unique-ness. Fewer different sources with hash to the same result.
    3) takes time to make. The quicker it is to create the hash, the quicker it is to brute-force your way through all possible combinations to find a hash that matches.

    Most password cracking happens by getting a list of hashed password values through some other securitu exploit, and running as many

    • by Georules (655379) on Tuesday December 25, 2012 @03:13PM (#42389333)
      Fast hashing has its uses as well. Such as verifying data transmissions. Passwords aren't the only things that we hash.
    • by pipatron (966506)

      3) takes time to make. The quicker it is to create the hash, the quicker it is to brute-force your way through all possible combinations to find a hash that matches.

      Most password cracking happens by getting a list of hashed password values through some other securitu exploit, and running as many hashes as you can as quickly as you can to find match. If they're claiming a fast hash is a good thing, they're missing the point.

      Bullshit. You don't bruteforce a 512 bit hash, no matter how fast it is. It simply doesn't work like that. You must find a weakness in the algorithm to break even much smaller hashes.

      • by OneAhead (1495535)
        No weakness required, simply the ability to make educated guesses about the data being hashed. As in brute forcing password hashes [wikipedia.org]. Granted, hash functions are used for a host of other applications, but password hashes happen to be pretty high-profile, and most definitely have a requirement that they shouldn't be too fast. You can call GP's claim 3) not generally true, but to call it bullshit is, well, bullshit.
    • Re:Missing the point (Score:4, Informative)

      by magic maverick (2615475) on Tuesday December 25, 2012 @03:18PM (#42389381) Homepage Journal

      Nah, you are. Hashes are used for a lot more than just passwords. Yes, for passwords a fast generic hash function like SHA2 or SHA3 (let alone MD5) is not such a good option. But for verifying that a downloaded executable or other file has not been modified, it's mostly fine. But don't use MD5, because it's completely broken (e.g. with it being possible to have two distinct PDF files having the same hash).

      For password hashing use Blowfish/Bcrypt [codahale.com].

      • by Immerman (2627577)

        Just to clarify - it's not the duplicate hashes that are the problem. Hash collisions should *always* be considered inevitable since the number of possible pdfs (or whatever) will exceed the number of possible hash values by many, many orders of magnitude unless the hash size is as large as the original file. The problem is that it's possible to *intentionally* cause a hash collision - for example by appending some "garbage" data to a compromised executable to make it appear to as though it's the original.

        • by Pseudonym (62607)

          Hash collisions should *always* be considered inevitable since the number of possible pdfs (or whatever) will exceed the number of possible hash values by many, many orders of magnitude unless the hash size is as large as the original file.

          The number of possible PDFs is larger, but the number of actual PDFs is lower. Much lower.

          A very reliable rule of thumb is that if there are N possible hash values, then you should expect 0.5 hash collisions after hashing N items. (Exercise: Prove this. You want to consi

          • by WillerZ (814133)

            A very reliable rule of thumb is that if there are N possible hash values, then you should expect 0.5 hash collisions after hashing N items.

            No you shouldn't. You should expect 0.5 collisions after hashing N/2 items. Trivially you are guaranteed at least M collisions when hashing N+M items.

            I don't actually know off the top of my head how many collisions you should expect if you hashed N items.

            • by Pseudonym (62607)

              Slashdot screwed up my comment. Please see this correction [slashdot.org].

            • by Pseudonym (62607)

              By the way, to answer your question: If there are N hash values and you hash N items, you should expect N(1-2/e) collisions. The proof of this is also left as an exercise.

            • by DrVxD (184537)

              I don't actually know off the top of my head how many collisions you should expect if you hashed N items.

              One of the characteristics of a good cryptographic hash is that it has a uniform distribution in the hash space - so really, you have a generalisation of the birthday paradox [wikipedia.org]; the section there on 'Collision Counting' gives the expected number of collisions as
              n - d + d ( ( d -1 ) / d ) ^ n
              (where d is the number of possible hash values, and n is the number of items).

              Since we're hashing N items, with N outcomes, then we can substitute d==N, n==N
              N - N + N ( ( N - 1 ) / N ) ^ N
              and simplify a little:
              N ( ( N - 1

          • by Immerman (2627577)

            Okay, I can only assume that that's a typo - if you have N possible hash values and have hashed N items then you almost certainly already have many, many collisions, and are guaranteed a collision on the (N+1)th hash by the pigeonhole principle.

            Consider that a good hash function will bear many similarities to a random number generator and you'll see that it's a variant of the birthday problem - you don't need 180 people in a room to get a 0.5 chance of two people having the same birthday, only something lik

            • by Pseudonym (62607)

              Okay, I can only assume that that's a typo

              What I wrote was &radic;N, but Slashdot in its wisdom cut off the square root sign.

              If there are N possible hash values, you should expect 0.5 collisions after hashing sqrt(N) items.

          • by fnj (64210)

            Are you sure you don't mean "you need around 2^511 PDF files"?

            2^256 is not anywhere near half of 2^512.

        • Well yes. Good point that I should have made, it is the intentional aspect that is most worrisome. You take a PDF file, take the hash, and then can easily generate another PDF file with the same hash. Which apparently could be used for fraud. Or, take an executable and then generate a malicious one with the same hash and trick someone into downloading it instead of the correct one. I should have expanded on that point in my original post.

      • by fnj (64210)

        Good and fast hashes are all you need for any purpose. You can't make a slow hash fast, but it's trivially easy to make a fast hash slow. You just use sequential rounds [archlinux.org], enough of them to make it slow.

        SHA-512 is fine for passwords. It's the best there is. You're nuts to use anything else, the US military agrees with me, and it is the default in RHEL6 and other recent security conscious distros. The thing is, nobody with any sense uses a single round for this purpose. They use 5000, or 50,000, or 719,246. Wh

    • by Agent ME (1411269)

      Taking time is only important if your input data is small and you don't want someone guessing the input data and verifying it against the hash.

      If you want a hashing algorithm to take time, it's not that hard: just run it X times.

    • by Desler (1608317)

      Hashes are used for far more than storing passwords securely.

    • 3) takes time to make. The quicker it is to create the hash, the quicker it is to brute-force your way through all possible combinations to find a hash that matches.

      I wouldn't say that. The hash itself should be as quick as possible, so long as it satisfies the other requirements. We have things like PBKDF2 when we want a hash to eat up a lot of CPU, and scrypt when we want to eat up lots of RAM as well.

    • You forgot : changing a little bit the input should ideally produce a totally different output ( ie, good cascading effect, if I am not wrong on the property ).

  • by Anonymous Coward

    I know I’m already too late for a few, but fast hashing is good. The only thing you want a slow hash for is a PBKDF—and, to be honest, that is and should be an entirely different construct to a hash, although you can make PBKDFs out of cryptographic hashes.

    I’m still not seeing anything that makes this better than Skein, however, which is very fast in software, can perform signature pinned and keyed hashes and rounds (which could be used to make a PBKDF of arbitary strength), and even has a

    • > the NSA value hardware speed far more than software speed

      I don't think this is true for NIST though. Witness the results of the SHA competition. Keccak sucks in hardware compared to Skein. Skein is lovely to implement in hardware. Ultimately the sponge construction is what won it.

      They certainly ignored my advice on hardware implementation.

  • by TechyImmigrant (175943) on Tuesday December 25, 2012 @05:49PM (#42390245) Journal

    The software speed of the SHA algorithms is somewhat moot in the medium terms because over the medium term, crypto primitives (encryption, hashing, RNGs etc) are moving to hardware and moving to an instruction model instead of a device+device_driver model.

    So the hardware implementations available to software through instructions will be faster than software implementations and have much better security properties in terms of attack surface and side channels. Modern crypto tends to fall to side channels and implementation error before it falls to crypto attacks and hardware is the best place to solve these problems.

    At the recent NIST RBG Workshop http://www.nist.gov/itl/csd/ct/rbg_workshop2012.cfm [nist.gov]
    I presented a short talk on where Intel is going. http://csrc.nist.gov/groups/ST/rbg_workshop_2012/johnston.pdf [nist.gov]

    Basically, we've started putting standards based crypto primitives in hardware, on the CPU die, presented through the instruction interface (E.G. AES-NI, RdRand, RdSeed) to provide for more secure crypto on PCs. This is our publicly stated intent going forward. So who cares how many cycles it takes when there's a constant time instruction available that is faster?

  • Faster also means faster to attack. Also, there is absolutely no need for faster crypto-hashes at this time, the available ones are quite fast enough.

  • It occurs to me that, under certain circumstances, encryption might be unnecessary. An eavesdropper expected encrypted text might be skeptical of brazenly published open text. Hiding in plain sight, so to speak.
  • What about simplicity and performance for hardware implementations? Or is this meant as a software hash? TFA only gives software runtimes.

Things equal to nothing else are equal to each other.

Working...