Slashdot Mirror
Ask Slashdot: Linux Security, In Light of NSA Crypto-Subverting Attacks?
New submitter deepdive writes "I have a basic question: What is the privacy/security health of the Linux kernel (and indeed other FOSS OSes) given all the recent stories about the NSA going in and deliberately subverting various parts of the privacy/security sub-systems? Basically, can one still sleep soundly thinking that the most recent latest/greatest Ubuntu/OpenSUSE/what-have-you distro she/he downloaded is still pretty safe?"
Moral
The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect.
http://cm.bell-labs.com/who/ken/trust.html
"Flyin' in just a sweet place,
Never been known to fail..."
There was recently a bit of a kerfuffle over RdRand.
Matt Mackall, kernel hacker and Mercurial lead dev, quit Linux development two years ago because Linus insulted him repeatedly. Linus called Matt a paranoid idiot because Matt would not allow RdRand into the kernel, because it was an Intel CPU instruction for random numbers that could not be audited. Linus thought Matt's paranoia was unwarranted and wanted RdRand due to improved performance. Recently Theodore T'so has undone most of the damage, but call RdRand still exist in Linux. I do not understand exactly if there are lingering issues or not.
The last time that the NSA weakened an algorithm they recommended was by shortening the key for DES. Snowden confirms that properly implemented crypto still works, and Rijndael (AES) still seems strong. The problem aren't the algorithms, because the mathematics still check out. The thing to fear are the implementations. Any implementation for which we are not free to inspect its source is suspect.
Every encryption protocol you use has been sabotaged to be readable by them. You dont really think they will try 200 trillion keys to break your stream do you?
No. They modified the protocols, (to make them more secure) and of course never explained the changes. They just mandated it.
Even the almighty NSA with it's insanely high budget can't crack all the encryption. But it does make me wonder if I should avoid everything they recommend.
I suspect the NSA has developed custom hardware for the more common encryption types. Custom hardware was shown to work extremely well on DES by deep crack. http://en.wikipedia.org/wiki/EFF_DES_cracker
Fortunately there is an effective counter-measure: http://www.dwheeler.com/trusting-trust/
The last time that the NSA weakened an algorithm they recommended was by shortening the key for DES.
Minor correction: They strengthened the DES algorithm by substituting a new set of S-boxes which protected against an attack that wasn't publicly known at the time. They shortened the key space which made it more susceptible to brute forcing the key. Full strength DES has held up very well against attacks overall until its key length became a problem. It lasted much longer in use than intended.
I seem to recall that DES was never approved for protecting classified data, but that AES does have that approval.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
One Bruce Schneier is a (loud) advocate for increasing the number of rounds in AES. Currently it's set at 16, and he advocates increasing it to much more. His main reason for this is that there's a differential crypto-analysis attack against known plaintext data encrypted with reduced rounds AES implementations. In short: If you know or control some of the encrypted data, you can extract bits of the key by comparing changes between encrypted known data. The bits you gain reduce the keyspace you need to search. AES according to the guidelines isn't vulnerable for this. Yet.
why do people keep suggesting to use lastpass?
Seriously!
You don't want Chrome to have acces to all your keys, but you're quite happy to fucking upload them to some server run by some random fucking mouth breather in some fucking country you don't know.
Digitial Forensics for Prosecutors presentation suggests Truecrypt has a backdoor.
http://www.techarp.com/showarticle.aspx?artno=770&pgno=0
The entire link inadvertently explains why cloud storage shouldn't be used, and that mobile devices are your worst enemy.
The only mention of TrueCrypt is this sentence:
"Currently available for major software - Microsoft bitlocker,
FileVault, BestCrypt, TrueCrypt, Etc" (sic)
It does have these gems
"The Patriot Act allows for the use of backdoors for counter terrorist investigations"
The use of backdoors cannot be detected or proven.
Vendors are legally and commercially prevented from acknowledging their backdoors.
Defense will not be able to prove their existence.
The files can be described as "forensically obtained"
Users of mobile devices and cloud storage sign off on their rights to data scanning.
There is no opt our option.
Lots more...
PDF can be downloaded here:
http://www.techarp.com/article/LEA/Encryption_Backdoor/Computer_Forensics_for_Prosecutors_(2013)_Part_1.pdf