Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Encryption Government United States Your Rights Online

Did NIST Cripple SHA-3? 169

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."
This discussion has been archived. No new comments can be posted.

Did NIST Cripple SHA-3?

Comments Filter:
  • Sinister (Score:5, Informative)

    by pterry ( 100705 ) on Saturday September 28, 2013 @07:57AM (#44978291) Homepage
    A crippled cipher can be used to read your private data. A crippled hash function can be used to substitute bad data for good.
  • by pla ( 258480 ) on Saturday September 28, 2013 @08:03AM (#44978307) Journal
    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.

    Two reasons.
    1) Because having a standard means that everyone using SHA-3 will get the same result, instead of every implementation coming out with a different answer of totally unknown integrity. With a standard, I can verify the integrity of program-X's hashing simply by comparing it to a small sample of know plantexts and hash values.
    2) Because most software houses dream of someday getting a government contract - Maybe military, but don't forget about the 14% of Americans that in some way work for the government. Any software they use needs to adhere to the standards issued by the government, or no dice.

    And really, simple as that.
  • by Anonymous Coward on Saturday September 28, 2013 @08:09AM (#44978331)

    He has told me stories of NSA personnel coming by for meetings. He said he had no idea why they were there, so YYMV.

    That said, NSA had indeed been on the NIST campus.

  • by ledow ( 319597 ) on Saturday September 28, 2013 @08:10AM (#44978337) Homepage

    In case you haven't noticed, the NSA are spies. They do nothing but infiltrate groups of interest all day long.

    Such a group of OS programmers would be the perfect target. And why do we trust Schneier more than anyone else such that his involvement means something is acceptable? I love the guy, but no, that's not how trust works for mass-public security systems. If the NSA/GCHQ spies are working at anywhere near the levels they were back in their heyday of WW2, then Bruce would be my prime candidate for "beyond suspicion" and thus my first inclination that - somewhere, somehow - he could be a shill for them. I'm not seriously saying he is or isn't, but the point of security is that NOBODY should hold any special power over anyone else, certainly not the ability to single-handedly "approve" a worldwide security standard.

    No, what we do is carry on as normal. Put all the algorithms to public testing. As attacks are found, knock out the vulnerable ones like a game of Guess Who, and only ever use whatever is still standing. You can't defend against attacks that you do not know about and if such agencies really ARE as worried as we think they might be about the world moving to encryption they can't break, then my first thought would be "what are they moving us towards, without trying to look like they are doing so?" - and there you run into Blowfish/Twofish and similar algorithms that they've had the opportunity to analyse for years now. It would be the perfect coup - make people think you are attacking them, then "be involved" with the only alternative of elliptic-curves and thus make everyone think that's your preference and hence subtly move them onto something else of your choice without even MENTIONING it or being involved with it.

    Don't try to out-think a bunch of geniuses working with military-level funding and a real interest in keeping you on something broken. Just follow procedure - stay on what you've got until there's actual evidence it's broken. Don't jump ship to new and interesting and relatively untested things for no reason other than you feel uncomfortable.

  • by fatphil ( 181876 ) on Saturday September 28, 2013 @08:42AM (#44978429) Homepage
    Discrete logarithms are spelt "division" in elliptic curves. They're just as mathematically pure and well studied as finite fields and prime product rings.
  • by fuujuhi ( 2088482 ) on Saturday September 28, 2013 @01:44PM (#44980021)

    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.

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Working...