BLAKE2: A New Alternative To MD5 & SHA-2/SHA-3

[Licaon]

The algorithm was clearly a finalist but I don't know if blake2 is the same code as that which was in the competition.
So, as I said, it may be a reimplementation of a sha3 finalist algorithm.

https://blake2.net/blake2_20121223.pdf TL;DR "BLAKE was already more secure, we reduced some params to gain speed"

[kazetsukai]

Improved performance isn't necessarily a good thing, when it comes to these sorts of hash functions. The faster a hash function, the easier it is to brute-force.

Funny. BLAKE2 (being faster than MD5 yet more secure) seems to disprove that absolute (and utterly incorrect) correlation.

The takeaway message for us lowly non-security types was pretty simple, yet none of us got it: I'll be pretty happy when I can replace the md5sum command line tool with something faster that I can have a reasonable amount of confidence in.

[liam]

So decide already, it was either a finalist or a redesign, it can't be both.

The algorithm was clearly a finalist but I don't know if blake2 is the same code as that which was in the competition.
So, as I said, it may be a reimplementation of a sha3 finalist algorithm.

[Licaon]

The article claimed BLAKE2 was a finalist. According to this link, http://crypto.junod.info/2010/12/10/...unced-by-nist/, it was a finalist (well, BLAKE was, I'm assuming BLAKE2 is simply a different implementation.

So decide already, it was either a finalist or a redesign, it can't be both.

[elanthis]

Keccak and Sha2-256 or greater can't be brute forced.

All well said. Put in simpler terms for the simpler readers: these speedups mentioned are all linear, and while a linear improvement in hash computation is pleasantly noticeable when you're trying to compute hashes for a few hundred files while making a git commit or something like that, it is completely irrelevant when trying to search a ridiculously huge hash space. One thousandth of the time of "practically forever" is still "practically forever."

[zanny]

Improved performance isn't necessarily a good thing, when it comes to these sorts of hash functions. The faster a hash function, the easier it is to brute-force. When Intel added SHA hardware instructions, they weren't necessarily making SHA better, they were bringing it closer to obsolescence (for certain applications.)

Keccak and Sha2-256 or greater can't be brute forced. Their key spaces are within 3 orders of magnitude of the estimated number of atoms in the universe. It would take billions of years with all our available computational power to cover them. Hell, a 128 bit keyspace is currently completely impossible to brute force as well, but that is only a problem at a galactic scale rather than a universal one.

And if you really wanted to be OCD, 512 bit keyspace (or just 384) is laughably impossible to even consider brute forcing. But 256 bit is already impossible. The lowest used key space for either algorithm is 224 bits, which is just as crazy. Here is the wikipedia entry on 128 bit vs 256 bit keyspace brute forcing:

AES permits the use of 256-bit keys. Breaking a symmetric 256-bit key by brute force requires 2128 times more computational power than a 128-bit key. A device that could check a billion billion (10^18) AES keys per second (if such a device could ever be made - as of 2012, supercomputers have computing capacities of 20 Peta-FLOPS, see Titan. So 50 supercomputers would be required to process (1018) operations per second) would in theory require about 3?10^51 years to exhaust the 256-bit key space.

Keccak is already supposed to be really easy on cycles though, right? The real tradeoffs here isn't size of key storage vs execution time to have a secure key. The question isn't if you can brute force it, but if the algorithm has a vulnerability to reduce a 128 bit or 256 bit keyspace into a solvable problem.

Improved performance isn't necessarily a good thing, when it comes to these sorts of hash functions. The faster a hash function, the easier it is to brute-force. When Intel added SHA hardware instructions, they weren't necessarily making SHA better, they were bringing it closer to obsolescence (for certain applications.)

Exactly.

(I need make my message at least 10 chars long. what a stupid cms)

[liam]

So instead of using the winner of the SHA-3 competition or even one of the finalists that were under a lot of checks and scrutiny, let's take one of those finalists, redesign it and call it better? 4real?

The article claimed BLAKE2 was a finalist. According to this link, http://crypto.junod.info/2010/12/10/...unced-by-nist/, it was a finalist (well, BLAKE was, I'm assuming BLAKE2 is simply a different implementation.

[MaxToTheMax]

Improved performance isn't necessarily a good thing, when it comes to these sorts of hash functions. The faster a hash function, the easier it is to brute-force. When Intel added SHA hardware instructions, they weren't necessarily making SHA better, they were bringing it closer to obsolescence (for certain applications.)

[bug77]

I'm having problems convincing others they should use SHA2 over MD5, let alone SHA3. Bringing an exotic solution to the table would put me in an awkward position.
It's good there's research in the area, maybe this will grow into SHA4. But I don't think it's worth raving about it just yet.