[cdavidcash]

If all it does is prevent length extension attacks, then there are much simpler and less risky ways to do that (i.e., MD variants).

Also, your explanation of the sponge structure omits the real difference between it and MD: It is a transform that turns a non-compressing function (f in that diagram) into a compressing function. MD, on the other hand, starts with a fixed-input-size compressing function and extends its domain.

By the way, what do you mean by "Furthermore, Keccak's Sponge design derives security by only allowing inputs to directly influence a subset of the internal state bits."? That's as true for an MD-type construction as it is for a sponge construction. In fact, it's a crucial fact that allows us to build a reduction from, say, the collision-resistance of MD[f] to the collision-resistance of f.

[tptacek]

Regarding the bits exposed to inputs in Keccak, I read the claim in the same manner as the claim that CTR is more side-channel resistant because attacker ciphertext bits never hit the AES core; here further margin is given by the additional capacity bits. That's my attempt at exposition from the Sponge paper. You would know far better than I would, though; I'm a tester, not a cryptographer.

Regarding length extension, strong disagree; we see the SHA functions routinely abused this way.

[dchest]

BLAKE and Skein inject a message block by first running it through the block cipher (as key in BLAKE, as plaintext in Skein), and then XORing the result with the message block to get a new state. JH XORs message block into one half of the state before permutation, and into the other half after it. Keccak XORs message block into a part of state before permutation, and that's it.