A US government agency has selected cryptographic hash function Keccak as the new official SHA-3 algorithm. The National Institute of Standards and Technology's decision to pick the nippy system as the replacement for SHA-1 and SHA-2 marks the end of a six-year competitive process. Five algorithms were left in the running at the …
"A US government agency has selected cryptographic hash function Keccak as the new official SHA-3 algorithm."
Read as, "We have developed a back door entry system allowing near instantaneous decryption of the SHA-3 algorithm."
Official US approval of an encryption scheme is never a good thing.
It's a hash function. You don't decrypt those. If you want to break it you need to find another message with the same hash value. Seriously, there is a difference.
NIST != NSA
Paranoid delusions aside.
> Official US approval of an encryption scheme is never a good thing.
It's a balance of terror for the spooks of all nations: of course they would love to be able to crack everyone else's comms but equally they want their own comms to remain secure, and they cannot count upon their crypto skills being a whole generation ahead of the rivals. So it would be perilous to adopt as a national standard something with a known weakness, lest some ingenious Israeli, clever-clogs Chinese, or resourceful Russian identifies it too. And as far as I know none of the US standards have been fingered as having exploitable weakness - for many years the NSA alteration to DES was thought to be such a case but in fact what they did was to strengthen it - see http://news.cnet.com/Saluting-the-data-encryption-legacy/2010-1029_3-5381232.html
Of course what does work is weakening a system that you don't use yourself - e.g. the long-standing suspicion that the NSA trojanned Crypto AG machines: widely used for diplomatic comms but apparently not by USA.
Re: > Official US approval of an encryption scheme is never a good thing.
" for many years the NSA alteration to DES was thought to be such a case but in fact what they did was to strengthen it - "
They then proceeded to claim the 56 bit key (developed to run on 1970s technology) was *still* secure 20 yrs later until the EFF *built* hardware to demonstrate a brute force crack was viable.
I wrote the first paper within a company that used a DES variant warning this its security must be viewed as suspect.
Note that it is an *algorithm* that has been approved, not an implementation. A black box software implementation could have *any* number of trapdoors built into, just like *any* closed source piece of software.
Now lets start...
building rainbow tables for SHA-3 values, if only there were real world examples of lists of actual passwords chosen by real people, oh wait, there's loads of those.
Roll on SHA-4?
Re: Now lets start...
Er, the real problem is not the hash function, it is one or both of these:
1) User choosing short simple passwords (i.e. low entropy), maybe not helped by system with dumb limits like 8 characters max.
2) Users of said hash not salting (1) with sufficient entropy so the input to the hash function is big enough that a matching rainbow table is practical to compute.
Really, going from a 256-bit hash output to 512-bits only doubles your rainbow table size, but going from 20 bits in to just 28 bits input, for example, makes the table 256 times bigger!
> from which it is hopefully impossible to recover the original information.
No, that's totally not the point of a hash function. The aim is that you cannot trivially compute a fake data payload which matches the hash. I can assure you that you cannot recover an arbitrary payload from a N-bit hash because N-bits is usually order of magnitudes smaller than the payload ...
Thanks for the kick up the arse - that was our fault for trying to oversimplify a complex subject to keep things light and non-boring. I've tweaked the article.
You're welcome ;) Technically you were right - it's a valid use case for storing passwords in a database - in that case the irreversibly is a useful property, but it missed the other use cases (signing) in which case the user already has the "plain text".
missing info in the article
One of the SHA-3 creators (Daemen) also worked on AES....
Re: missing info in the article
One of the SHA-3 creators (Daemen) also worked on AES
More specifically, Joan Daemen was co-author of Rijndael, which became AES. So that's both of the two most recent major NIST crypto-algorithm contests his teams have won. Good show.
Of course his coauthors also deserve their fair share of the credit, as do the many researchers working in the field; it's not like Daemen is a lone genius inventing this stuff sui generis. You could argue that, while he does fine work, in the end he just got lucky twice - a small difference of opinion on either NIST committee could have changed the final result in either case. But it's a fine achievement nonetheless.
Different is good... because...
We can now, in situations where speed isn't important, compute both SHA-2 and SHA-3 and use both. If they are different, the combined strength of both algorithms is at least as good as the weakest. If they are similar, someone might find a way to break both at the same time.
- Product round-up Ten excellent FREE PC apps to brighten your Windows
- Review Tough Banana Pi: a Raspberry Pi for colour-blind diehards
- Product round-up Ten Mac freeware apps for your new Apple baby
- Analysis Pity the poor Windows developer: The tools for desktop development are in disarray
- Chromecast video on UK, Euro TVs hertz so badly it makes us judder – but Google 'won't fix'