Slashdot Mirror
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."
He was always good with codes...
Give it, oh, five more versions.
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.
Fast hashing has its uses as well. Such as verifying data transmissions. Passwords aren't the only things that we hash.
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.
HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
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.
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.
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 built-in tree hash function, and parallelises well. Skein’s still my favourite SHA-3 finalist by far, and I’m going to be using it in production instead of SHA-3—given FIPS won’t be driving SHA-3 adoption in short order, we won’t get hardware support for some time, and the NSA value hardware speed far more than software speed (as they mostly work with hardware CSMs). Further, I am not entirely convinced the round function underneath the sponge construction is necessarily different enough to survive an attack that would weaken AES.
Keccak’s way, way too slow given Skein and BLAKE are faster and of comparable security (although BLAKE was the second least favourite of my picks), and I suspect that SHA-3 will face slow adoption: there’s nothing obviously wrong with SHA-2, and absolutely no reason to move from SHA-256 to something significantly slower than SHA-256 when other hashes of comparable security exist which have received a similar amount of cryptographic attention and run faster. Keccak’s a poor sell.
As for PBKDFs, perhaps we need to hold another contest entirely for them, although it is also getting to the point that by the time we’d finish such a competition, passwords which the average person can remember have too little entropy to survive even brute force on any practical PBKDF you’d want to run (bearing in mind that if it runs too slow it represents a potential point of DoS), and no asymmetric PBKDF can exist that resists offline attacks.
It might also be worthwhile to hold a contest to define a tweakable block cipher and define more modes based on that, and perhaps that would be an interesting way forward.
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.
Generally you're right.
However, for passwords specifically, you'll need longer plaintext passwords for this to work. It doesn't matter how many bits your hash function is at, if the average password is only 8 characters of Alphanumeric (which, unfortunately, has entropy much less than 64 bits...). Salts help against things like rainbow attacks, but it won't help if an attacker is trying to crack one specific account that is protected by a 8 character password -- in that case, the speed of the hash function is the only variable in the cracking effort.
We all know we should have longer plaintext passwords, but the fact is -- our puny brains cannot remember random characters that well.
And passphrases haven't really caught on, unfortunately.
Don't quote me on this.
That's why there are dedicated hash functions for password hashing like bcrypt and scrypt that should be used for this. One should never use generic cryptographic hash function for storage of passwords directly. Being slow was never considered as a goal in design of cryptographic hash functions, they are intended to be practical replacements for random oracles. They could, however, be used as a building blocks for PBKDF that might be appropriate for password storage.
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
I presented a short talk on where Intel is going. http://csrc.nist.gov/groups/ST/rbg_workshop_2012/johnston.pdf
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?
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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 like 20-30 (I don't remember exactly), and the effect scales sub-linearly. Logarithmically if I remember correctly. So yes, a good hundreds-of-bits hash function will generate values that can safely be considered rare, just NOT unique. And even events with billions-to-one against odds happen all the time in the real world, just not in a predictable fashion.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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, 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. When you configure your password security on linux to SHA-512, glibc defaults to 5000 rounds.