Slashdot Mirror
Ask Slashdot: Can We Still Trust FIPS?
First time accepted submitter someSnarkyBastard writes "It has already been widely reported that the NSA has subverted several major encryption standards but I have not seen any mention of how this affects the FIPS 140-2 standard. Can we still trust these cyphers? They have been cleared for use by the US Government for Top-Secret clearance documents; surely the government wouldn't backdoor itself right?...Right?"
Depends who runs the Government. Which is always the same people no matter who gets voted in, so the answer is YES.
How could anyone trust an encryption algorithm provided by an organization whose purpose is decryption and interception? That will always be the craziest part.
http://www.nsa.gov/ia/programs/suiteb_cryptography/
AES with 128-bit keys provides adequate protection for classified information up to the SECRET level. Similarly, ECDH and ECDSA using the 256-bit prime modulus elliptic curve as specified in FIPS PUB 186-3 and SHA-256 provide adequate protection for classified information up to the SECRET level. Until the conclusion of the transition period defined in CNSSP-15, DH, DSA and RSA can be used with a 2048-bit modulus to protect classified information up to the SECRET level.
AES with 256-bit keys, Elliptic Curve Public Key Cryptography using the 384-bit prime modulus elliptic curve as specified in FIPS PUB 186-3 and SHA-384 are required to protect classified information at the TOP SECRET level. Since some products approved to protect classified information up to the TOP SECRET level will only contain algorithms with these parameters, algorithm interoperability between various products can only be guaranteed by having these parameters as options.
NSA also defined another algorithm suite, Suite A, which contains both classified and unclassified algorithms. Suite A will be used in applications where Suite B may not be appropriate. Both Suite A and Suite B can be used to protect foreign releasable information, US-Only information, and Sensitive Compartmented Information (SCI).
No, and you never actually should have trusted it. None of us did, we all stopped using it the moment the NSA advocated it, just like we stopped trusting every single crypto standard and favorite security tool they promoted, merely because they promoted it so suspiciously, long long before it was public knowledge the agency had gone rouge.
It still makes me chuckle when I hear people worryingly speculate whether SELinux has backdoors. SELinux doesn't have backdoors, SELinux IS A BACK DOOR!!! *Actually read the instructions* for configuration of this tool and you'll see what I mean. Its security-through-obscurity at its worst. At best you can increase the illusion of security to untrained staff members. Anyone who has read the manual though knows there's one command anyone can use to gain root access more easily than if SELinux had not enabled or installed.
Trust was assumed on the basis that the NSA would not unreasonably jeopardise its protection mission by furthering its interception mission. This trust was apparently misplaced: it has.
As you will actually see if you look at the documents, the NSA used the NIST analysis process under FIPS 140-2 certification to find ways to secretly attack and subvert the implementation of submitted cryptographic modules, including standalone modules, cards, hardware tokens, and software cryptographic modules, including both closed-source and open-source software. There are indications that suggestions relayed by NIST from the NSA to "strengthen" such modules may not always have been made in good faith in recent years. Subtle RSA padding mode attacks and random number generators were particular areas chosen to backdoor. Look out for them.
In particular, note that DSA and ECDSA require strong random numbers for every single signature - they are critically weak if the numbers are repeated, and weak if predictable. It may be worth exploring what subtle effects a weaker random number generator might have. The cynic may suggest that those signature schemes were chosen by NSA precisely because of their reliance on strong random numbers for every signature - not all signature schemes have this requirement (RSA does not, neither does Ed25519).
The NSA has definitely suggested weak and backdoored standards, such as MQV (formerly in Suite B) and Dual_EC_DRBG; its personnel, originally via Certicom, were responsible for suggesting the SECP/NIST elliptic curve groups. It is notable that the "verifiably random" curves in fact do NOT have verifiably random seeds - there are no nothing-up-my-sleeve numbers, it seems that the seeds were chosen after a search of some kind. We do not know the criteria of that search, and they may be weak to an obscure, little-known attack, or they may be strong to it. They strengthened DES, but their priorities seem to have shifted since then.
Other elliptic curves, such as Ed25519, have been produced by individuals in the public academic crypto sphere, and as such their origins have been subject to more scrutiny. Schneier suggests (as he always has) that elliptic-curve crypto is still too new to trust - particularly given that the NSA did much of the initial research and it now seems that their integrity cannot be trusted as far as you can throw them, that seems well-founded. RSA is still good for now, but perhaps we should move above 2048 bits soon, to 3072 or 4096.
For hash functions, the prudent may wish to choose Skein, one of the SHA-3 finalists, rather than the NSA/NIST-blessed Keccak. Its software performance is almost twice as fast and it seems more traditionally-designed. One wonders why the NSA chose Keccak. Perhaps their stated reason (that the sponge construction is the most unlike SHA-2) is truthful, perhaps it is a lie. We don't know.
For symmetric crypto, AES-128 is still good and no powerful attacks are known. Maybe the round count is a little lower than we'd like long-term. AES-256 doesn't buy us any more security, in truth, due to a meet-in-the-middle attack - it needs more rounds. TWOFISH-256 might do better, but it's hard to cast a crystal ball into the future...
For the other 99% of us that aren't encryption specialists, a list of what software, services, and websites use which encryption method and whether or not it's known to be broken/back doored might be more helpful. I'm even a software programmer and I don't know what uses FIPS and what uses AES and what specifically uses the Dual_EC_DRBG algorithm.
FIPS is a financial and government-facing certification. FIPS guarantees correct implementation of cryptographic protocols according to a set of standards. It does not guarantee that there are no undiscovered (or backdoored) weaknesses in your implementation. This is still useful function to entities that require this certification. Corporate liability and loss due to getting hacked because of incorrect cryptographic implementation is orders of magnitude greater than liability and loss due to getting exposed NSA backdoors. It is all about risk management, and it says FIPS is still good idea.
Now, if you want personal security this equation changes a bit - possibility of personal harm due to hypothetical NSA backdoors goes slightly up and your likelihood of getting targeted to get pwned goes drastically down. FIPS is still likely net benefit, but diminished.
Keep in mind that there is no such thing as perfect security. You have to ask, how likely that this specific implementation was backdoored by NSA and what the worst possible outcome of such occurrence?
"Up to Top Secret" does not include Sensitive Compartmented Information (SCI). The ciphers under discussion, backdoored or not, are not suitable for use on SCI.
No matter how good your encryption it still can be easily decrypted with a rubber hose.
The FIPS 140-2 standard is for "protecting sensitive but unclassified information". It is not for top secret. Also the body of the FIPS 140-2 standard is algorithm agnostic. The part that mandates specific algorithms is Annex A and can be updated to add and remove algorithms without changing the standard.
In terms of how bad the situation actually is.... I refer to Bruce:
The math is good, but math has no agency. Code has agency, and the code has been subverted.
For example, they strengthened DES against differential cryptanalysis when they were the only ones who knew about the technique.
I think we've reached peak encryption. No matter what you come up with, the NSA has more than enough resources to crack your encryption method. And if you're using one-time pads, they or their retinue will just crack one of the holders of the one-time pads. Crack, like the holder's skull, knuckles or testicles.
So we need to dump the idea that encryption can be used to transmit our secrets. And come up with entirely new ideas.
A radical thought? Hell, yeah. Do I myself have any ideas how to do this? Hell, no. And even if I did, I wouldn't dare to talk about it. The first person to publish an idea on this will be taken by the government on a ride with Hans Reiser.
But I think that we're stuck in a rut with encryption. We've been using it for so long, we can't even broaden our horizons to even consider other ways to get secret information from one place to another, without it getting snooped on. At the very least, the message should self destruct if someone tries to snoop on it. As to the rest . . . by my guest, and let your imagination run wild . . .
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
>>Rolling your own crypto won't work well.
What if Joan Daemen and Vincent Rijmen kept AES to themselves, wouldn't that work for them and still be considered "roll your own"?
Still, I think that FOSS works best for encryption; many eyes make for shallow backdoors... erhm what was the saying again?
It is one of the reasons I dont really trust bloated distros like ubuntu. Too much code to inspect. (but I might be wrong;-)
rm -rf --no-preserve-root /
ASCII stands for "American Standard Code for Information Interchange". Since this is an American standard, then the whole encoding scheme probably contains a backdoor that allows the NSA to read all information encoded in it. We can't trust EBDIC either as IBM is a contractor for the NSA, they would insert a backdoor as well. I think for maximum online privacy we should be using Unicode which shouldn't contain an NSA backdoor because it is an international standard. The American government has no interest in following or creating international standards.
Unfortunately Slashdot does not support Unicode, so one should now safely assume that Slashdot is an NSA honeypot .
I have no doubt that FIPS 140-2 is fully available to the NSA. The official story is probably so they can monitor or prevent espionage. Also the NSA has political interests in terms of knowing what it's opponents within the government are doing. If the NSA had adequte supervision this wouldn't be allowed but they don't have adequte supervision. So there you are.
Minus physical assault, it's getting to be the only way to transport anything securely.
Quo usque tandem abutere, Nimbus, patientia nostra?
As someone who writes cryptography software (I'm not a cryptologist, I just implement known algorithms, and verify they produce was I'm told they should produce), the solution for us is to provide software with multiple algorithms and let the user pick. Our core library supports DES, Blowfish, Twofish, and two separate implementations of AES, one of which is from outside the US. We also support a handful of lesser known algorithms, such as variants of the different Russian GOST standards.
Unless everyone is collaborating, some part of the software is secure. I don't think Russia, the USA, Germany ... and Bruce Schiener are all in cahoots with each other. Maybe one or two of them, but not all of them.
I don't know that, but thats my theory.
Slashvertisement: http://www.rtsz.com/products/cryptolock/
Its years old now and I haven't updated in in at least 5, so its a bit out of date compared to current UIs and updated cryptography features and such, but functionally, it works. When used with properly long keys, you aren't going to crack its AES implementation, I'm confident of that.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
The question here doesn't make sense does it? FIPS is a certification not an algorithm. It's like asking if my soundsystem that was THX certified would still be any good if the we found out their CEO was a crook. AES-256, Serpent, Twofish, etc... are all algorithms but only a few got FIPS certification.
On top of that, from all the articles I read, the NSA isn't actually cracking these protocals, they're using passwords and certificates gleamed from other sources as seed for cracking.
Finally, if you wanted to make sure there was no back door, you could always download the source of an open source project like TrueCrypt and compile it yourself after doing a code review.
Just food for thought...
Yeah but they wouldn't shoot themselves in the foot by giving out unbreakable encryption to the people they are trying to spy upon.
If they got a very secure algorithm, weakened it in a hard to detect way which makes it easier for the NSA and nobody else then that would be perfectly fine to both use for government documents and to give out to other nations.