Forgot your password?
typodupeerror
Government Security Linux Your Rights Online

Ask Slashdot: Linux Security, In Light of NSA Crypto-Subverting Attacks? 472

Posted by timothy
from the go-ask-theo-de-raadt dept.
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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Linux Security, In Light of NSA Crypto-Subverting Attacks?

Comments Filter:
  • by reve_etrange (2377702) on Sunday September 08, 2013 @03:59PM (#44791905)
    Much better to use LastPass or whathaveyou instead of the Chrome keystore, IMHO. For one thing, you're right about separating that from your user account keystore, but also the Chrome keystore is pretty insecure. LastPass makes a point of this during installation, once you've OK'd the install it's able to silently access all your passwords.
  • by Jeremiah Cornelius (137) on Sunday September 08, 2013 @04:01PM (#44791923) Homepage Journal

    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 [bell-labs.com]

  • Linux and RdRand (Score:5, Informative)

    by Digana (1018720) on Sunday September 08, 2013 @04:04PM (#44791943)

    There was recently a bit of a kerfuffle over RdRand [cryptome.org].

    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.

  • Re:AES (Score:5, Informative)

    by Digana (1018720) on Sunday September 08, 2013 @04:06PM (#44791953)
    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.
  • by 1s44c (552956) on Sunday September 08, 2013 @04:13PM (#44792009)

    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 [wikipedia.org]

  • by dalias (1978986) on Sunday September 08, 2013 @04:14PM (#44792017)
    Fortunately there is an effective counter-measure: http://www.dwheeler.com/trusting-trust/ [dwheeler.com]
  • Re:AES (Score:4, Informative)

    by cold fjord (826450) on Sunday September 08, 2013 @04:17PM (#44792045)

    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.

  • Re:AES (Score:2, Informative)

    by Anonymous Coward on Sunday September 08, 2013 @04:20PM (#44792061)

    The AES was designed by Rijmen and Daemen, who are not working for the NSA (the former for a belgian university, and the other one for ST microelectronics), after a public competition. Every element of its design (which is simple) was justified. If the NSA wanted something they could break, then why not doing it themselves (that was the case of the DES).

    The AES was chosen by the US government because it was apparently secure while fast and easy to implement. The academic crypto community widely considers it secure after more than 10 years of effort to break it (note that twofish does not look less secure, but what makes you think that the NSA could break the AES and not twofish ? In fact nobody can break any of them).

    The point of the AES competition was to provide US companies (i.e. the public) with something secure enough against potential attacks from their competition.

  • Re:AES (Score:5, Informative)

    by burne (686114) on Sunday September 08, 2013 @04:42PM (#44792175)
    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.
  • Re:AES (Score:2, Informative)

    by Anonymous Coward on Sunday September 08, 2013 @06:30PM (#44792781)

    All crypto algorithms have cracks for reduced round variants. Each round diffuses and mixes the state more--ideally increasing cracking difficulty exponentially.

    Whether a break for N of M rounds is sufficient to lose trust in an algorithm is entirely a judgment call, and others disagree with Bruce regarding AES.

    If you want to crank up the security of an algorithm, you should probably choose those from Dan Bernstein. His algorithms tend to be highly parameterized, to please both the tin foil hat crowd, as well as the hardware whiners trying to minimize the number of gates necessary.

    But choosing a more widely used algorithm is more often preferable. You get the benefit of highly tuned implementations, including tuning which reduces weaknesses. It also reduces application complexity. These things are infinitely more important than the mathematics behind the algorithm, at least for the set of publicly vetted algorithms that meet a minimum standard of acceptability.

    AES is _seems_ less secure than alternatives in large part because it's so visible. More academics are banging away on it. Other alternatives have received less attention, and there may be more serious, undiscovered flaws. Are there other algorithms that are better than AES? No doubt. But you're playing Russian Roulette by trying to pick them.

    Don't forget that AES is derived from Serpent, which is an algorithm invented by some European academic cryptographers unaffiliated (as far as we know) from any government. Also, Bruce himself has published successor algorithms to Twofish. Why not choose one of them instead?

  • by Anonymous Coward on Sunday September 08, 2013 @07:35PM (#44793127)

    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.

  • by Noir Angellus (2740421) on Sunday September 08, 2013 @08:48PM (#44793411)
    Very pretty example, but badly flawed. Thanks to Login being open source, and the abundance of de-compilers available from independent sources, shenanigans such as this can be readily detected by comparing the de-compiled code from the freely available source code and noting significant variations, specifically blocks of additional logic not included in the source. While behaviour like that illustrated would go unnoticed in the closed source (Windows) world, and very likely does, it doesn't wash in the FOSS community. Nice try.
  • by Jeremiah Cornelius (137) on Sunday September 08, 2013 @09:45PM (#44793653) Homepage Journal

    It is not easy to discover vulnerabilities through code examination.

    The easy to discover problems are picked up by source management tools, LINTs and things.

    Functional vulnerability in derived object code is less work-intensive, and generally returns richer results versus man-hours of investment.

    Pen geniuses still "fuzz" binaries, rather than trawl millions of lines of code.

    Think about how Android vulnerabilities are discovered, by Blackhat Briefing presenters. They don't usually delve into the monolithic available sources. Many vulns only make themselves evident, when combined with microcode on devices or in combination with radio stacks, etc.

    Code is used to confirm findings. Sometimes. ;-)

  • by Trax3001BBS (2368736) on Monday September 09, 2013 @12:23AM (#44794365) Homepage Journal

    Digitial Forensics for Prosecutors presentation suggests Truecrypt has a backdoor.
    http://www.techarp.com/showarticle.aspx?artno=770&pgno=0 [techarp.com]

    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 [techarp.com]

"Tell the truth and run." -- Yugoslav proverb

Working...