Are NIST's changes to Keccak/SHA-3 problematic? NIST is working on standardizing SHA-3.  They have selected Keccak as the basis for SHA-3, and they plan to make some small changes to it; the result (with NIST's changes) will be standardized as SHA-3.

A blog post from the CDT raises concerns over those changes.  Two specific concerns were mentioned:


The security level is "reduced": instead of offering 224-bit, 256-bit, 384-bit, and 512-bit versions of the hash (as found in the Keccak submission), the SHA-3 standard will only offer 128-bit and 256-bit versions.
Some of the internals of the algorithm have been tweaked by NIST.


My question: Are these criticisms of SHA-3 valid?  Are they something to worry about?

(To be clear: in the two points above, I'm just repeating what the blog post said.  I'm not trying to claim that those two criticisms are valid -- indeed, whether they are fair criticisms or not is exactly what I want to know.)

NIST gives the rationale for these changes in their presentation at CHES 2013.

I wonder if the first criticism might be a misunderstanding; is it an accurate statement of NIST's plans?  (See also Why restricting SHA3 to have only two possible capacities?.)  The second criticism might be more interesting.  Is there any technical merit to the second criticism?  Is there any reason to distrust the plans for SHA-3, or to suspect shenanigans?  Are these changes to Keccak more likely to make it more secure, or less secure?
I do worry, but not for the resistance of SHA-3; I worry for its acceptance.

Technically, what NIST wants to do is sound. They do want to somehow "break" a traditional rule, which is that a hash function with an output of n bits ought to resist collisions with strength 2n/2, and preimages (first and second) with strength 2n. Instead, NIST wants harmonized security levels at 2n/2. Indeed, 128-bit resistance to preimages are more than enough for most practical purposes. On the NIST mailing-list for the SHA-3 competition, John Daemen himself has recently (this morning) argued that the proposed modification on SHA-3 will not only retain 128-bit protection against preimages, but it will even ensure 128-bit protection against multi-target preimages, i.e. something better than what a "classic" hash function with a 128-bit output would offer.

The upside of "harmonizing" the security levels is that it is done, in the case of Keccak, by lowering the internal "capacity", and this increases performance (software performance is a sore point of Keccak in general, in that it is not really faster than SHA-2).

Acceptance, however, is something else altogether. In many cases (unfortunately, in most cases), decision to use or not use a specific algorithm in a given system will be taken by people with a, let's say, less acute grasp of cryptography than the crowd of cryptographers. Most don't imagine that there is a difference between collisions and preimages. What happens on their heads is not something like "mmh, NIST made a trade-off between academical security and performance, but a sound one, approved by other cryptographers, so that's good". Rather, it goes along the lines of "OMG they changed the algorithm now it's all backdoored !". And they finally decide to use a custom scheme, e.g. a XOR of MD4 with MurmurHash, or anything else equally dumb.

In my experience, systems which use cryptography don't get broken because of a well-informed trade-off between performance. They get broken because a good algorithm was misused, or simply not used, because someone got paranoid and/or creative, and used a custom weak scheme instead.

One of the reasons why AES was widely adopted is that Rijndael was unchanged. NIST did not change the slightest bit in the whole algorithm; they just took it as is, i.e. as it was specified by the non-American inventors and also as it was analysed by all the other non-American cryptographers during the competition.

If NIST wants the widest possible acceptance of SHA-3, then they should keep Keccak unchanged from its "third round" specification. And by "unchanged" I mean "really unchanged". This is not just about the internal "capacity", but also the padding and all the other bits.

Acceptance at all costs is not necessarily a worthy goal; maybe NIST considers that having a technically good and fast (or not too slow) algorithm is more important than catering to the crowd of ill-informed paranoid managers who make dumb technical decisions. But at least it is a question worth asking.