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?"
How could anyone trust an encryption algorithm provided by an organization whose purpose is decryption and interception? That will always be the craziest part.
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.
"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.
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.
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
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.