Slashdot Mirror
Did NIST Cripple SHA-3?
An anonymous reader writes "In the process of standardizing the SHA-3 competition winning algorithm Keccak, the National Institute of Standards and Technology (NIST) may have lowered the bar for attacks, which might be useful for or even initiated by NSA. 'NIST is proposing a huge reduction in the internal strength of Keccak below what went into final SHA-3 comp,' writes cryptographer Marsh Ray on Twitter. In August, John Kelsey, working at NIST, described (slides 44-48) the changes to the algorithm, including reduction of the bit length from 224, 256, 384 and 512-bit modes down to 128 and 256-bit modes."
I say we just use the algorithms Schneier has invented and nothing else. Why do we even go to these standards approvers in the first place. The open source community should get together and hold they're own competition and forget anyone who's in anyway associated with any org starting with N*. Can someone please make an open source "Scheneier Suite" of cryptography written in C for the world to make use of already please!?
-- stoops
The way I see it, I think its wise to avoid all PKI standards using Elliptic curve cryptography algoritms. In contrast to the mathematical basis of prime based algorithms, these mathematics are relatively recent - and have been pushed by the NSA (who is known to be decenia ahead of publicly known mathematics).
There is no mathematical indication for me to believe that Eleptic curve cryptography is fundamentally broken. But why use 'new mathematics' when hundreds of years of public mathematic geniusses have been thinking about fast factoring of prime numbers?
I don't get that...
The most important argument used is that key length is more manageable. One could also interprete it as an indication that there might be security bit reduction attacks still unknown to us, but known by the NSA. Possibly. Possibly not.
But why take the risk?
Some more info about elliptic-curve-cryptography:
http://www.linuxjournal.com/content/elliptic-curve-cryptography
A crippled cipher can be used to read your private data. A crippled hash function can be used to substitute bad data for good.
so why don't we just look at what organizations like the US military use to secure and sign their data, and use that? (the methods of course, not their keys) That sounds to me like the only way to make sure they're not suggesting or influencing us to use something they (or their opponents) could easily break?
I work for the Department of Redundancy Department.
When the SHA-3 competition was announced, the pretty much only working method of getting a hash function was using the Merkle-Damgård construction. Bit security limits where set under the assumption that the submitted proposals use MD, since nothing else was known. However, Keccak does not use it and gains better security guarantees. For this reason, NIST had an opportunity to weaken it a bit while still keeping the old security requirements and making the hash function much more efficient in the process.
Why didn't they think of that before asking for "224, 256, 384, and 512 bits" in the first place?
They included included Dual_EC_DRBG into a standard despite it being slow and obviously backdoored, they have no credibility to make changes to encryption algorithms any more. They have to rebuild their credibility at this point, any changes they make have to be explained, any coefficients they pick have to be shown to be free from NSA meddling, any reduction in hash length from the contest requirements ... well, they just shouldn't even try to do that at this point.
They can try to rebuild their credibility or they can become irrelevant.
Pfft. A single checkbox is all that's needed:
"Reduce effectiveness to comply with US Government standards."
When confronted with one problem, some think "I'll use recursion". Now they are confronted with one problem.
NIST's proposal (presented at last CHES conference) is NOT reducing the internal strength of Keccak.
NIST proposes some standard values for a parameter called "capacity" in Keccak, and for which Keccak's authors always said that it can be freely chosen by the designers. A high capacity means a higher security, and a lower capacity means a better performance. NIST's current forecast for FIPS202 specifies 2 values for the capacity, namely 256 and 512, that would bring the SHA-3 standard to an equivalent security level as the AES (2^128 operations required to break c=256 and 2^256 operations required to break c=512). One may actually consider that these security levels are the same as the ones in the original submission, because these are the minimum security levels offered by *ALL* finalists (including Keccak). Indeed all candidates for SHA3-256 offers a collision resistance of 2^128 operations, and 2^256 operations for SHA3-512.
The discussion here is that actually choosing c=256 means that the cost to find pre-image is also reduced to 2^128 operation, instead of 2^256 as in say SHA2-256. There are ongoing discussions on the mailing list about the theoretical consequences of this choice, but what strikes me most is why people are so much focusing on the strongest security bound of a primitive (pre-image here) and are completely ignoring the weakest security bound (collision resistance). Of course one may always design an application that would be immune to collision resistance, but if one only looks at the primitive, saying that SHA2-256 offers a security of 2^256 because it has a pre-image resistance of that level is clearly fooling himself. In that sense, NIST proposal was to level the security bound of the primitive to its guaranteed minimum as for block ciphers, and allows a security bound of either 2^128 (c=256) or 2^256 (c=512). Those with an ounce of common sense will observe that 2^128 is completely astronomical, and absolutely out of reach of any thinkable devices in the future, even for the NSA! And if you don't care about performance (you probably don't design products then), and are absolutely paranoïd, there is then still the freedom to chose a capacity c=512, as allowed in current proposal, and probably waste computer cycles for no gain whatsoever.
I of course have no clue on the possible influence of the NSA, but for having attended to SHA-3 and similar conferences, I must say that NIST's work in SHA-3 is remarkable and *unprecedented* in the cryptographic community. NIST ran the most *OPEN* process ever for the evaluation and selection of the new SHA-3 standard. I think that the intention of NIST is to write a standard that will satisfy the majority of the community (hence their openness and presentation at CHES), and that will offer the most of potential of the winner candidate. Keccak is really a "new" object in the cryptographic community, that is quite different from previous proposals, and no wonder to me that its adoption triggers some questions. However the hidden suggestion that NIST would have a secret agenda is clearly participating to current tin-foil propaganda of some would-be security specialists that are trying to acquire attention, and brings zero to the current standardization process.