NIST Selects Winner of Secure Hash Algorithm (SHA-3) Competition

Keccak's structure is simple and markedly different from that of MD4, MD5, SHA1, and the SHA-2 family, all of which share a common design pattern called Merkle-Damgard (MD). MD-style hashes chunk their inputs into blocks and tag the last block with a length; they then run in a manner similar to a block cipher, where each block is combined with the previous block after the hash function core is applied. The resulting output of these MD-style hashes is literally the internal state of the hash at the last block; you can take most SHA-2 hashes, for instance, and "feed them back" to the SHA function with more data to generate a continued hash. This gives rise to a common crypto protocol flaw called a "length extension attack".

Unlike MD, Keccak uses a design called a "sponge function". It's called a "Sponge" because it splits hash into two distinct stages: one in which the hash function "absorbs" data, applying the hash core function to permute an internal state, and another in which the hash is "squeezed" to produce output (which further permutes the state). Somewhat like a cryptographic PRNG, the security of the hash function is delegated to the confidentiality of the internal state, which isn't disclosed by producing the hash.

Furthermore, Keccak's Sponge design derives security by only allowing inputs to directly influence a subset of the internal state bits. Like MD hashes, the inputs are chunked into blocks and fed to the hash algorithm. But each block fed to the hash affects only that block's worth of internal state bits; the remainder of the hash's state (called the "capacity bits") are mixed in with the "outer" bits during the application of the hash core. Here's a picture that may tell the story better:

http://tinyurl.com/cryptosponge

Notice how the "M" bits of the input hit only the "r" bits of "outer" state in the hash, while the "c" bits of "capacity" are used only during the "f" function.

"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."

http://csrc.nist.gov/groups/ST/hash/sha-3/Round3/documents/E... [PDF]

Going by the eBASH benchmarks, software implementations of Keccak are mostly the same speed as SHA-2, and for some CPUs it's significantly slower.

It does have better throughput/area ratio in hardware, but chip manufacturers are not early adapters.

With that in mind I can't see any major push for general SHA-3 adoption unless the SHA-2 family is broken.

Still, I'm looking forward to the reading the report.

I am not saying this isn't good stuff, but as someone struggling to implement a user login properly it would be much nicer to have a template to follow. (and he waits for someone to point to the template ...)