Slashdot Mirror
SHA-3 Winner Announced
An anonymous reader writes "The National Institute of Standards and Technology (NIST) has just announced the winner of the SHA-3 competition: Keccak, created by Guido Bertoni, Joan Daemen and Gilles Van Assche of STMicroelectronics and Michaël Peeters of NXP Semiconductors. 'Keccak has the added advantage of not being vulnerable in the same ways SHA-2 might be,' says NIST computer security expert Tim Polk. 'An attack that could work on SHA-2 most likely would not work on Keccak because the two algorithms are designed so differently.' For Joan Daemen it must be a 'two in a row' feeling, since he also is one of the authors of AES."
It's time to start building some new rainbow tables?
What makes you extrapolate from "It's safe against the most likely issues SHA-2 might have" to "We chose it because of that but for the rest didn't bother to study it at all?" You surely are not a cryptographer, given that you can't even spell the word.
Praise from an AC on Slashdot? Yeah, they're certainly going to be printing that out and framing it for posterity.
Criticism from an AC on Slashdot? Yeah, I'm certainly going to be printing that out and framing it for posterity.
Sarcasm from an AC on Slashdot? Yeah, I'm certainly going to be printing that out and framing it for posterity.
Having a good SHA algorithm is a good thing. Yes, hash collisions may not seem to be something that can happen often, but if there is a chance that one can make a document saying "hell no" be changed to "yes, definitely", that can bankrupt a company.
Hashes also have other uses, especially as "bit blenders", so if one is able to figure out a way to decrease entropy, then keys generated from a device like /dev/random can be significantly less secure.
Each crypto algorithm is important. I just wish NIST would not just pick one candidate, but perhaps 2-3 at a time [1]. The reason for this is that if something happened that made the algorithm insecure, the standard libraries would have a backup. It also means that embedded controllers that are made to the standard wouldn't have to be chucked and replaced should one algorithm be cracked.
[1]: Not just hashing, but encryption as well. I wish NIST went wish not just Rijndael, but Serpent and Twofish for a standard. Similar with not just going with just RSA, but RSA, Merkel, DSA, ElGamel, and elliptic encryption. That way, should an attack like TWIRL or quantum computers make RSA pointless, people can switch over to Merkel or another algorithm without needing a hardware upgrade. Plus, for high security work, multiple algorithms can be cascaded [2] to ensure that one weak link won't compromise everything.
[2]: No, three 256-bit algorithms will not get you 768 bits. In reality, you end up with 258 bits of security. However, if one of the algos ends up being broken and only offering 32 bits of unique keys, the other two would continue to keep at least 256 bits of keylength.
I think my account has been hacked.
You can post as me, but I'm not printing out ANYTHING. Fuck you guys.
This wouldn't have happened if slashdot would have been using SHA-3.
It makes it somewhat more impressive when the vulnerabilities of SHA-2 are not known yet.
What?
That is a strange criteria though, as 99.9% of the people using SHA3 and depending on it's security will use a software implementation. Practically the only people who deal with hardware implementations anymore are those trying to break a cryptosystem. Of course all the speed measures for the SHA-3 contenders (hw and sw implementation) are relatively small constant multiples/divisors of SHA2, so it really isn't a big deal from a security or convenience factor.
Looking forward to reading the final report.
Security is only one of the factors. Speed is one of the big reasons AES was chosen IIRC.
I just wish NIST would not just pick one candidate, but perhaps 2-3 at a time [1]. The reason for this is that if something happened that made the algorithm insecure, the standard libraries would have a backup. It also means that embedded controllers that are made to the standard wouldn't have to be chucked and replaced should one algorithm be cracked.
As with anything, be careful what you wish for. I've seen successful attacks on protocols that support multiple versions or algorithms, made possible by devices that support them all for various compatibility reasons. Let's suppose someone does discover an attack on SHA-3A but SHA-3B remains secure. Everybody switches their servers to SHA-3B. A flexible protocol might allow an attacker to generate an error that forces clients to re-hash their passwords with SHA-3A. This has happened more often than you might think; NTLMv2 implementations falling back to NTLM being one of the more spectacular of the exemplary failures.
Your example creates a theoretical weakness - a failure in either SHA-3A or SHA-3B could put such a device at risk. If you try to prevent this by building in an environmental protocol switch, so the device could be set in the future as to which algorithm to use, why not initially design the device to support loading a more modern algorithm in the future?
John
you're trying (poorly) to troll, but for those who actually are curious, no, you should not do anything of the sort. you should use a proper password hashing framework which makes use of hash functions actually intended for use with authentication systems, such as phpass.
In fact it should be a given that SHA-X does not suffer from the same vulnerabilities as SHA-X-1.
No, it shouldn't. Both SHA-1 and SHA-2 are based on the Merkle–Damgard construction. If there's something really wrong with it (not that there's any reason to believe so, today), both SHA-1 and SHA-2 would be affected.
Keccak (SHA-3) has a completely different design based on the sponge construction.
The same companies that are vulnerable to SQL injection exploits because they don't even have pen testing as part of their development cycle.
I think he's targeting major corporations.
Change is certain; progress is not obligatory.
Did you even READ the article you're quoting? Merkle-Damgard is known to have many undesirable properties. They're even mentioned in that same WIkipedia article...
And yet, NIST has no plans to phase-out of SHA-2, because SHA-2 is fine. There's a reason I wrote "If there's something really wrong with it": as far as we know, there's nothing really wrong with it. Cryptographic algorithms are all about trade-offs, and SHA-2 is certainly not perfect, but the same is true of almost everything else we use.
When Scheier said "we don't need SHA-3" last week, he was lambasted by the remaining cryptographic community for ignoring exacly that.
Don't be silly. If that was true, people would be recommending moving away from SHA-2, and nobody is saying that.
I've seen successful attacks on protocols that support multiple versions or algorithms, made possible by devices that support them all for various compatibility reasons.
And I've seen attack ships on fire off the shoulder of Orion and watched C-beams glitter in the dark near the Tannhauser gate.
So there!