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.
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."
Version 2 was code named Jenna.
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 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.
It depends on what hashing function is used or. For passwords, yeah, that kind of function is good. But that's not the only use for hash function. If you need to know if files X and Y in different systems are identical, you want that checksum pretty fast. If you are transmitting data at 10Gbit/s and want to make sure it's going without problems, you are going to need something very fast. But you most likely want to make sure it's still slow enough that it cannot be bruteforced on the wire.
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.
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.
Faster is good for plenty of applications of hashes such as checksums on data.
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.
> [Fastest Encryption] Is this: source_byte_to_encrypt XOR some_random_byte.
No it isn't. The complex part is the generation of 'some_random_byte'. Check out SP800-90A,B & C. Those are not efficient algorithms.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
The birthday paradox only lets you find a collision faster, not crack a specific password faster.
If you have a good b-bit hash function, then the expected cost of "undoing" a specific hash is X*2^(b-1), but the expected cost of finding half a collision (the birthday paradox scenario) is X*2^(b/2).
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
According to wikipedia's page on the NISH-sponsored competition - @
http://en.wikipedia.org/wiki/NIST_hash_function_competition
- one of the criteria of the elimination of potential candidates was ...
Security: "We preferred to be conservative about security, and in some cases did not select algorithms with exceptional performance, largely because something about them made us 'nervous,' even though we knew of no clear attack against the full algorithm."
Would the clause above invalidate Blake2??
Muchas Gracias, Señor Edward Snowden !
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.
Wow how scientific of them |:-|
"When information is power, privacy is freedom" - Jah-Wren Ryel
What about simplicity and performance for hardware implementations? Or is this meant as a software hash? TFA only gives software runtimes.