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
durr.
NIST fooled us once (Dual_EC_DRBG), but to fool us twice, that would be a shame on 'us'. (us = everyone who is not NIST and NSA)
Kick them to the touch I say, time for a replacement.
Encryption algorithms are created by security forces. Most data in the U.S.A is manipulated to serve government propaganda of success. Just look at unemployment, inflation etc, methods of calculations to see how it changed in the last 20-30 years.
Pathetic.
Really needs to be read to the tune of The Who for maximal irony.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.
and gave a master key to the CIA/FBI/NSA and all the other three letter goons & spooks that are part of the US Govt, and now the blowback for such a breach of trust is nobody trusts the US Govt anymore, i am sure MS_Windows will take a big hit in sales because of this (since it is closed source) at least BSD & Linux can have its code audited and i bet other nations are scrambling to do just that for their systems that they want to keep secured,
i wonder how much data and info the US Govt spys steal to give to their fascist cronies on wallstreet (I bet it was a hell of a lot)
Politics is Treachery, Religion is Brainwashing
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.
If NIST see a need to weaken sha3 for (presumably) kleptographic purposes, should we not assume 512 bit keccak to be secure?
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.
Try working on real software. I'm not talking about some shitty web app written in Perl. I'm talking about real software, used by corporations, academia and government. The kind of software that these organizations will pay top dollar to use.
Say you find the need to integrate encryption into such a system. You go to your manager and suggest Blowfish. Since he's an MBA with a finance background, and hasn't heard Blowfish mentioned in any webcasts he's watched, he say, "What the fuck is a blowfish?"
You'll try to explain it to him. You'll start talking about Bruce Schneier and the NSA and he'll say, "Fuck, son, you've been listening to too much Hootie and the Blowfish."
Then he'll tell you to the get the hell out of his office with your "hippy" ideas. He can't bring them to his boss, who can't bring them to his boss. He needs standards recognized by official bodies. He doesn't need your "open source crap".
In the real word, what you're proposing just doesn't fly, son.
Because if your software does not comply with FIPS or whatever other standard of the day is in effect, the government can not purchase it. When hundreds of millions (sometimes billions) of dollars in revenue are on the line, people will make a lot of concessions.
The guy calls himself cryptographer, but he doesn't know what he's talking about.
Hashes, and also any ideal random oracles, have only (n/2) security due to so called birthday paradox limit.
That's why SHA-512 has only 256-bit security. This is not weakening of the hash in any form. It is a property of any hash or RNG.
What the slides show is that they want to reduce clutter in reducing dozen options into two options. One high-security (256-bit security) and another fast, medium-security.
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.
You're cute when you're wrong.
That's not the real world you're talking about. That's just deluded kiddie troll dreams.
Developers should implement Keccak, and NIST and NSA can have their SHA-3, whatever it becomes, all to themselves.
Signature intentionally left blank.
There are lots of allegations but no proof that NSA is actually weakening the primitives they are contributing to. NSA provided the s-boxes for DES and nobody knew why they chose the ones they did. Then Biham and Shamir published their work on differential cryptanalysis and it turned out those s-boxes were ideally resistant. That was when the NSA said "yep, we knew about differential cryptanalysis but we couldn't tell you that we chose those s-boxes to resist it until it was discovered by the open crypto world."
So, until I see some proof that NSA is now actually crippling crypto standards instead of strengthening them I'll remain skeptical.
Reading the slides, sounds like they just eliminated some middle capacities that had equivalent strength. They did this by saying if you want 384 bits of output, just run the 512 bit version and truncate the result. This means that they made the 384 more secure, not less.
Slide 48 says SHA3 standard are the two 512 and 256 bits long capacity. On the previous slide the explain that a 512 bit hash has 256 bits of security. This is because all hashes have an upper limit on theire security strenth which is n/2 bits (where n is length of output) of security due the birthday attack. The other tweaks to the padding and other aspects do deserve skepticism, but the original posts is just confusing bits of security with bits of output. They did not reduce the security of the output sizes.
Does the author actually know anything about cryptography? When the slides make reference to 128-bit and 256-bit, they are talking about *strength*, not number of bits. A 512-bit hash produces something with 256 bits of strength. In addition, let's keep in mind that the NSA has zero interest in making crypto weaker. Their interest (speaking of the SIGINT people, not the IAD people) would be in backdoors that allow them, and only them, to decrypt something while nobody else can. Nothing to see here, move along.
It unfortunately is a very real world that the GP describes, and the one where the most money is to be made when writing software. Somebody like yourself, who has only ever used PHP or Ruby on Rails to make web sites for independent hair salons and wedding photographers, just wouldn't understand how it works. Standards are king, and anyone who doesn't use standards has no chance. It isn't about whether or not Blowfish has technological merit, but instead it's a lot more about politics.
This complaint is based on not understanding the slides. NIST changed size 224, 256, 384, and 512 to sizes 256 and 512. The 128/256 slides are about an internal component, so this entire misunderstanding is based on comparing different things.
See here, for example.
http://bristolcrypto.blogspot.com/2013/08/ches-invited-talk-future-of-sha-3.html
What do you think Crypt:CBC is implemented in? Perl? Hahaha. No. It's C you idiot.
No, Crypt::CBC is implemented in Perl. The crypto algorithms you'd typically use with it (not that CBC mode is necessarily the best choice) are generally implemented in Perl.
The actual NIST Proposal strengthens SHA-3 relative to the authors' most performant proposal (http://eprint.iacr.org/2013/231.pdf section 6.1) by rounding *UP* the capacity of the sponge construction to 256 bits for both SHA3-224 and SHA3-256, and rounding *UP* to 512 bits for both SHA3-384 and SHA3-512 (matching the proposal in section 6.2). This thread is the result of a careless misreading, ignorance or both.
http://crypto.stackexchange.com/questions/10008/why-restricting-sha3-to-have-only-two-possible-capacities
The real truth in the slides is that the algorithms are expected to have a collision and pre-image resistance that is 1 half the digest size. In this case the 128 and 256 numbers mean that the collision resistance is 2^128 and 2^256.
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.
What, you haven' heard about DJB's curve25519 http://cr.yp.to/ecdh.html ?? Nothing to do with NSA or NIST, and there's already even an implementation by Google.
From TFS: "NIST is proposing a huge reduction in the internal strength of Keccak below what went into final SHA-3 comp"
The word "proposed" means something here.
Back doors are built into an implementation, not a standard.
-- I ignore anonymous replies to my comments and postings.
Here's what I'd suggest - set up your own numbers station. Then they'll never find out who you were communicating with, and if you incinerate each one time pad immediately upon use they'll never figure out what you sent either. Of course, you'll have to keep on the move .....
are you serious?
Of course the manager does not know Blowfish, Twofish, AES ... you just tell him: We now use a more secure algorithm, and he goes "good, this will protect our customers. Continue to have such good ideas, please!"
Unless you know what you're doing and have a very good reason to use the modules under the Crypt namespace directly, you should generally be using Crypt::CBC with them, at least for most common purposes.
The actual Blowfish cryptography core of Crypt::Blowfish is written in C. You can verify this by downloading the tarball and looking at the source. There is a pure Perl version available as well, but it's slower.
The cores of Crypt::DES, Crypt::Rijndael, etc are also written in C.
Write failed: Broken pipe
You're failing to grasp the context and you won't understand this either but I know someone who will and this is for them. No one with a clue gives a shit about what you're describing, it is utterly irrelevant and “we” are more than happy to let such people as you continue jumping into the grinder as many times as they want to. Nobody can stop you.
What “we” do want is to avoid being forced to jump into that grinder ourselves for the rest of time.
That is what the war for the future is about. That is the context.
In addition to Alef's comment
That Guardian article where he teaches everyone, including terrorists, how to avoid the NSA, undoing 10 years of infiltration work:
http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
Also, he's been helping anti-surveillance campaigns including NO2ID for years.
Doesn't anyone here remember all that footage from planes in Bosnia that was sent unencrypted and downloaded by people with slightly tweaked satellite TV gear? Some stuff isn't even encoded at all.
Time to switch to open standards instead of this NIST bullshit.
We should not have one SHA-3 with the security parameters selected by NIST or anyone else.
For the vast majority of usages the speed of the hashing is a non-issue, they are all plenty fast enough
yet some implementations, specifically those with limited hardware my have other concerns.
We should approve the basic algorithm, and have a family of hash functions with different security parameters
to be selected for each usage.
Most of us should use an extra secure variant most of the time.
Why not just use cascades? You can use AES in combination with Twofish or Serpent. I suspect you can combine hashing algorithms also depending on the circumstance. TrueCrypt already uses cascades I'd like to see it in OpenSSL. The real problem is with implementation. Implementations are more likely to back-doored then algorithms. Look at SSL for example. There should be focus on eliminating CAs and replacing them with a web of trust. Web of trust is implemented in PGP/OpenPGP.
I probably shouldn't be replying to a troll, but what the hell, this one is just too hard to pass up. Thousands of companies around the world, including many of your favorite Fortune 500s, use Perl for tasks ranging from mission critical systems programming, to application integration, to enterprise reporting and sure, web applications. You must be living a pretty sheltered life; if you truly work in an enterprise environment, have you bothered taking a look at what powers your company recently? Hint: there's an awful lot of Perl (and Python, too) driving it, probably in places you don't even know exist in your infrastructure.
Son, I've been doing this professionally for fifteen years. Have a nice day!
Write failed: Broken pipe
Leaving aside what I'll take as a typo of Linus as Linux, Linus has since stated it was a joke. PJ, meanwhile, was responding the climate of fear and the impossibility of anything being done online even having a hope of being truly private, so not any sort of deliberate pressure per se, just unable to live with How Things Are and choosing instead to retreat from them. I wish she hadn't, but that's her call.
I honestly don't even know who Phil Zimmerman is, so I'll just assume you're right on that one, although your track record isn't great ;)
I remember sigs. Oh, a simpler time!
Please read the comments from the authors regarding Sha-3 http://keccak.noekeon.org/yes_this_is_keccak.html