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?"

472 comments

  1. No. by Anonymous Coward · · Score: 4, Funny

    I think there's even a law for this kind of reply...

    1. Re: No. by Anonymous Coward · · Score: 0

      1. Typewriter
      2. One-time pad cipher
      3. Dark (possibly candle/lantern lit) room
      4. Burn ribbon when done writing
      5. Hand delivery of said material
      6. Shoot recipient as government conspiracy theorists advise
      7. Shoot self in peacefully deserted parking lot
      --EOF--
      Problem solved.

      There is only one other way of resolution: Trust no one and keep to yourself. (Oh, and forget the wife, 1.5 kids, dog, and picket fence -- see previous statement.)

      And welcome to post-Rand-ian post-1984 "democracy".

      Also, read what Tao Te Ching says about the best government. (If you know it's there, it's probably a bad thing -- And French fry where you should pizza and you're not gonna have a good time...)

      Cheers!

    2. Re:No. by Anonymous Coward · · Score: 0

      the insightful and yet sad part of this reply is, yes, yes there is a law

  2. Not much worry with a source build by msobkow · · Score: 4, Interesting

    The big worry is not building from source, but builds delivered by companies like Ubuntu, which you have absolutely no guarantee are actually built from the same source that they publish. Ditto Microsquishy, iOS, Android, et. al.

    The big concern is back doors built into distributed binaries.

    --
    I do not fail; I succeed at finding out what does not work.
    1. Re:Not much worry with a source build by msobkow · · Score: 4, Interesting

      Another one that concerns me is Chrome, which on Ubuntu insists on unlocking my keystore to access stored passwords. I'd much rather have a browser store it's passwords in it's own keystore, not my user account keystore. After all, once you've granted access to the keystore, any key can be retrieved.

      And, in the case of a browser, you'd never notice that your keys are being uploaded.

      --
      I do not fail; I succeed at finding out what does not work.
    2. Re:Not much worry with a source build by Concerned+Onlooker · · Score: 2

      In the Apple Keychain Access app the access to each key is restricted to a list of applications that are set by the user. You are allowed to grant access of a particular key to all applications, however.

      --
      http://www.rootstrikers.org/
    3. Re:Not much worry with a source build by Zumbs · · Score: 4, Insightful

      Then why do you use Chrome? Pulling stunts like that would make me uninstall a program in a heartbeat ...

      --
      The truth may be out there, but lies are inside your head
    4. Re:Not much worry with a source build by AlphaWolf_HK · · Score: 4, Interesting

      Eventually you have to draw the line somewhere with regard to where you stop trusting. If the Linux kernel sources themselves contained a backdoor, I would be none the wiser, and neither would most of the world. Some of us have very little interest in coding, let alone picking through millions of lines of it to look for that kind of thing. And then of course there's syntactic ways of hiding backdoors that even somebody looking for one might miss.

      --
      Careful with names containing L slashdot.org/~AiphaWolf_HK slashdot.org/~AlphaWoif_HK slashdot.org/~AiphaWoif_HK
    5. Re:Not much worry with a source build by reve_etrange · · Score: 1, Informative

      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.

      --
      .: Semper Absurda :.
    6. Re:Not much worry with a source build by roscocoltran · · Score: 1, Interesting

      I can't help but feel scared by this SELINUX thing. You can tell me a hundred time that the code was reviewed (was it ?) I still won't trust it. I'd like to be sure that just disabling it altogether is enough to stop it completely from....I don't know, opening backdoor ? Cmon, NSA code in the kernel ?

    7. Re:Not much worry with a source build by Anonymous Coward · · Score: 1

      tl;dr:

      Use Gentoo.

    8. Re:Not much worry with a source build by Anonymous Coward · · Score: 1

      Ubuntu (and other FOSS distributions): Tthey do publish the source, patches and buildscripts used, so you can recompile yourself and either use that version or compare the checksums against their own. PGP keys mean you can verify the builds are authentic from Ubuntu and not provided by another party.

    9. Re:Not much worry with a source build by hedwards · · Score: 1

      You do, but if you're that worried, there's always truecrypt and keepassx. If you keep the database in a truecrypt encrypted partition, the NSA can't get at that with any reasonable period of time. You can also ditch the keepassx and just store it as plain text in the encrypted partition, but that's not very convenient.

    10. Re:Not much worry with a source build by ImdatS · · Score: 2

      Mod up the parent!

      Yes, that's actually my concern all the time. Of course, with open source, you could technically check the source of the system you are using. But then, you'd need to check every line of code, thinking exactly like the NSA (or what-not) in every piece of software you use, including the compiler you use to compile and the compiler compiler, etc, etc.

      Additionally, you'd need to check the source of all the HW-components that come with their own BIOS, including the system's BIOS, networking chip's onboard software, and a lot more. Of course, you could reduce the number of checks if you would write your own code for encryption that sits between your keyboard/mouse, memory, etc - meaning, if you really want to sleep sound, you need to write your own encryption system end-to-end, i.e. from the first input (electricity flowing from .e.g keyboard) to the last output. Even then, I wouldn't be sure if I hadn't forgotten anything in-between...

    11. Re:Not much worry with a source build by WaffleMonster · · Score: 2

      The big worry is not building from source, but builds delivered by companies like Ubuntu, which you have absolutely no guarantee are actually built from the same source that they publish. Ditto Microsquishy, iOS, Android, et. al.

      The big concern is back doors built into distributed binaries.

      So what is the practical difference between a "back door" and a security vulnerability anyway? They both remain hidden until found and they both can easily result in total ownage of the (sub)system.

      History demonstrates "open source" community is not immune from injection of "innocent" security vulneribilities into open source projects by way of human error. I find it illogical to assume intentional vulnerabilities would be detectible in source code where we have failed to detect innocent ones.

      And as for your compiler argument what guarantee do you have the compiler itself is not compromised how do you know epic fail is not being injected into resulting executables during compilation?

      Even if you can compile a compiler attacks have been previously demonstrated which are capable of compromising the additional layer of indirection.

    12. Re:Not much worry with a source build by lesincompetent · · Score: 1

      I tend to agree but... is somebody actually looking at the source and auditing the important bits?

    13. Re:Not much worry with a source build by henryteighth · · Score: 2

      Did you build your own compiler? If not, how can you trust the binaries it produces? Have you dissected your CPU? How do you know it's executing the instructions you want and not quietly running other instructions too? As others have said, you have to draw the line somewhere. Personally, I have no trouble running a binary distribution (not sure why you pick on Ubuntu and not Redhat or Suse or Debian or FreeBSD, but meh)

    14. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      Do you go over all the source of Linux to ensure nothing detrimental is in there? If not you may as well be running the binaries.

    15. Re:Not much worry with a source build by 1s44c · · Score: 1

      Compile again for the source package and do a binary diff. There will of course be a few differences so it might be hard to find real code differences.

      It would be an interesting experiment anyway.

    16. Re:Not much worry with a source build by 1s44c · · Score: 1

      I can't help but feel scared by this SELINUX thing. You can tell me a hundred time that the code was reviewed (was it ?) I still won't trust it. I'd like to be sure that just disabling it altogether is enough to stop it completely from....I don't know, opening backdoor ? Cmon, NSA code in the kernel ?

      Plus it breaks things all over the place if you actually try to use it.

      Can't we just throw out SElinux and pretend it never existed?

    17. Re:Not much worry with a source build by 1s44c · · Score: 1

      tl;dr:

      Use Gentoo.

      If the NSA have backdoors or deliberate exploitable bugs in the kernel it doesn't matter what distro or meta-distro you use.

      OpenBSD is the last OS you can really be sure of.

    18. Re:Not much worry with a source build by M.+Baranczak · · Score: 5, Insightful

      The NSA is a big organization. They do plenty of things that don't violate the Constitution, international treaties, or common sense.

      SELinux is the least of our worries. It's not impossible to hide backdoors or vulnerabilities in an open-source product, but it is pretty difficult. And if the spooks managed to do it, they certainly wouldn't be putting their name on this product, because the people that they're really interested in are even more paranoid than you.

    19. Re:Not much worry with a source build by Truekaiser · · Score: 1

      Also rip out se-linux too. As well as roll your own ipsec implementation.

    20. Re:Not much worry with a source build by 1s44c · · Score: 1

      I tend to agree but... is somebody actually looking at the source and auditing the important bits?

      Many people are. Not all of them are on your side.

    21. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      Additionally, you'd need to check the source of all the HW-components that come with their own BIOS, including the system's BIOS, networking chip's onboard software, and a lot more.

      Which components outside of the motherboard come with their own BIOS? Are you conflating firmware with BIOS? They are not one and the same. It's like suggesting a mouse be checked to see if it contains a keyboard.

      Pedantry aside, everything else is right on the money.

    22. Re:Not much worry with a source build by Ingenium13 · · Score: 1

      I don't think Chrome uses my Ubuntu keystore. It never asks for a password when opening Chrome, and it never requested access to the keystore. I'm using 12.04.

    23. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      I wouldn't trust Google nor Canonical. Google I don't have to explain. AFAIK there's no mention of Canonical in the recent revelations, but I would be surprised if they haven't been targeted, either by legal extorsion or hacking or source code insertion. Ubuntu (at least the no-prefix version) is big enough to be a target. And they never valued people's privacy in the first place, see the Amazon lens debacle.

    24. Re:Not much worry with a source build by M.+Baranczak · · Score: 1

      If they did it to Linux (and we still don't know for sure if they did, or what they did) then they could have done it to OpenBSD.

    25. Re:Not much worry with a source build by MaskedSlacker · · Score: 2, Funny

      Or at least, they will have in ten years when the OpenBSD codebase catches up.

    26. Re:Not much worry with a source build by Skapare · · Score: 1

      Just be sure you do not build from source with a compiler that was not built from source, or a compiler that was built from source by a compiler that was not built from source, or a compiler that was built from source by a compiler that was built from source by a compiler that was not built from source ... and so on. In other words, source is fine (as long as you read it all) but binary is not since it may be secretly infected.

      --
      now we need to go OSS in diesel cars
    27. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      The practical difference is that since somebody puts backdoors in on purpose, they know about them from day one. Whereas other security problems have to be discovered before they're exploitable.

    28. Re:Not much worry with a source build by Smallpond · · Score: 4, Interesting

      There was an attempt to backdoor the kernel a few years back. I don't believe the perpetrators were ever revealed.

    29. Re:Not much worry with a source build by rvw · · Score: 5, Insightful

      You do, but if you're that worried, there's always truecrypt and keepassx. If you keep the database in a truecrypt encrypted partition, the NSA can't get at that with any reasonable period of time. You can also ditch the keepassx and just store it as plain text in the encrypted partition, but that's not very convenient.

      Can you be sure that Truecrypt has no backdoors? If so, how?

    30. Re: Not much worry with a source build by Anonymous Coward · · Score: 0

      There should be no differences since it would be built exactly like the binary version. Same version of gcc, ld, etc. Same flags and so on.

    31. Re:Not much worry with a source build by SuricouRaven · · Score: 5, Interesting

      Backdooring a CPU wouldn't actually be that difficult. You'd need it to recognise a specific command sequence (128-bits long should do it) when reading memory to trigger the backdoor - that way you could activate it by sending a network packet, or reading external media, or routing traffic. And all the backdoor needs to do is run a simple 'set instruction pointer to immediately after this trigger.' It'd be impossible to defend against short of using an un-backdoored CPU to filter the trigger out, and even then it could be snuck through in an SSL session or a fragmented packet.

      And best of all, it would *never* be detected. The schematics for a CPU are practically impossible to reverse-engineer from the masks, and both schematics and masks are strictly internal company property. Plus the number of people who could understand them in enough detail to spot a backdoor without years of specialist study could probably fit in one conference hall.

    32. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      Actually, Ubuntu could be a 100% front of GCHQ. That would explain why they exist w/o making money.

    33. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      I've not heard anyone claim that the NSA has violated any international treaties. Can you name one treaty they have breached?
      I'm waiting.

    34. Re:Not much worry with a source build by msobkow · · Score: 2

      I don't. I use Firefox because it doesn't ask for access to my default keystore.

      Not that I keep any keys in the default keystore anyhow. I just don't like the behaviour of Chrome in this regard.

      Why would any sane person want to unlock their whole wallet just for a freaking browser?

      --
      I do not fail; I succeed at finding out what does not work.
    35. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      Which means we need a GNU CPU.

      Given that we had things like the Pentium F00F bug, maybe hardware is also infested with exploitable bugs, just like kernels and app software ? Maybe they (USSTRATCOM, Israel, GRU etc) can simply exploit the laziness of stressed development engineers ?

      An important lesson from (commercial ?) C and C++ development is that the attackers don't need any special cooperation. Run-of-the-mill laziness/stress of the developers (Ping of Death, Windows fonts, ASN1 parser etc) is wholly sufficient to hand them the empire.

      If somebody has time at his hands: start "fuzzing" instruction sequences and see what happens on a large number of CPUs. Maybe we discover something....

    36. Re:Not much worry with a source build by Cacadril · · Score: 1

      We need to get organized. Nobody can check all the code. Much less can everybody check all the code. So, organize a systematic partitioning, and keep lists of people who have checked each part. That will help point out areas that have been checked by few people, or by only unknown people. Additionally, if any backdoor is ever found in a piece that has been checked by twenty people, everything checked by those twenty becomes suspect. I think that is about the best we can achieve. As to backdoors inserted by the compiler, Thompson style, split the compiler binary in suitable pieces, and do a hand check of the disassembly and of the assembly.

      --
      There is no substitute for common sense. Especially, no body of rules will do.
    37. Re:Not much worry with a source build by gagol · · Score: 2

      I have some network cards, video cards and storage cards that does. All in my home server 12 feet away. Chances are you hace a couple too but may not be aware of them.

      --
      Tomorrow is another day...
    38. Re:Not much worry with a source build by Anonymous Coward · · Score: 2, Interesting

      the 1946 Convention on the Privileges and Immunities of the United Nations, the 1947 agreement between the United Nations and the United States, and the 1961 Vienna Convention on Diplomatic Relations

      from Wikipedia. Found in the first few hits by Google for "wiretapping NSA international treaties", it's really not that hard.

    39. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      I've said this, and I'll say it again, the only place to put security is in the keyboard/keypad controller itself. The reason is the keypad controller can be isolated from the rest of the system such that it's not possible to break into it. And the code size is small enough that people can verify that it does exactly what it's supposed to.

      Modern operating systems have far and away too much code running root/ring0 whatever to be trusted, period. Sure you want to harden them as much as possible. But for important stuff (The NSA, Pakistani Wire Fraud Rings, and the Russian Mafia don't care about you midget porn fetish), stuff where people have a serious incentive, banking passwords, quazi-illegal stuff, business information, you need hard protection.

    40. Re:Not much worry with a source build by Dunbal · · Score: 1

      Or drivers. Especially closed source proprietary drivers, like Nvidia, etc.

      --
      Seven puppies were harmed during the making of this post.
    41. Re:Not much worry with a source build by Dunbal · · Score: 3, Insightful

      I think you're missing the concept of what a back-door actually is. Yeah. Trust your "key chain" app. Your data is safe! If only the NSA had thought of that. Curses!

      --
      Seven puppies were harmed during the making of this post.
    42. Re:Not much worry with a source build by budgenator · · Score: 5, Interesting

      One of our advanatages is that I'm sure the Russians don't want NSA backdoors in Linux, and the NSA doesn't want Russian backdoors in Linux and neither want Chinese Backdoors and simalarly the Chinese want neither NSA or Russian backdoors. After all of this "Spy vs. Spy" Linux is unlikely to have backdoors. If your requirements are great enough that unlikely isn't good enough your probably shit outa luck because nothing will be good enough for you.

      --
      Apocalypse Cancelled, Sorry, No Ticket Refunds
    43. Re:Not much worry with a source build by Dunbal · · Score: 1

      You want complete security disconnect it from the network and never ever connect it again. And don't allow anyone to use that machine, or service the machine, or turn on the machine. Then it will be 100% secure.

      --
      Seven puppies were harmed during the making of this post.
    44. Re:Not much worry with a source build by ImdatS · · Score: 1

      Yeah, I meant firmware - but somehow, in my messed-up mind (with regards to security/encryption discussion), they are all under the heading "BIOS" (in fact, the heading should be the other way around: everything should be under the heading "Firmware"....)

    45. Re:Not much worry with a source build by SuricouRaven · · Score: 1

      It breaks things, but in ways you can fix by just changing the SE ACLs. That's the idea - it provides very granular control over permissions, even for processes that run as root.

      For low-security applications though, it's usually easier to just disable SELINUX than it would be to configure it correctly.

    46. Re:Not much worry with a source build by Anachragnome · · Score: 1

      Can anyone explain what happened to several of the posts in this thread (I cannot get them to load IN the thread), including the following:

      http://slashdot.org/comments.pl?sid=4183357&cid=44791915

      http://slashdot.org/comments.pl?sid=4183357&cid=44792345

      (last one is my own post)

      Were JC and I just censored out of an article? When logged in, there about 25 posts at the top of the thread that are visible that are not visible at all, regardless of filter-slider settings when not logged in.

      Try it. Look at what is visible when logged in, vs when not logged in. Totally different thread, IMHO.

    47. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      Except if you use a modern chipset - Sandybridge comes complete with built-in wireless, so you need to add "inside a faraday cage" to that list of requirements. Unless you're never going to power it up ever, in which case "replace it for a housebrick" would be more appropriate.

    48. Re:Not much worry with a source build by Anonymous Coward · · Score: 1

      I never understood why SELinux was chosen over the far superior alternatives. It was complex, broke often and hard, and doesn't actually work too well in practise (there's been a spate of kernel exploits recently that without even specifically being designed for SELinux still bypass it like it wasn't there).

      Even if you were to trust it 100% as being kosher, it still isn't actually fit for purpose.

    49. Re:Not much worry with a source build by SuricouRaven · · Score: 1

      F00F still needed the attacker to be able to execute code. It simply allowed any userspace process to cause a system crash, ignoring permissions. It'd be easy to build in an escalation backdoor - just needs an instruction that bypasses the user/kernal space distinction, keyed to only work if some registers contain a specific value to prevent detection. But that depends upon being able to run code, while my idea of a memory trigger works even if you can't execute anything legitimately.

    50. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      The big worry is not building from source, but builds delivered by companies like Ubuntu, which you have absolutely no guarantee are actually built from the same source that they publish. Ditto Microsquishy, iOS, Android, et. al.

      The big concern is back doors built into distributed binaries.

      When did Ubuntu become a company?

    51. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      Really? That got voted "Insightful"? The mind boggles. The point of recent revelations isn't that the NSA has been installing specific backdoor code, it is that they have been systematically weakening or diluting consumer and commercial security to the point where they are able to crack it.

      Given how atrocious SELinux has proven to be at blocking threats in practise, I'd say it's a prime qualifier for the label of "intentionally weak sauce security."

    52. Re:Not much worry with a source build by 1s44c · · Score: 1

      The thing is it always breaks things in ways that make it look like the problem is elsewhere. If system calls returned ESELINUXSAYSNO instead of hiding behind other error messages it would be less of a nightmare.

      SElinux causes all kinds of random breakage even on tools that come with the distribution. The last one I got was CentOS 6.4 when SSH would not allow root to login unless the daemon was started manually. Nothing was logged in dmesg or /var/log/messages. strace and ssh debugging gave me nothing to hint at the problem. It looked exactly like sshd was misconfigured, which it wasn't.

      SELINUX is unworkable in practice with maybe only a few exceptions. There is no reason it's enabled in any distro.

    53. Re:Not much worry with a source build by AHuxley · · Score: 1

      The main aspect to consider is one person or front group getting into networking or encryption. That would be the classic way in over the life of a project. Just keep producing quality work that has a known hidden weakness but is still passable.

      --
      Domestic spying is now "Benign Information Gathering"
    54. Re:Not much worry with a source build by AHuxley · · Score: 1

      Yes its like the targeting of the big brand commercial OS and hardware makers. The idea that Linux would be too small or more hard work to keep hidden seems a mistake. Why let one very powerful OS escape the same efforts?

      --
      Domestic spying is now "Benign Information Gathering"
    55. Re:Not much worry with a source build by Anonymous Coward · · Score: 5, Informative

      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.

    56. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      Honestly, the larger threat is not the machine, but the pathways you use it on.
      Access to your local machine is far less interesting, on the most part, than the traffic it generates.
      Man in the middle attacks are nearly impossible to stop if they undetected.
      While a untrusted third party (i.e. hacker x) is fairly easy to notice, the trusted 'hacker' (i.e google, yahoo, at&t, verizon...) are nearly impossible.

    57. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      How about a company like Red Hat and SELinux, "built into the kernel", that was built in part by NSA?

    58. Re:Not much worry with a source build by Burz · · Score: 1

      He was just comparing features, and didn't mean to imply that Apple's was better because its proprietary.

    59. Re:Not much worry with a source build by pthisis · · Score: 2

      It only unlocks the wallet for the user it's running as, it doesn't have crazy admin privileges.

      If you care about security, you're already running the browser as a restricted user anyway--even if you did stupidly share passphrases between wallets (or accidentally mistype the wrong passphrase into the browser unlock window) it still shouldn't have FS permission to your primary wallet.

      Plus you can run Chromium if you want to be able to audit the source, presuming you don't think someone's Ken Thompson'd chrome into gcc (or CPU microcode).

      --
      rage, rage against the dying of the light
    60. Re:Not much worry with a source build by pthisis · · Score: 2

      It does, though it's configurable. https://code.google.com/p/chromium/wiki/LinuxPasswordStorage has details.

      --
      rage, rage against the dying of the light
    61. Re:Not much worry with a source build by RabidReindeer · · Score: 1

      Additionally, you'd need to check the source of all the HW-components that come with their own BIOS, including the system's BIOS, networking chip's onboard software, and a lot more.

      Which components outside of the motherboard come with their own BIOS? Are you conflating firmware with BIOS? They are not one and the same. It's like suggesting a mouse be checked to see if it contains a keyboard.

      Pedantry aside, everything else is right on the money.

      I seem to recall that some disk controllers did, in fact jack themselves into the BIOS. Also video cards, and NICs (PXE boot support, for example).

    62. Re:Not much worry with a source build by pesho · · Score: 4, Funny

      May be they can agree on one backdoor which they can share like big brothers.

    63. Re:Not much worry with a source build by smash · · Score: 1

      You realise that modern keyboards have firmware in them that can be compromised?

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    64. Re:Not much worry with a source build by gweihir · · Score: 2

      Chrome is spyware, what do you expect? Its very purpose is to get all your data.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    65. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      Unless you're never going to power it up ever

      It's almost like you read his post or something.

    66. Re:Not much worry with a source build by gweihir · · Score: 1

      SELinux is pretty unlikely to be compromised. It would just be too obvious. So far they have weakened CPRNGs and crypto constants for ECC. Both require expert-level knowledge to detect, while a flaw in SELinux can be found by any reasonably competent programmer.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    67. Re:Not much worry with a source build by smash · · Score: 1

      Given the brain damage of C, that could just as easily have been a typo. I've seen a similar typo myself in an online game I used to be part of a coding team on, which resulted in everybody's skills being set to 99% the first time the code to check for skill advancement ran :D

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    68. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      A random mouth breather is more trust worthy than Google (which is basically a branch of the NSA).

    69. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      There was an attempt to backdoor the kernel a few years back. I don't believe the perpetrators were ever revealed.

      You still have to trust them to find things like that, unless you are able to verify all their changes yourself.

    70. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      right because you read source code you compile

    71. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      the 1946 Convention on the Privileges and Immunities of the United Nations, the 1947 agreement between the United Nations and the United States, and the 1961 Vienna Convention on Diplomatic Relations

      from Wikipedia. Found in the first few hits by Google for "wiretapping NSA international treaties", it's really not that hard.

      Those establish diplomatic immunities for the UN, immunity from legal systems, which really has nothing to do with intelligence services by themselves.

      You are free to point out where either document has anything to do with collection of intelligence or specific NSA activities.

      It looks from here like you just googled some words and blew your load because there were results.

    72. Re:Not much worry with a source build by shentino · · Score: 1

      You only need compromised once to leak your data forever.

    73. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      Does this mean that open-source or otherwise in-house manufactured CPUs are the way of the future for security-conscious individuals and organizations?

    74. Re:Not much worry with a source build by Lennie · · Score: 1

      HDD's obviously also contain firmware and SSD's even more.

      --
      New things are always on the horizon
    75. Re:Not much worry with a source build by klui · · Score: 1

      Under normal circumstances, yes, but the change log shows the modification going into the source tree outside the normal process--someone modified the file on that server directly.

    76. Re:Not much worry with a source build by utkonos · · Score: 1

      I use Chrome on Kubuntu which does store its passwords in Kwallet. However, kwallet can have multiple wallets. You are not being forced to store Chrome's passwords in the same wallet that the system stores its passwords at all. The new secretservice libraries and utilities are not stable yet, but when they are, the back end storage for kwallet will be the same back end as gnome.

    77. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      fuck chrome proprietary piece of crap with a metric shit ton of google spy gadgets

    78. Re:Not much worry with a source build by rastos1 · · Score: 1

      What about this and this ? (Interesting how current media did not bring up that repetition of history)

    79. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      I just recently read an article somewhere (here or on ars probably) about all our compilers and build tools could already infected with architechture-jumping viruses that are baked in so well with it cant be detected. I could not find the article.

    80. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      and then they can wipe or format the drive and there goes. OR YOU can do it by mistake.

    81. Re:Not much worry with a source build by Alain+Williams · · Score: 5, Insightful

      What would you do if you where a Chinese or Russian spook and discover a NSA backdoor in Linux ? You could cry foul! to Linus and get it fixed. However: a much more profitable action would be to silently fix it in your own security critical machines and then exploit it as much as possible on your targets in the West.

    82. Re:Not much worry with a source build by stiggle · · Score: 1

      Anything which is restricted in software can also be compromised by software.

    83. Re:Not much worry with a source build by Alain+Williams · · Score: 1

      SELinux is the least of our worries. It's not impossible to hide backdoors or vulnerabilities in an open-source product, but it is pretty difficult.

      Most people look in the kernel; however a large part of SELinux is the rule base that it uses. This is poorly documented, very complex, written by each distribution that uses SELinux (ie multiple, unchecked implementations) and potentially modified with every RPM that you install on your system.

    84. Re:Not much worry with a source build by rew · · Score: 1

      I disagree. I'm pretty confident that canonical builds the binaries in a safe way. Even though there is a thirty year old "proof of principle" article on how to hide a backdoor somewhere almost impossible to detect.

      The problem is that an average Unix system has many bugs at any one time. Debian and Canonical have given up on updating the kernel on every privilege escalation bug. You might forget to run apt-get upgrade for a few days.

      When the NSA needs your data, they will for sure have a big list of things-to-try to get into your system. They will most likely succeed. It's the same with every other directed adversary. He'll be able to get in.

      Note that I'm toning down what I read in the media a bit. When the facts state: "NSA was able to hack into some phones", the reports will change from "NSA hacked into phones" into "NSA can hack all phones" and "NSA has access to all data on your phone". They don't. Once they are interested in you, they will try to hack your phone and get what they need.

      It's different for internet monitoring. Traffic analysis and automated wiretapping is something they are apparently into. So the big internet providers have automated that and they can't do much to verify the requests they get. So when Snowden says he could tap anyone anywhere, he means he could issue a "wiretap warrent" from his desk, which would reach, say yahoo as: "NSA wants access to the traffic from IP x.y.z.w, you're not allowed to ask why." And then Yahoo might try to fight that a few times, but they have already lost. So nowadays that is processed immediately, and/or automatically.

    85. Re:Not much worry with a source build by bluegutang · · Score: 4, Insightful

      But you'd have to prevent knowledge of the backdoor from leaking. Hundreds of engineers work on each CPU, each group produces and verifies a new CPU design every year or so, there is considerable employee turnover every few years, and nobody has ever reported such a thing. So I find it unlikely.

      Disclaimer: I work as a hardware engineer for a major CPU manufacturer.

    86. Re:Not much worry with a source build by b4upoo · · Score: 1

      No government wishes people to be able to communicate freely. Sad, but all too true.

    87. Re:Not much worry with a source build by fuzzywig · · Score: 1
      I use LastPass, and it's really helpful. However, they're based in the US, so if the NSA (or other TLA) really wants your data, then they can just pop round with a court order or a National Security Letter or a gun and demand access to all of your passwords.

      Now, I assume that the NSA isn't interested in me, but I couldn't recommend Lastpass to someone who was worried about the government.

      That said, there are several OSS password managers, or you could even just keep a text list inside a Truecrypt volume. One of those would be the more secure choice.

    88. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      I'd much rather have a browser store it's passwords in it's own keystore, not my user account keystore.

      And, in the case of a browser, you'd never notice that your keys are being uploaded.

      *its

      FFS get it right!

    89. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      PGP keys mean you can verify the builds are authentic from Ubuntu and not provided by another party.

      I don't know anything about how well Ubuntu protects their signing key. Do you? (seriously, you might; it's not a rhetorical question.) Anyone wanna tell us Ubuntu's processes?

    90. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      If you're storing passwords in your browser, you've already shot yourself in the foot.

      I work for a Managed Security Services Provider and browser password storing, among other things, is strictly prohibited (as are dictionary passwords).

    91. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      Actually, it's more likely to be like the WWII crypto-efforts: The NSA doesn't want the Chinese or the Russians to know that they know about their backdoors, and vice versa. The NSA would be happy with a Chinese backdoor - saves them the trouble of getting another one in themselves, and tells them where to watch for Chinese efforts.

    92. Re:Not much worry with a source build by allo · · Score: 1

      Chrome is a Problem, because its closed source.
      Chromium is okay. And you did not understand the concept of a keystore. When chromium requests access to kwallet, you can give it access to an own "chromium" wallet, which only contains data from chromium. You can have as much wallets, as you want.

    93. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      two engineers of 160iq given a year for example can easily outsmart one of 300 given 6 months. Face it, the government has done a LOT of damage in leaving things open to interpretation.

    94. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      encrypted memory space in OpenBSD should work, wouldn't it?

    95. Re:Not much worry with a source build by marcosdumay · · Score: 1

      Backdooring a network card would be easier (it has first-hand access to the network data), more transparent, less obvious and as usefull than backdooring a processor.

      It's quite harder to see anything wrong when two devices talk to each other by DMA, completely bypassing anithing that could run an OS.

    96. Re:Not much worry with a source build by SuricouRaven · · Score: 1

      The hundreds wouldn't know about it. They produce their CPU quite innocently. Only the three-man espionage team needs to know about it, and the manager who lets them make a few modifications to the design during the process of turning schematics into mask.

    97. Re:Not much worry with a source build by SuricouRaven · · Score: 1

      No. Network card still has to write the frames into a buffer cleartext somewhere.

    98. Re:Not much worry with a source build by marxmarv · · Score: 1

      THIS. Americans relate to duplicity like fish relate to water: it's apparently the medium of action in the world we inhabit, yet we can't see it.

      --
      /. -- the Free Republic of technology.
    99. Re:Not much worry with a source build by SuricouRaven · · Score: 1

      But there's no way to communicate back - the network card doesn't even know the default gateway, so it can't send data out.

    100. Re:Not much worry with a source build by gagol · · Score: 1

      Firmware yes, we were talking about bios... the threat aslo exist though.

      --
      Tomorrow is another day...
    101. Re:Not much worry with a source build by marcosdumay · · Score: 1

      You can discover that easily if you can read the network stream.

    102. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      There are passwords that you are a crucial security measure (such as your Google login, your bank login, etc), and there are passwords that are an inconvenience (such as the login to some random hentai forum or some shit). The latter are the ones that you put into Lastpass.

      Now, whether or not lastpass sniffs all your other passwords anyways (the way their extensions work, they *do* have this capability) is another question :-)

    103. Re:Not much worry with a source build by reve_etrange · · Score: 1

      That's not how LastPass works. All of the credentials are packed into a single binary blob which is encrypted locally using a key which itself is never sent over the network. They actually have a very good security model. In comparison, Chrome doesn't even bother to encrypt stored passwords.

      The weakness is the same as with any piece of software: unless you personally read every line of code, you don't know for sure what it will do.

      --
      .: Semper Absurda :.
    104. Re:Not much worry with a source build by reve_etrange · · Score: 1

      Supposedly LastPass never transmits the master key over the network, so actually they do not have this capability.

      The real security benefit of a password manager is in using automatically generated passwords. I use 16-25 characters, allowing alphanumerics and special characters and requiring each type.

      --
      .: Semper Absurda :.
    105. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      its why i run everything on a z80.

    106. Re:Not much worry with a source build by Lennie · · Score: 1

      I'm sorry, but a BIOS is firmware.

      Look at UEFI as an example.

      --
      New things are always on the horizon
    107. Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      I can't help but feel scared by this SELINUX thing. You can tell me a hundred time that the code was reviewed (was it ?) I still won't trust it. I'd like to be sure that just disabling it altogether is enough to stop it completely from....I don't know, opening backdoor ? Cmon, NSA code in the kernel ?

      No doubt because you don't have a clue what SELinux even is. It isn't something that you disable, you stupid fucking retard. On the contrary, it's something you have to go out of your way to enable and configure. Get a clue before opening your mouth and showing the entire world what a complete dipshit you are.

      If you're truly worried about SELinux then you can just use one of the alternate approaches to access control. There are at least two viable and well established alternatives, and in typical linux fashion there are literally dozens of others too.

  3. OpenBSD by Anonymous Coward · · Score: 1

    Short of writing it all yourself, I think OpenBSD is as close as you will find to a useful OS you can trust.

    1. Re:OpenBSD by Predius · · Score: 2, Interesting

      Even that's no good if the problem is flaws in the spec rather than how it's implemented by OSs. If the NSA did things correctly they didn't have to muddle with actual Linux/BSD/etc src, they got flaws into the crypto definition itself that reduces the work needed to crack it. The better an OS follows the spec... the easier for the NSA to punch through.

    2. Re:OpenBSD by Anonymous Coward · · Score: 0

      The better an OS follows the spec... the easier for the NSA to punch through.

      So... You're saying that Microsoft Windows is the most secure OS?

    3. Re:OpenBSD by Anonymous Coward · · Score: 0

      That's easier to spot than a nasty buffer overflow or "use after free", so less credibility to this tactic.

    4. Re:OpenBSD by gweihir · · Score: 1

      There is also the small problem, that a flaw in the logic could be exploited by anybody that finds it. Flaws in crypto can be designed so that only the one that inserted it can use it. Which is one reason I do not believe SELinux is compromised. Far too much risk of somebody else finding and exploiting the problem. Or publishing it widely, and the traceback to the NSA would be trivial.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    5. Re:OpenBSD by utkonos · · Score: 1

      Nobody is completely safe. Even OpenBSD. In light of these new Snowden docs, the following post by the OpenBSD author makes quite a lot of sense. Theo is accusing certain developers of being paid to backdoor the OpenBSD IPSEC stack dating back to 2000/2001 which coincides with the current revalations.

      Theo de Raadt's post to the openbsd-tech mailing list.

    6. Re:OpenBSD by utkonos · · Score: 1

      Just to reiterate this. Everything is basically tainted at this point. We need to redo tons of standards and we need to exclude the US government from having a seat at the table.

    7. Re: OpenBSD by Anonymous Coward · · Score: 0

      There is no crypto in SELinux. SELinux is nothing more than ACL on application level (which systemcalls the app is allowed to use etc).

    8. Re: OpenBSD by gweihir · · Score: 1

      Indeed. Exactly my point. While the NSA can hope to get away with inserting flaws in crypto, they cannot for something like SELinux.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  4. AES by greenfruitsalad · · Score: 1

    i never understood why people go for AES. clearly, if NSA recommends it, in my view it is something to be avoided (i personally go for twofish instead). in ubuntu, ecryptfs uses aes by default, so i would not trust that.

    1. Re:AES by Digana · · Score: 5, Informative

      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.

    2. Re:AES by hedwards · · Score: 1

      AES consists of well studied algorithms. Whether or not the NSA recommends it, it's still known to be secure by independent researchers. From what I understand the only breaks to it are marginally better than brute force, and not likely to result in the data becoming available in a useful period of time.

    3. Re:AES by cold+fjord · · Score: 4, Informative

      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
    4. Re:AES by greenfruitsalad · · Score: 4, Funny

      if the whole world goes for one cipher, then nsa can concentrate on creating and improving a single ASIC design for breaking it. we should be using hundreds of different algorithms. then they'd have to design hundreds of types of ASICs, build 100x more datacentres, increase taxation in USofA to 10x what it is now, yanks would rebel and overthrow that government and then there would be no more evil NSA. simples

    5. Re:AES by Anonymous Coward · · Score: 2, Informative

      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.

    6. Re:AES by WaffleMonster · · Score: 1

      i never understood why people go for AES. clearly, if NSA recommends it, in my view it is something to be avoided (i personally go for twofish instead). in ubuntu, ecryptfs uses aes by default, so i would not trust that.

      Pick a government. If you trust the Russians use GOST. If you trust the Japanese use CAMILLA. NSA has a dual role in spying and protection from spying. By intentionally selecting a vulnerible algorithm cleared for use in protection of classified secret information they also KNOWINGLY compromise their mission to protect US secrets.

      Obviously we can't reason about what we don't know. We must all make our own decisions regarding who/what to trust. I will add AES has been continually subject to attention by researchers because of its heavy use worldwide. To date there is nil public information to indicate it is subject to compromis when used properly.

    7. Re:AES by Threni · · Score: 2

      Is there any particular reason why people don't strengthen AES (or any other symmetric encryption) by just reencrypting 1000 times? Perhaps interleaving each encryption with encrypting with the first 1, then 2 etc. It would make next to no difference for the end user, who's going to decrypt just once, but I imagine it would add a lot more time to the cracking of the encrypted data than increasing the size of the key.

    8. Re:AES by WaffleMonster · · Score: 4, Insightful

      Is there any particular reason why people don't strengthen AES (or any other symmetric encryption) by just reencrypting 1000 times? Perhaps interleaving each encryption with encrypting with the first 1, then 2 etc. It would make next to no difference for the end user, who's going to decrypt just once, but I imagine it would add a lot more time to the cracking of the encrypted data than increasing the size of the key.

      Exponents are actually what protects information, multiplication just makes people feel good.

    9. Re:AES by burne · · Score: 4, Informative

      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.

    10. Re:AES by boristhespider · · Score: 0

      "Snowden confirms that properly implemented crypto still works"

      Yes, because I'm going to trust everything he says. Honestly, kudos to him for leaking everything he has but am I *really* going to trust he knows *everything* and he also isn't going to misreport things for his own personal gain, or to mislead the Russians and Chinese, or to *help* the Russians and Chinese (who, after all, he ran to and was held by for a month) and mislead others, or any other conspiracy-lead scenario you can think of?

      Surely, if you care at all about what Snowden decided to leak one thing you should really get from it is *don't fucking trust what someone says who may have vested interests*. And he has vested interests, merely different ones from the NSA (although not necessarily that different if his pious claims to not leaking anything that would hurt American security can be believed, which they may or may not be). And since we never know what someone's vested interests are, assume that everyone has vested interests. So don't trust anyone. Then it all becomes a game about how far you think you can go on anything.

      Personally I take the view that what I do online - and, if they are bugging every single computer which is technically possible though unless they've got to them too would pop up on network analyzers which it doesn't seem to - is just going on an enormous slagheap of metadata, which is kept for about three days before space runs out and it's pruned down to the most likely pieces of interest and kept for about six months to a year, at which point most of it is trashed to recover the space.

      Paranoia is all well and good - and definitely, definitely do not trust anything *anyone* says, and that includes Snowden just as much as it includes shitheads like Obama and Putin (who is in a different world of shitheadedness entirely, no matter what the propaganda currently says) if there's even the vaguest reason to think they might want to keep one thing hidden or exaggerate another.

      Healthy cynicism is the way to go, people. Mad paranoia is just ridiculous because ultimately the NSA/GCHQ/FSB/whoever really just do not care about you. Mad acceptance is equally ridiculous because every spy agency on the planet will always push its remit as far as possible to invade as much privacy as they can - because they would be remiss if they didn't, and hang the consequences.

    11. Re:AES by rvw · · Score: 1, Interesting

      Is there any particular reason why people don't strengthen AES (or any other symmetric encryption) by just reencrypting 1000 times? Perhaps interleaving each encryption with encrypting with the first 1, then 2 etc. It would make next to no difference for the end user, who's going to decrypt just once, but I imagine it would add a lot more time to the cracking of the encrypted data than increasing the size of the key.

      It seems that encrypting the file multiple times with the same key is not safe, and tends to expose the flaws in the encryption method. It will be less secure. Hashing the password with a random key multiple times (like keepass uses 5000 rounds), and then using that string to encrypt the file, however should work. I'm not an expert on this matter, just repeat what someone else replied me when asking the same question.

    12. Re:AES by Goaway · · Score: 1

      Doesn't matter. AES is not going to fall to a few ASIC chips in the first place. Doesn't matter how many the NSA builds, and they wouldn't waste their money on that in the first place.

    13. Re:AES by Anonymous Coward · · Score: 1

      Occam's razor points towards both Snowden and Manning being authentic. I was considering these being enormous PSYOPS, though. But as you write, at one point your own conspiracy fantasy must be kept in check. I am not so sure about that Vanunu guy though. He "proved" a certain country having nuclear weapons by his "spill".

    14. Re:AES by TuringCheck · · Score: 5, Funny

      Pick a government. If you trust the Russians use GOST. If you trust the Japanese use CAMILLA.

      Then use all three of them in sequence and hope it would be quite difficult to have them all cooperate to break your encryption.

    15. Re:AES by Dunbal · · Score: 1

      Only because the researchers don't know how to find the key and the sequence only looks random but it's non-random in a way only the NSA knows how to recognize. Because other leaked documents claim that the NSA has been heavily involved in the development of all consumer-level cryptography chips. It doesn't matter how you code, it's the chip that's giving the game away. If the NSA has a pattern it can recognize which tells them how to decrypt it, then researchers will see it as unbreakable while the NSA will be able to crack it.

      --
      Seven puppies were harmed during the making of this post.
    16. Re:AES by Anonymous Coward · · Score: 0

      Is there any particular reason why people don't strengthen AES (or any other symmetric encryption) by just reencrypting 1000 times? Perhaps interleaving each encryption with encrypting with the first 1, then 2 etc. It would make next to no difference for the end user, who's going to decrypt just once, but I imagine it would add a lot more time to the cracking of the encrypted data than increasing the size of the key.

      I do not know whether that would actually provide extra security, but I do know that it would greatly slow both encryption and decryption.
      Fancy encryption schemes may sound great, but the scheme itself will be public, and anyone attempting to crack it would know the method. I say without any expertise that encrypting with two 50-bit keys is typically weaker than encrypting with a single 100-bit key.

    17. Re:AES by Anonymous Coward · · Score: 2, Informative

      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?

    18. Re: AES by Anonymous Coward · · Score: 0

      Why not encrypt a file, the encrypt it again with a different algorithm and different passphrase!

    19. Re:AES by AHuxley · · Score: 1

      Re: 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.
      Banks and businesses where to get a stronger DES cold. The final product shipped was weaker. The only aspect that was protected was the ability of the NSA and GCHQ to get in but still keep out hackers and others. Re: DES was never approved for protecting classified data as it was for commercial use.....

      --
      Domestic spying is now "Benign Information Gathering"
    20. Re:AES by pjt33 · · Score: 1

      Serpent was a candidate, but Rijndael is the algorithm which became AES. The rest of the point stands.

    21. Re:AES by Anonymous Coward · · Score: 0

      It probably has already passed the revolting threshold for some...

    22. Re:AES by AHuxley · · Score: 1

      That was the mixing of old and new efforts. In the distant past the US/UK could set a product for say NATO, embassy use by friendly nations or banking.
      Over time most understood what they had been sold was junk at a price point to keep safer private sector crypto competitors, hackers and the Soviet Union out.
      Transmission was safe, plain text was always leaking.
      The next step seems to be to offer great encryption to a global PR standard. As we now seem to understand most of the surrounding telco, networking and the OS where weakened/worked with to ensure the end product was something they never needed to break. The plain text was always accessible and networking trackable at over the useful life of products use.

      --
      Domestic spying is now "Benign Information Gathering"
    23. Re:AES by burne · · Score: 1

      Ah. DJB and JF. The mad math professors. Thanks for your comments. Sadly no modpoints, so the reward is platonic.

    24. Re:AES by Anonymous Coward · · Score: 0

      He wasn't held by the Russians. His passport was revoked by the US and he knew any plane he chose to leave on would be interdicted and forced to land.

      No idea where you go the notion that the Chinese held him.

    25. Re:AES by multimediavt · · Score: 2

      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).

      In fact, you are dumber than you appear. I've said it more than once, encryption is not a magic spell. Trust me, if anyone has the mathematicians and the hardware to break *ANY* encryption it is the NSA. It's been their job for more than 60 years. If you can show me internal NSA documents that prove otherwise, I'll believe you. In the mean time, believe that no encryption algorithm is "secure".

    26. Re:AES by multimediavt · · Score: 1

      Pick a government. If you trust the Russians use GOST. If you trust the Japanese use CAMILLA.

      Then use all three of them in sequence and hope it would be quite difficult to have them all cooperate to break your encryption.

      Try writing in Navajo. You have a better chance.

    27. Re: AES by Anonymous Coward · · Score: 0

      That is actually something that is used. I implemented such a system for one particular company for protecting highly sensitive data where they wanted a solution that used two completely separate encryption systems to ensure that if one was compromised they would have time to re-engineer the system without being overly exposed. processing time was not an issue so this was easy to implement, however for many the CPU and time overhead of multiple encryption streams and complex keys can get rather heavy.

    28. Re:AES by dido · · Score: 1

      AES has gotten scrutiny from the best cryptanalytic minds in the world for well over a decade, and not one of them has been able to find an attack on it capable of breaking the algorithm significantly faster than brute force. If Edward Snowden is to be believed, not even the NSA's vaunted cryptanalytic ability has been able to find a sufficiently serious flaw in AES either. I agree that we need more algorithms, perhaps a dozen or so, but not hundreds. Too much diversity will have the effect of diffusing the pool of open experts that subject these algorithms to cryptanalytic scrutiny and the chances increase that one or more of the algorithms in use will have a serious flaw.

      --
      Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
    29. Re:AES by smash · · Score: 1

      Good thing the new generation CPUs have AES in hardware right? Much faster and more secure. Ohwait...

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    30. Re:AES by Anonymous Coward · · Score: 0

      DES was created by IBM, with modifications by the NSA.
      The only publicly-known modern cipher developed entirely by NSA is Skipjack.

    31. Re:AES by Anonymous Coward · · Score: 0

      Then use all three of them in sequence and hope it would be quite difficult to have them all cooperate to break your encryption.

      WOW! GEE! Three cryptos at once! Why, they've NEVER be able to decode that -- unless they somehow all worked together. Or one of them had a $5 wrench.

    32. Re:AES by boristhespider · · Score: 0

      If you think that he was happily sitting in a hotel in Hong Kong and Chinese agents didn't talk to him, or that he was sitting "in an airport" in Moscow and Russian agents never talked to him, you are absurdly naive. I know people like to point out that Hong Kong isn't China and all but... seriously, when it comes to security, it is, and Beijing ultimately rules Hong Kong despite "One Nation, Two Systems".

      When I say "talk" I mean "interrogate". I'm not implying that they treated him as a criminal, nor that he necessarily obliged them, but they will have wanted to assess everything he had with him and learn everything they could from him. To think otherwise is... crazy. To think we'd do otherwise with a whistleblower from Russia or China is equally crazy.

      With the passport thing, that was a bit of a smokescreen. If it suited the Russians they could very easily provide him with a temporary visa (as indeed they eventually did), take him out of the airport via the back door (as indeed they may well have done; we have zero proof that he was literally in the airport that entire time) and transported him anywhere within Russia that they chose. Leaving it so long before they did this doesn't automatically mean they were playing for time to see what they could learn, but I've no doubt that *one* of the consequences of the delay was that the FSB had more time to have friendly chats with Snowden (who may or may not have been playing ball; I'm casting no allegations around).

    33. Re:AES by boristhespider · · Score: 1

      Oh, I think Snowden is authentic, as far as he goes. Whether he knows everything that's going on, or whether everything he's leaked is actually true, is a different matter entirely, but I don't think the man himself is deliberately lying, nor that there isn't at least a lot of truth in most of what he's released. Likewise Manning and Vanunu (probably more so, too, in both cases given the jail time).

      My point wasn't really to attack Snowden, or open that whole can of worms again, but more to always make sure you don't blithely trust something he (or anyone else) says, merely because it might fit in with your particular views or beliefs. It's a truism that everyone has their own biases and political beliefs and that it colours everything people say or write, and the interpretations they cast on information they receive, entirely unintentionally. It's also a truism that many people throughout history have been happy to distort the truth, or distort others' statements, to further their own interests. And so on.

      And yeah, ultimately we should all try and make sure that our own conspiracy fantasies - nice phrase :) - are controlled a bit...

    34. Re:AES by michelcolman · · Score: 2

      Hashes have collisions: multipe strings can result in the same hash, although hash designers try to minimise this as much as possible. If you keep hashing the password over and over again, like 5000 times, the resulting number of possible results will get smaller and smaller and therefore the final key, which you use to encrypt the actual file, will be less safe. Not a good idea.

    35. Re:AES by Anonymous Coward · · Score: 0

      Exactly,
      The problem is standardization. If we would all use our own easy encryption, the NSA would have a big problem. Because they would have to do manual work for each message. Which is impossible.

      The last message of the famous killer Zodiac has never been fully decrypted. This was in the 70s...
      If you encrypt just text and use a symmetric key, there is no way you can ever for sure know what "jklfdçUçàu2JJFE"* means :-)
      For text, you should also use spelling mistakes and dialects or phonetic writing.

      * that could be just "hello" but also a 2 page story.

    36. Re:AES by aztracker1 · · Score: 1

      I recently, mainly for interoperability, created a base for user authentication tokens for .Net (with corresponding node.js code), that will take a shared secret (random string), scrypt it (Math.pow(2,14), 1, 8), and use that as the base cipher/iv for aes256.. technically a bit stronger than the default .Net FormsAuth... I seed my input data with a few bytes of random data, so the encoded values don't share output.

      That said, ymmv of course.

      --
      Michael J. Ryan - tracker1.info
    37. Re:AES by secdev · · Score: 1

      There are several good reasons why multiple (cascade) encryption is not necessarily more secure than either algorithm on its own. Moreover, there are examples of situations where cascade encryption provide a false sense of security. Matthew Green posted an articlein 2012 on his website that addresses this issue.

    38. Re:AES by u38cg · · Score: 1

      Because sandwiching encryption or repeating it simply leaves you open to other, more subtle attacks. Often the effect is to amplify theoretical or marginally practical attacks on the algorithm.

      --
      [FUCK BETA]
    39. Re:AES by marcosdumay · · Score: 1

      Few people ever tried to break your algorithm, thus it's untested and one shouldn't rely on it. Altough, it should be no worse than a single application of AES. Also, crypto researchers are always after fast algorithms that achieve as near as the maximum security as possible for their keylength, thus just doing more rounds won't gain many fans.

      Now, I have a similar question. If I take 3 (or more) assymetrical crypto algorithms - name them A, B and C, and encrypt some text with them, in the order ABCABC, I should get something that is no worse than the best algorithm in the set. Is that a valid thing to do when you suspect one of them may have a backdoor?

    40. Re:AES by marxmarv · · Score: 1

      What information would they have gotten by holding a competition that they wouldn't have gotten by developing internally?

      Competitive intelligence, duh. If you want to see what the state of the art in civilian crypto is, of course you want to look at as much as possible.

      --
      /. -- the Free Republic of technology.
    41. Re:AES by DickBreath · · Score: 1

      You say it correctly: encryption is not a magic spell. But you then proceed to treat cryptanalysis as if it were a magic spell.

      Just because intercepting signals is part of the NSA's job doesn't mean they can magically crack any kind of cryptography by waving some kind of magic wand. They have human minds like other cryptanalysts. They have more computing resources, but that only shortens brute force time, by insignificant amounts. (One thousand times faster than one trillion years doesn't matter.)

      If you can show me internal NSA documents that prove otherwise, I'll believe you. (Clearly, while that argument works both ways, it doesn't mean anything when used either way.)

      In the meantime I'll put my faith in various algorithms based on how well they have withstood the test of significant attack efforts, over a long time, by brilliant people.

      --

      I'll see your senator, and I'll raise you two judges.
    42. Re:AES by Anonymous Coward · · Score: 0

      You could do a combo of DES-X and 3DES concepts with AES, so something like:
      ciphertext = AES-E-K3( AES-D-K2( AES-E-K1(plaintext xor X1) xor X2 ) xor X3 )

      Not very readable, so here is step by step
      1. Xor plaintext block with X1
      2. AES Encrypt above with Key1
      3. Xor above with X2
      4. AES Decrypt above with Key2
      5. Xor above with X3
      6. AES Encrypt above with Key3

      X1, X2, X3 are 128-bit (block size) values that are randomly generated
      K1, K2, K3 are 256-bit AES keys ideally unique for each step

      The Encrypt-Decrypt-Encrypt increases keylength to help prevent brute force
      The Xor steps are a form of key whitening again helping with brute force

      If there are known vulnerabilities/backdoors in AES (key scheduling, S-Boxes, etc) your security is reduced to:
      ciphertext = plaintext xor (X1 xor X2 xor X3)

  5. If it is off by morcego · · Score: 5, Insightful

    You can sleep soundly if your computer is off and/or unplugged. Otherwise, you should always be on your guard.

    Keep your confidential data behind multiple levels of protection, and preferentially disconnected when you are not using it. Never trust anything that is marketed at 100% safe. There will always be bugs to be exploited, if nothing else.

    A healthy level of paranoia is the best security tool...

    --
    morcego
    1. Re:If it is off by 1s44c · · Score: 1

      You can sleep soundly if your computer is off and/or unplugged.

      That's the good advice that nobody takes. Putin went one step further and recommended using typewriters for confidential data.

    2. Re:If it is off by morcego · · Score: 2

      You can sleep soundly if your computer is off and/or unplugged.

      That's the good advice that nobody takes. Putin went one step further and recommended using typewriters for confidential data.

      I'm more on the "never sleep soundly" side of things. Trusting you have a secure system is a good part of the problem. Even a typewriter had flaws.

      --
      morcego
    3. Re:If it is off by symbolset · · Score: 2

      Hopefully manual typewriters. Some electric typewriters have been hacked.

      --
      Help stamp out iliturcy.
    4. Re:If it is off by Anonymous Coward · · Score: 0

      The electric typewriters were hacked by inserting hardware into them - they aren't computers that can run arbitrary code, they are just an electromechanical implementation of a mechanical device. You could very easily develop hardware that could act as a keylogger/transmitter for a mechanical typewriter, the only thing about electrics that make it easier is the availability of electrical power to increase the device's endurance vs. batteries.

    5. Re:If it is off by viperidaenz · · Score: 1

      As long as you burn the used ribbon afterwards, and nobody gets a hold of the type writer afterwards either.

    6. Re: If it is off by mike260 · · Score: 1

      That's not even remotely what a TPM does.

    7. Re:If it is off by Anonymous Coward · · Score: 0

      I bet some properly funded researchers could recover a far bit of information just from an audio recording of the typing on a manual.

    8. Re:If it is off by glavenoid · · Score: 1

      Heh, manual typewriters were "hacked" a very, very long time before computers were even invented. Ever hear of reading the ink ribbon?

      --
      I, for one, am looking forward to the inevitable /. beta rollout fallout.
    9. Re:If it is off by glavenoid · · Score: 1

      damn, I should have scrolled down and read the same premise posted by someone else already. Please mod me -1 redundant for the above, and -1 offtopic for this comment.

      --
      I, for one, am looking forward to the inevitable /. beta rollout fallout.
    10. Re:If it is off by Dunbal · · Score: 1

      You can still read the patterns on the ink ribbons... Or the drum, for that matter :)

      --
      Seven puppies were harmed during the making of this post.
    11. Re:If it is off by SuricouRaven · · Score: 1

      I wonder if anyone has tried making a 'spy-resistant' ribbon, where the used ribbon isn't just spooled but first run through a roller or series of rollers to erase any trace of imprints - perhaps by overlaying lots of obscuring lines and letters.

    12. Re:If it is off by Anonymous Coward · · Score: 0

      I think this overlooks a very important and new fact for our society: our data is no longer in our hands, and we don't have control over a lot of it. If your computer is off, you can sleep soundly that there are no active attacks on the data that resides there, but what about your bank's servers that are on 24/7, which hold your personal information? What about your Facebook account? Privacy settings don't stop direct database/network access. There are companies out there with enough data to ruin your life, and it's not a handful, it's probably in the hundreds.

      What all of this reveals to me that the Internet (and the computers that comprise it) was not built for security, but for connectivity and it is at this point that we must implement a strong security fabric that provides Authentication, Identification and Authorization features de facto. Barring this, we will continue to see abuses of the technology that runs our world and protects our livelihoods.

    13. Re: If it is off by HiThere · · Score: 1

      You mean "...what it is claimed that a TPM does." I doubt that anyone posting knows what it actually does. (Possibly someone reading here does.)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    14. Re:If it is off by Anonymous Coward · · Score: 0

      This should pose another question........

      Can you trust Firewalls? Anti-Virus/Malware programs anymore? It would be safe in assuming these to have open back doors in them for various government agencies to crack into. In light of the major OS's building blatant holes in there software, and or special portals for certain "concerned parties" to exploit, I would only guess that no closed software, from any company is really safe.

    15. Re:If it is off by michelcolman · · Score: 1

      The arms carrying the letters make a slightly different sound when hitting the paper. Extremely sensitive NSA spy satellites can pick up these sounds and eavesdrop on your entire message.

    16. Re: If it is off by gishzida · · Score: 1

      That's not even remotely what a TPM does.

      A possible correction to your assertion-- you meant to say: "That's not even remotely what *they say* TPM does..." The truth is we only have the assurances of those whom we no longer trust for most of the alleged "privacy" and "security" of our systems...

      Security mechanisms are built on trust in the purveyors of the mechanism... I'd say from the revelations that the US Government [which is NOT denying them] has just blown our trust in most security mechanisms to very small pieces... The whole "TPM hardware is safer" and the fact that the world's biggest OS seller requires it for its current OS speaks volumes.

      Maybe TPM means "The Pwned Machine"

    17. Re: If it is off by mike260 · · Score: 1

      If you're gonna argue from zero evidence, just claim that the CPU itself is pre-rooted and be done with it.

    18. Re: If it is off by Anonymous Coward · · Score: 0

      What's the endorsment key for my TPM... the hardware I paid for?

      How do I find out?

      Oh right... that would be why I'm right and you're a shill for the 1984 crowd behind Trusted Computing.

    19. Re:If it is off by romons · · Score: 1

      electric typewriters? Ha! Also, if you copy the document, you are out of luck; modern xerox machines can keep digital copies of everything they duplicate. Also, if the spooks have sonic access to the typewriters, they can probably figure out much of what is being typed, given enough samples.

      Face it, given enough energy and time, nobody can win here. There is only one real solution: have no secrets.

      --
      Go to Heaven for the climate, Hell for the company -- Mark Twain
    20. Re:If it is off by symbolset · · Score: 1

      The electric typewriters were hacked by creating a readable radio signal with each keypress. If you look at the circuit diagrams they seem deliberately designed so as to do so. In the day that would have been readable at 1km. Now you can see it from a satellite.

      --
      Help stamp out iliturcy.
    21. Re:If it is off by symbolset · · Score: 1

      Good luck reading the text written off the stirred wet ash of our typewriter ribbons. Throwing out that stuff went out in the '70s.

      --
      Help stamp out iliturcy.
  6. It has never been safe. by Anonymous Coward · · Score: 0

    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.

    1. Re:It has never been safe. by 1s44c · · Score: 4, Informative

      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

    2. Re:It has never been safe. by SuricouRaven · · Score: 1

      I'm sure they go beyond that. I'm picturing full-length PCI cards with thirty-two cores each, packed sixteen to a 2U box, and a warehouse full of them. All running at 3GHz. Crypto-cracking needs crazy amounts of processing power, but very little network communications. If you wanted to, you could network them all on 10baseT.

      And a watercooling system - because the smaller the facility is from the outside, the less any potential opponents will estimate your capabilities to be. Plus it'd be cheaper than trying to air-cool something like that, even on hot/cold aisles.

    3. Re:It has never been safe. by Anonymous Coward · · Score: 0

      Precisely. I don't think this crowd appreciates what kind of processing capability is available for billions of dollars. We know they are "over-building" storage and so what happens is they can brute-force decrypt only a handful of messages for now and store the rest in perpetuity. At any time if they decide an encrypted message is a high value target, they can probably decide how much resources to devote to it - a simple cost/benefit analysis. Sound familiar? Yes, that was the ending of THX1138.

    4. Re:It has never been safe. by multimediavt · · Score: 1

      Even the almighty NSA with it's insanely high budget can't crack all the encryption.

      If you're an American you better hope that's *NOT* true and hope that we get them off spying domestically. So to rebut, yes they can (remember hardware is only part of the encryption breaking; smart people with better algorithms is another piece). If it exists they have broken it.

    5. Re:It has never been safe. by gweihir · · Score: 1

      Nonsense. IPSec was killed by them by making it weak and complicated, true. (Which counts as a severe attack on critical infrastructure in my book and makes them a lot more immoral and dangerous than any terrorist organization.) But to read most messages, they just have to compromise SSL certificates and they likely have done that for all commercial certificate providers by cooperation, coercion and plain old criminal hacking. Any expert knows that self-signed certificates have been a lot more secure for a long time now.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    6. Re:It has never been safe. by Culture20 · · Score: 1

      Probably submerged mineral oil cooling since water cooling 16 pci cards might be difficult.

    7. Re:It has never been safe. by SuricouRaven · · Score: 1

      Mineral oil has its own issues - long-term it damages capacitors. Water doesn't seem too impractical: Use those mini GPU blocks on the cracker chips. Each rack gets it's own pump and heat exchanger at the top, and hot/cold manifold pipes to plug the cracker boxes in to. Then each rack in turn hooks in to the big coolant pipes leading up to the fans on the roof, cunningly disguised as air conditioning machines. From the outside, it could look just like a warehouse.

    8. Re:It has never been safe. by gishzida · · Score: 1

      Why not just rent the CPUs from a cloud provider with an encrypted private line to the locak NSA data center and hide it in plain sight?

    9. Re:It has never been safe. by Anonymous Coward · · Score: 0

      768 bit RSA keys were broken by public researchers a few years ago if I remember right, and at the time they intimated that 1024 bit RSA keys would be broken within 2-4 years (i.e. around now). I can't find the exact quotes and paper at the moment but if I can I'll post it as a comment.

      What is known pretty well is that the NSA contracts out to IBM to build chips, custom ones. It's almost a -given- that 1024-bit RSA keys have been broken by more than just the NSA, I would suspect that their own equipment allows them to break higher than that. There's some speculation that a 4096-bit RSA key would still be relatively secure, but when you have an entity building entire server farms, likely with custom hardware, dedicated solely to breaking those keys if all other methods fail... At this point, if it's on a computer and that computer is connected to the Internet, I don't think you can consider it secure any more.

    10. Re:It has never been safe. by SuricouRaven · · Score: 1

      Because custom crypto-specialised cracker chips would be many orders of magnitude faster than general-purpose CPUs.

    11. Re:It has never been safe. by Anonymous Coward · · Score: 0

      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.

      200 trillion keys? In this day and age I could brute force that on my smart phone.

  7. Yes. by Anonymous Coward · · Score: 2, Insightful

    You have to trust the integrity of Linus and the core developers.

    If any of them let in such major flaws they would be found out fairly quickly... and that would destroy the reputation of the subsystem leader, and he would be removed.

    Having the entire subsystem subverted would cause bigger problems.. but more likely the entire subsystem would be reverted. This has happened in the past, most recently, the entire changes made for Android were rejected en-mass. Only small, internally compatible changes were accepted, and these went through the usual analysis, and (rather severe) modifications to make them compatible.

    It is possible that this is part of the reason IPsec has never been accepted in the kernel networking code.

    1. Re:Yes. by Anonymous Coward · · Score: 0

      You have to trust the integrity of Linus....

      Welp, that answers that.

    2. Re:Yes. by AHuxley · · Score: 1

      Re and that would destroy the reputation of the subsystem leader
      The world tried trust via the PR/branding/stock price/legal issues/failed international sales wrt to the closed source/private sector code/OS/telcos.

      --
      Domestic spying is now "Benign Information Gathering"
  8. Ken Thompson, Anyone? by Jeremiah+Cornelius · · Score: 5, Interesting

    You can not add security, later.

    In Unix systems, there’s a program named “login“. login is the code that takes your username and password, verifies that the password you gave is the correct one for the username you gave, and if so, logs you in to the system.

    For debugging purposes, Thompson put a back-door into “login”. The way he did it was by modifying the C compiler. He took the code pattern for password verification, and embedded it into the C compiler, so that when it saw that pattern, it would actually generate code

    that accepted either the correct password for the username, or Thompson’s special debugging password. In pseudo-Python:

        def compile(code):
            if (looksLikeLoginCode(code)):
                generateLoginWithBackDoor()
            else:
                compileNormally(code)

    With that in the C compiler, any time that anyone compiles login,

    the code generated by the compiler will include Ritchie’s back door.

    Now comes the really clever part. Obviously, if anyone saw code like what’s in that

    example, they’d throw a fit. That’s insanely insecure, and any manager who saw that would immediately demand that it be removed. So, how can you keep the back door, but get rid of the danger of someone noticing it in the source code for the C compiler? You hack the C compiler itself:

        def compile(code):
            if (looksLikeLoginCode(code)):
                generateLoginWithBackDoor(code)
            elif (looksLikeCompilerCode(code)):
                generateCompilerWithBackDoorDetection(code)
            else:
                compileNormally(code)

    What happens here is that you modify the C compiler code so that when it compiles itelf, it inserts the back-door code. So now when the C compiler compiles login, it will insert the back door code; and when it compiles

    the C compiler, it will insert the code that inserts the code into both login and the C compiler.

    Now, you compile the C compiler with itself – getting a C compiler that includes the back-door generation code explicitly. Then you delete the back-door code from the C compiler source. But it’s in the binary. So when you use that binary to produce a new version of the compiler from the source, it will insert the back-door code into

    the new version.

    So you’ve now got a C compiler that inserts back-door code when it compiles itself – and that code appears nowhere in the source code of the compiler. It did exist in the code at one point – but then it got deleted. But because the C compiler is written in C, and always compiled with itself, that means thats each successive new version of the C compiler will pass along the back-door – and it will continue to appear in both login and in the C compiler, without any trace in the source code of either.

    http://scienceblogs.com/goodmath/2007/04/15/strange-loops-dennis-ritchie-a/

    --
    "Flyin' in just a sweet place,
    Never been known to fail..."
    1. Re:Ken Thompson, Anyone? by Jeremiah+Cornelius · · Score: 4, Informative

      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..."
    2. Re:Ken Thompson, Anyone? by dalias · · Score: 5, Informative

      Fortunately there is an effective counter-measure: http://www.dwheeler.com/trusting-trust/

    3. Re:Ken Thompson, Anyone? by Anonymous Coward · · Score: 1, Interesting

      This argument is much, much too complicated. Plus, it can indeed be tracked down in the compiler binary. Compiling the compiler with an unrelated compiler will remove the malware in the compiler binary. You can use a really slow one for this effort, as you must use it only once.
      In reality, there are more than enough bugs of the "Ping of death" style, which can be used. Read "confessions of a cyber warrior".
      The worst thing Bell Labs brought into this world was the C and C++ languages and the associated programming style. Like char* pointers, uninitialized pointers possible and so on.

      If Bell Labs had no foisted C and C++ on this world for "free", the government would have had to invent something to make their "cyber war space" possible. Wait, Bell Labs WAS the government.

      If that's not enough, a single buffer overflow in firefox or Acrobat reader can trigger something like the Pentium F00F bug, and then they OWN THE CPU. Your stinking sandbox is wholly irrelevant at this time.

      Go figure, sucker. Me, I am a C and C++ software engineering sucker, too.

    4. Re:Ken Thompson, Anyone? by 1s44c · · Score: 1

      Madness. But gcc isn't the only C compiler that can compile code that contains GNU extensions, there was another that could even compile a working kernel but I forget it's name. Plus if you strip the GNU extensions out there are loads of alternative compilers.

    5. Re:Ken Thompson, Anyone? by gl4ss · · Score: 3, Interesting

      write your own login, use a different sourced compiler for compiling the compiler..

      anyways, can we stop posting this same story to every fucking security story already? put it in a sig or something.

      --
      world was created 5 seconds before this post as it is.
    6. Re:Ken Thompson, Anyone? by TheRealMindChild · · Score: 2

      icc. Intels c compiler

      --

      "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
    7. Re:Ken Thompson, Anyone? by rvw · · Score: 2

      Fortunately there is an effective counter-measure:

      http://www.dwheeler.com/trusting-trust/

      So you compile the code using two different compilers. How can you be sure that both other compilers don't have a parent compiler that is infected?

    8. Re:Ken Thompson, Anyone? by Anachragnome · · Score: 5, Interesting

      "The moral is obvious. You can't trust code that you did not totally create yourself...."

      I agree, but that doesn't really help us in the real world--writing our own code doesn't reasonably work out for most people. So, what's the solution to your dismal conclusion? Ferret out those that cannot be trusted--doing so is the closest we will ever come to being able to "trust the code".

      So, how does one go about ferreting out those that cannot be trusted? The Occupy Movement had almost figured it out, but wandered around aimlessly with nobody to point a finger at when they should have been naming names.

      The NSA has made it clear that making connections--following the metadata--is often enough to get an investigation started. So why not do the same thing? Turn the whole thing around? Start focusing on their networks. I can suggest a good starting point--the entities that train the "Future Rulers of the World" club. The "Consulting Firms" that are really training and placing their own agents throughout the global community. These firms are the world's real leaders--they have vast funding and no real limitations to who and where they exert influence. In my opinion, they literally decide who runs the world.

      Pay close attention to the people associated with these firms, the inter-relatedness of the firms and the other organizations "Alumni" end up leading. Pay very close attention to the technologies involved and the governments involved.

      Look through the lists of people involved, start researching them and their connections...follow the connections and you start to see the underlying implications of such associations. I'm not just talking the CEO of Redhat (no, Linux is no more secure then Windows), but leaders of countries, including the US and Israel.

      http://en.wikipedia.org/wiki/Boston_Consulting_Group

      http://en.wikipedia.org/wiki/McKinsey_and_Company

      http://en.wikipedia.org/wiki/Bain_%26_Company

      THIS is the 1%. These are the perpetrators of NSA surveillance, to further their needs...NOT yours. People with connections to these firms need to be removed from any position of power, especially government. Their future actions need to be monitored by the rest of society, if for no other reason then to limit their power.

      As George Carlin once put it so well..."It's all just one big Club, and you are not in the fucking club."

    9. Re: Ken Thompson, Anyone? by hendrikboom · · Score: 1

      Actually, he pointed out in a Turing lecture that he *could* have done it, but didn't say whether he actually had.

      --hendrik

    10. Re:Ken Thompson, Anyone? by Dunbal · · Score: 1

      Unless the "unrelated compiler" is also compromised. How far down does the rabbit hole go?

      --
      Seven puppies were harmed during the making of this post.
    11. Re: Ken Thompson, Anyone? by CockMonster · · Score: 2

      So C/C++ are a government conspiracy of the 60's so they could intercept data from the Internet, which hadn't been invented (or at least only used within military circles) at the time? You're too stupid to be a C/C++ programmer. Stop doing it.

    12. Re: Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

      #retalop

    13. Re:Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

      Nice story bro. Are we to seriously believe that nobody's ever gotten out of this loop during the past 40+ years? Especially since it's apparently a known fact? Not buying it.

    14. Re:Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

      Fortunately there is an effective counter-measure: http://www.dwheeler.com/trusting-trust/ [dwheeler.com]

      ...and the fact that this is posted in response to "Reflections on Trusting Trust" every time it appears on Slashdot is just another indication that most intelligent people are actually quite dumb, but adept at memorizing enough facts to give of some appearance of intelligence.

      Anyway, as long as you're adding this to your "shit I shouldn't post to Slashdot unless I want to reveal that I'm a philosophical zombie" list, add that article about recovering encryption keys from frozen RAM as well. I'm quite tired of seeing it too, and posting it similarly doesn't do you any favors.

    15. Re:Ken Thompson, Anyone? by Anonymous Coward · · Score: 1

      Unless the "unrelated compiler" is also compromised. How far down does the rabbit hole go?

      As far as you want it to go. The "feature" could be in the microcode for the CPU.

    16. Re:Ken Thompson, Anyone? by Trax3001BBS · · Score: 5, Interesting

      Moral

      The moral is obvious. You can't trust code that you did not totally create yourself..... A well installed microcode bug will be almost impossible to detect.

      http://cm.bell-labs.com/who/ken/trust.html

      You and the submitter in on this one? As the answer is a resounding NO.

      A well installed microcode bug will be almost impossible to detect.

      For people like me that didn't know, microcode can also be known as firmware, bios update
      or "code in a device" http://en.wikipedia.org/wiki/Microcode

      Ken Thompson's Acknowledgment

      I first read of the possibility of such a Trojan horse in an Air Force critique (4) of the security of an early implementation of Multics.

      (4.) Karger, P.A., and Schell, R.R. Multics Security Evaluation: Vulnerability Analysis. ESD-TR-74-193, Vol II, June 1974, p 52.

      So in theory you can't even trust the code you write as your video card could change it.

      --
      If you aren't paranoid yet, just wait

    17. Re: Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

      The Internet doesn't exists in my country but exists in yours, back then my friends create programs with this kind of backdoors in every programming language that they can touch, we where kids playing on those years... and I dont believe that the gov was kidding/playing on those/this times; the gov don't play for the fun they play for the win.
      You know what an easter egg is, right? some eggs are rotten and stinks.

    18. Re: Ken Thompson, Anyone? by Fjandr · · Score: 1

      No, such a backdoor could be created at any later time.

    19. Re:Ken Thompson, Anyone? by Trax3001BBS · · Score: 2

      http://cm.bell-labs.com/who/ken/trust.html">http://cm.bell-labs.com/who/ken/trust.html

      quoting Ken Thompson
        I would like to criticize the press in its handling of the "hackers," the 414 gang
       

      God I guess...
         

      The 414s gained notoriety in the early 1980s as a group of friends and computer hackers who broke into dozens of high-profile computer systems, including ones at Los Alamos National Laboratory, Sloan-Kettering Cancer Center, and Security Pacific Bank.

      They were eventually identified as six teenagers, taking their name after the area code of their hometown of Milwaukee, Wisconsin. Ranging in age from 16 to 22, they met as members of a local Explorer Scout troop. The 414s were investigated and identified by the FBI in 1983. There was widespread media coverage of them at the time, and 17-year-old Neal Patrick, a student at Rufus King High School, emerged as spokesman and "instant celebrity" during the brief frenzy of interest, which included Patrick appearing on the September 5, 1983 cover of Newsweek.
       

      September 5, 1983 cover of Newsweek
        http://mimg.ugo.com/201102/0/6/5/175560/cuts/4c6de9daa1c16-23680n_480x480.jpg

      Text from http://en.wikipedia.org/wiki/The_414s

    20. Re:Ken Thompson, Anyone? by Lumpy · · Score: 5, Insightful

      Maybe modern ones, but if you go back a few generations your chances of it existing drop drastically. so what you do for high security....

      1 - rely on OLDER hardware. Stuff from before the past two administrations would have a significantly higher chance of not having government back doors. Clinton era computers to start with.

      2 - use a completely different architecture. ARM is your best friend here or SPARC. The chances of SPARC having this are insanely small

      3 - Get processors from your countries "enemy" Russians dont use Intel processors for their KGB and Government operations. If they did they would be the biggest morons on the planet. Find out what they use and try to source them through the black or grey market channels.

      Welcome to the new world of underground computer science. Oh and keep your mouths shut. Don't do stupid shit like bragging as to what you have and where you got it. I'd say "hack the planet" but the safest thing is to go off the net and transfer data via offline means for the highest security.

      --
      Do not look at laser with remaining good eye.
    21. Re:Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

      "The moral is obvious. You can't trust code that you did not totally create yourself...."

      I'd go a step beyond...unless you're a very good programmer, otherwise your own code could actually be less secure.

    22. Re:Ken Thompson, Anyone? by Jeremiah+Cornelius · · Score: 5, Insightful

      Bingo.

      How many Intel or nVidia employees... How many Broadcom or Qualcom employees need to be placed by NSA, into their otherwise ordinary engineering jobs?

      How many Mossad associated employees? Whoops. I guess that's anti-Semitic. I'd have to ask how many PLA planted engineers, as there's no recognized anti-Sinoism. ;-)

      --
      "Flyin' in just a sweet place,
      Never been known to fail..."
    23. Re: Ken Thompson, Anyone? by Jeremiah+Cornelius · · Score: 1

      Yes. The reality of his concrete example is not a necessary condition for illustrating this vulnerability.

      --
      "Flyin' in just a sweet place,
      Never been known to fail..."
    24. Re:Ken Thompson, Anyone? by Burz · · Score: 2

      A person would have to be absolutely arrogant to trust themselves alone to effect a secure environment. No one is that good, unless we are talking about "secure" systems that are essentially non-functional.

      That's why we have communities of open source developers. Many minds and eyeballs enable a more comprehensive view of security, especially when they are watching changes incrementally accumulate. I think it is much harder to get even subtly surreptitious malware past developers this way.

      The other way, you're either coding a whole OS by yourself and are left with something too simplistic to be useful, or you're relying on proprietary vendors that are now known to be in the business of playing "Oops, we didn't mean to insert that hole... we'll have a patch for you in a couple weeks" on behalf of spies.

    25. Re:Ken Thompson, Anyone? by RabidReindeer · · Score: 4, Insightful

      This argument is much, much too complicated. Plus, it can indeed be tracked down in the compiler binary. Compiling the compiler with an unrelated compiler will remove the malware in the compiler binary. You can use a really slow one for this effort, as you must use it only once.
      In reality, there are more than enough bugs of the "Ping of death" style, which can be used. Read "confessions of a cyber warrior".
      The worst thing Bell Labs brought into this world was the C and C++ languages and the associated programming style. Like char* pointers, uninitialized pointers possible and so on.

      If Bell Labs had no foisted C and C++ on this world for "free", the government would have had to invent something to make their "cyber war space" possible. Wait, Bell Labs WAS the government.

      If that's not enough, a single buffer overflow in firefox or Acrobat reader can trigger something like the Pentium F00F bug, and then they OWN THE CPU. Your stinking sandbox is wholly irrelevant at this time.

      Go figure, sucker. Me, I am a C and C++ software engineering sucker, too.

      Before C, much less C++, there were languages like FORTRAN, COBOL, and PL/1. They were not as rigid about checking types and ranges as Java and Ada, for example. Even some versions of BASIC allowed definition of an "array" that was, in fact, a map of the entire system RAM. And, of course, peek() and poke. PL/1 has actual pointer support built into the language.

      So don't blame C. The problems go way, way back. Some systems and languages were more secure than others, but none of them were all that airtight. The onlu commercial hardware architecture that I know of that approached being REALLY secure was the Intel iAPX 432, which practically gave each stackframe its own private address space. But that one never caught on.

    26. Re:Ken Thompson, Anyone? by Noir+Angellus · · Score: 3, Informative

      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.

    27. Re:Ken Thompson, Anyone? by cavreader · · Score: 1

      What about Open Source developers who analyze the code looking for weaknesses to exploit? The malware creators of today need to understand their target systems to the nth degree to successfully exploit. Having all the source code for a program or sub-system seems to be a hackers dream come true. I am not saying there should not be open source software but today there is no program or subsystem that cannot be exploited using a combination of social engineering, sloppy server administration which lead to exploiting security holes on systems that have not been patched.

    28. Re:Ken Thompson, Anyone? by HiThere · · Score: 2

      If you're going to play it THAT way, then the exploits go back to assembler and every early digital computer. (Analog computers had different weaknesses.)

      But please remember that early Fortrans (e.g. IBSYS FORTRANII) discouraged using pointers at all. I will grant that they didn't check array bounds, but the location of the array WRT the rest of the program was not guaranteed, and was subject to being changed with different compiler options. I don't know COBOL well enough to really comment, but it's my impression that arbitrary use of pointers was even more difficult in COBOL than in FORTRAN. Don't know about variants like FARGO.

      Ken Thompson's exploit was different in nature, in that it required a more sophisticated compiler.

      P.S.: Many "C-ish" compilers from the early 1970's, e.g. Lifeboat-C for the I8008, came with source code in assembler, and compiled to assembler.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    29. Re:Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

      Write your own bootstrapping compiler in assembly. Don't forget to use an easily verified OS such as Kolibrios or Minix 3.

    30. Re:Ken Thompson, Anyone? by Jeremiah+Cornelius · · Score: 3, Informative

      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. ;-)

      --
      "Flyin' in just a sweet place,
      Never been known to fail..."
    31. Re:Ken Thompson, Anyone? by Jeremiah+Cornelius · · Score: 1

      Example of vector, not to be taken as literal example of one real threat.

      --
      "Flyin' in just a sweet place,
      Never been known to fail..."
    32. Re:Ken Thompson, Anyone? by smash · · Score: 2

      There's insecure, and there is deliberately and non-obviously malicious.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    33. Re:Ken Thompson, Anyone? by smash · · Score: 2

      I think you misunderstand the premise. You can trust code you yourself write to not be concealing deliberately malicious intent. It still maybe INSECURE, but you can at least be sure of the INTENT of code you write yourself. This isn't the case with third party software.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    34. Re:Ken Thompson, Anyone? by smash · · Score: 1

      How many C compilers can trace their lineage back to the original? I.e., they were compiled by a compiler that was compiled by a descendant of the original (possibly trojan-ed) C compiler. I'd say the only way you could consider being secure is to not write C at all. Though of course there's nothing to say that other languages have not been similarly compromised.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    35. Re:Ken Thompson, Anyone? by gweihir · · Score: 1

      The problem with this is that while it is a theoretical possibility, it is a practical nightmare to implement. For example, you absolutely must avoid that this breaks anything, because if it does, people will start tracing down the problem. Also, "login" is not so complicated as to make an assembler-level analysis impossible. And once you are found out, the backdoor you had to invest a lot of money in is gone and the people you inserted into the project are burned.

      So, while the NSA may attack critical infrastructure in the whole world (something which put them on the same moral level as terrorists and on a far higher danger and damage level) by weakening random-number generation or putting weak constants into elliptic-curve crypto, IMO they are unlikely to do something like this.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    36. Re:Ken Thompson, Anyone? by dgatwood · · Score: 2

      Unless the "unrelated compiler" is also compromised. How far down does the rabbit hole go?

      This is why you start by compiling a very simple, basic compiler like PCC using your choice of random, potentially compromised compiler, then use that PCC binary to compile a new copy of PCC. The resulting PCC-compiled PCC binary should be both small enough and simple enough instruction-wise for a few dozen people to feasibly audit it by hand. Use that to then build a verifiably source-clean copy of GCC. Use that, in turn, to build a source-clean copy of LLVM/Clang. And now you have a modern compiler that's almost certainly not generating dirty code.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    37. Re:Ken Thompson, Anyone? by dgatwood · · Score: 2

      The "feature" could be in the microcode for the CPU.

      That's not realistically very likely. Microcode typically never gets updated after the CPU ships, which means that as soon as some critical part of the compiled binary looks slightly different, the microcode won't have the desired effect. It doesn't take a large compiler change to screw that sort of thing up. Even tiny optimization changes would prevent microcode from usefully changing the behavior of a particular binary. The microcode level is just way too low level.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    38. Re:Ken Thompson, Anyone? by Burz · · Score: 1

      I think you're using an inanely narrow definition of trust. You can 'trust' yourself to the point of suffering delusions of grandeur; Its as much about capability as intention.

    39. Re:Ken Thompson, Anyone? by dalias · · Score: 1

      I think you forgot to include your (invalid) argument for why it's wrong amid the insults and other drivel...

    40. Re:Ken Thompson, Anyone? by thegarbz · · Score: 2

      it doesn't wash in the FOSS community.

      Nice try.

      A laughable comment at best. The FOSS community does not have an army of people running around decompiling binaries just to check to see if it can match compiled code from source. This is significantly less useful than the argument that FOSS doesn't contain back doors because you can look at the source. Just a tip, the vast majority of users don't.

      The vast majority of developers do, but the vast majority of developers don't as I said routinely get up in the morning and decompile published binaries. not the least because of the variances in compiler optimisations reading a decompiled code and comparing it to the source will do you head in without the NSA's help.

    41. Re:Ken Thompson, Anyone? by Mathinker · · Score: 3, Insightful

      Ken Thompson's theoretical attack against the Unix ecosystem was only practical because, at the time, he controlled a major portion of binary distribution and simultaneously a major portion of the information which could be used to defeat the attack, that being compiler technology. Nowadays, there are tons of different, competing compilers and systems for code rewriting, any of which can be used to "return trust" to a particular OS's binary ecosystem (if someone would take the time and effort to actually do it).

      Although I believe Bruce Schneier's information (previously covered in Slashdot) that, probably, any widely used software system available today is practically effortlessly pwnable by the NSA's TAO division, I don't think that the problem of designing hardened systems is an impractical one. It's just going to take a lot of hard, hard work (Schneier's call-to-arms in this regard has already been covered by Slashdot).

    42. Re: Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

      No doubt the NSA has altered the very nature of the integers 1 and 0 so that they can do this at a very low level...

    43. Re:Ken Thompson, Anyone? by Anonymous Coward · · Score: 1

      I think you forgot to include your (invalid) argument for why it's wrong amid the insults and other drivel...

      When speaking to a philosophical zombie, there's really no point. They won't understand what you say anyway. At best they'll merely pretend to understand, and maybe go on to repeat what you've said in an attempt to seem more intelligent. ...which come to think of it, isn't a bad idea. At least that way I'd be reading less drivel on Slashdot. So, what the hell:

      First, note the different perspectives each of the three papers. (The three papers being "Reflections on Trusting Trust", the "OMG it's so easy to detect" reply to it, and the "we're security researchers too" paper about reading encryption keys from frozen RAM.) One of these three was obviously written by an intelligent person with years of experience and something unique and worthwhile to say. The other two were written by some kids who have an interest in computing but no real experience and yet they nevertheless feel that some idea they came up with one day is brilliant enough to write a paper about because obviously their idea has never occurred to anyone in the past and been rejected due to its in feasibility or irrelevancy.

      Reflections on Trusting Trust tells us about how we can hide code in a compiler without that code being in the source code of the compiler. This is an extremely clever idea and it's fairly safe to say that the vast majority of the people who read the paper have never thought about it.

      The "OMG just compile the code twice and compare" paper tells us quite literally the first thing anyone would think of as a countermeasure, and ignores the infeasibility of such a comparison due to the fact that it's hard to get the same compiler with the same code to output the same executable twice, nevermind two independant compilers, which is the very next thought anyone who's thought of this has had. So what are we to do then, compare disassemblies in order to determine where one compiler simply chose to do things a different way, or even the same way, but encoded the instructions differently? ...or do we just disable optimization which makes the compilers magically spit out identical binaries since we all know there's only one unoptimized way to do anything. This solution stinks of someone who has no idea what the hell happens when a program is compiled. You'll never get identical binaries out of two compilers. So at best you're down to comparing the machine language code they generate, but if you're going to go that far, you might as well skip the comparing part and just look at the machine code output of the suspect compiler and see if it inserted anything bad. The idea is just dead-on-arrival, and the fact that anyone actually wrote a paper about it is just more evidence that most smart people are in reality complete fucking idiots.

      As for the frozen RAM paper, it seems some kids decided that breaking actual encryption was too hard, as was finding any exploits in code, and so they resorted to pulling out their RAM chips since, as everyone knows, your encryption keys are in there somewhere. However, their RAM was erased. So they tried freezing it, but it was still erased, because in modern manufacturing, they have a fine tolerance on those DRAM cells since they want as many on the chip as possible, and so they're not much larger than they have to be to survive a refresh cycle. So they went back in time and got some ram from the 80's, when manufacturing tolerances weren't as high, and again they froze the chips, but still their encryption keys were corrupted. So they wrote a utility to brute-force the key, starting with what they found in RAM as a base, and after pulling the chip out a dozen times, eventually got one which retained enough data that they were able to brute-force the key. Then they declared "OMG your encryption is broken because people can freeze your RAMz," completely ignoring that they weren't able to reproduce th

    44. Re:Ken Thompson, Anyone? by Etcetera · · Score: 4, Funny

      3 - Get processors from your countries "enemy" Russians dont use Intel processors for their KGB and Government operations. If they did they would be the biggest morons on the planet. Find out what they use and try to source them through the black or grey market channels.

      If your prescription for fixing the issues of low security is to trust the Russian (nee Soviet) Government, I'm pretty sure you're doing it wrong.

    45. Re:Ken Thompson, Anyone? by Etcetera · · Score: 1

      I think you misunderstand the premise. You can trust code you yourself write to not be concealing deliberately malicious intent. It still maybe INSECURE, but you can at least be sure of the INTENT of code you write yourself. This isn't the case with third party software.

      Not if you're Tyler Durden, you insensitive clod!

    46. Re:Ken Thompson, Anyone? by someone1234 · · Score: 1

      Compile login with the suspicious compiler and inspect its assembly code. - you may or may not notice something
      Check the size of the binary.
      Copy it to another system, preferably with a different CPU.
      Check the size of the binary again.

      There is no way they have on the fly cross compiling root kit :D

      --
      Patents Drive Free Software as Hurricanes Drive Construction Industry
    47. Re:Ken Thompson, Anyone? by smash · · Score: 0

      Still. There is a difference between an actual backdoor that was placed there by an adversary who knows about its existence and a potential backdoor that would need to be discovered via remote probing.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    48. Re:Ken Thompson, Anyone? by deepdive · · Score: 1

      A quick and dirty fix to such compiler attacks could be to have proper network watchdogs setup, and paying attention to the logs they generate.

      For example, init and login should not be accessing the network! Of course one can go one step deeper and inspect all file-handles opened by all the process. As a process can write stuff to a hidden log (and indeed memory!), and then some ok-looking process can fire up and do the actual net transfer. etc

      Of course, this would have to be a hardened kernel level module.

      So a little extra vigilance can take care of such attacks. But the crypto-weakening attacks don't seems to be so straight forward to manage. imho.

    49. Re:Ken Thompson, Anyone? by michelcolman · · Score: 2

      Different compilers produce different code. Some will produce faster and/or smaller code, even with optimisations turned off. Especially (obviously) code compiled for a different CPU. There's no way you'll find a back door by simply comparing the size of the binaries. They will always be different anyway.

    50. Re:Ken Thompson, Anyone? by Alain+Williams · · Score: 1

      You can trust code you yourself write to not be concealing deliberately malicious intent.

      Just remember that you typically only write a small amount of the code that ends up in your program. Do you use printf() and other library functions, or do you write the code to do system calls yourself ?

    51. Re:Ken Thompson, Anyone? by McDutchie · · Score: 1

      How can you be sure that both other compilers don't have a parent compiler that is infected?

      David A. Wheeler addresses this question in his dissertation.

    52. Re: Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

      So you haven't read or understood the Dwheeler paper. Also if you claim to have trouble making the same compiler yield the exact binary when fed the same code you have probably never used a compiler.

    53. Re: Ken Thompson, Anyone? by Anonymous Coward · · Score: 1

      What you fail to understand is that we don't need an army or the vast majority of the user base to conduct such checks. All that is required is a single individual, i.e once a discrepancy is found it is found.

      Also, which projects do you think people like Coverty uses to test their new shiny algorithms to find such problems, the closed ones where they don't have access to the code or FLOSS?

    54. Re:Ken Thompson, Anyone? by Electricity+Likes+Me · · Score: 1

      Functionally identical. I highly doubt that the NSA has compromised GCC. They will have an enormous database of version numbers and working exploits for different systems though, and get are presently getting a good chuckle from all the all loudest people implementing their new "secure" platforms and most probably writing their own buggy and exploitable cryptocode.

      If I wanted to fight terrorism, then convincing all the terrorists not to trust US government standards for top secret information sounds like a pretty good bit of social engineering to avoid arming my enemies.

    55. Re:Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

      Wow, I didn't know Linux is that insecure. Glad I'm using Windows.

    56. Re:Ken Thompson, Anyone? by ron_ivi · · Score: 5, Interesting

      Perhaps he's thinking to configure it so you only have to trust the Russian *or* US government. Dunno how it'd work for compute nodes --- but if you have 1 Russian Firewall in front of one US firewall in front of one Chinese firewall -- it seems you could set up a network where unless all 3 of them collude your combo-firewall is safe.

    57. Re:Ken Thompson, Anyone? by RabidReindeer · · Score: 2

      I don't know that I'd call assembler "exploits", since in assembler you're allowed to do any darn thing you want to. High-level languages exist as much to limit that ability as anything else.

      None of the early FORTRAN implementations I worked with supported pointers as such. But the Primos OS was mostly written in FORTRAN (in fact the instruction set was optimized for FORTRAN), and I think there was a pre-defined integer array whose first element was memory location 0 and each word in that array thus had a 1-to-1 correspondence to a memory address.

      On IBM machines, RAM was byte-addressable, so you would use a character array instead. FORTRAN wasn't a good fit for that but COBOL was. While the language didn't come with a built-in memory map array, it's about 5 lines of assembly language to add one in an external library.

      The early Unix C compilers also generated assembly language. The original C++ generated C, and as an early licensee, at one point I was running C++-to-C-to-assembler-to.aout builds. I never worked with it, but supposedly Xerox had a FORTRAN that allowed inline assembler.

      Regardless of the history, though, there are apples and oranges here. One is an discussion of an exploiting compiler. The other is a discussion of exploitable (but otherwise innocent) languages and runtime environments. Either one is fair game for the maliciously-inclined, but an exploiting compiler is especially insidious, since I can avoid exploits in code I write myself, but have no control over any back doors that a compiler, linker, or system loader might inject.

      Fortunately, modern OS environments are so hellishly complex that specialized exploits are virtually guaranteed to fail in very visible ways on at least a few of the thousands of permutations of systems and work environments in use across the planet. The only practical way to do that sort of exploit is when you are targeting a very specific environment, such as Iranian Windows machines running a certain brand and model of centrifuge. And even then, the unrelated incidental victims are likely to expose it.

    58. Re:Ken Thompson, Anyone? by fuzzywig · · Score: 2

      I'm betting that there's been a increase in people checking both the source of their favourite OSS encryption (et al) software, and checking their compilers in the last week or so.

    59. Re:Ken Thompson, Anyone? by Lumpy · · Score: 1

      Bingo!

      --
      Do not look at laser with remaining good eye.
    60. Re:Ken Thompson, Anyone? by FictionPimp · · Score: 2

      You are advocating security though obscurity?

    61. Re:Ken Thompson, Anyone? by u38cg · · Score: 1

      RTFL is an option...

      --
      [FUCK BETA]
    62. Re:Ken Thompson, Anyone? by Zaiff+Urgulbunger · · Score: 1

      One possible snag with using older kit is that you also need to cover microcode in any devices connected to them, so you also need to obtain old but still working floppy/optical/hard drives - otherwise, hypothetically, a modern storage device might modify anything it thinks looks like executable!

    63. Re:Ken Thompson, Anyone? by Burz · · Score: 1

      And here I thought all the security through obscurity advocates had left /. a decade ago.

      To be useful with networks and data from the outside world, I think an individual coder would make a lot of the same mistakes that were common in recent history. Don't bet on it being able to withstand a good fuzzing.

    64. Re:Ken Thompson, Anyone? by GargamelSpaceman · · Score: 1

      And the NSA are experts. And the military is a big customer. All you have to do is requrire backdoor-enabled encryption in all military hardware ( it could be secure against anyone without the NSA keys ) or give the most prestigious security certifications to only the stuff with the backdoors, justifying it on some other grounds, and you don't need to send national security letters. People will do it voluntarily - Don't you want to use the security that the experts at the NSA have vetted? And if it weren't secure why would the military be buying it? They're eating their own dogfood, so it can't be bad right?

      Also if you're a for profit company you don't REALLY give a damn if the NSA is spying. You're out for money.

      And if you are not using software designed for profit, but talking to/through software that is compromised, are you compromised? Has the protocol been negotiated to a level friendly to snooping? You only have control over the software you are running yourself, if you had any.

      Leaving messages on the mens room wall spreads info anonymously. I don't think they'll ever crack that without looking at more cracks than they want.

      --
      ...
    65. Re:Ken Thompson, Anyone? by allaunjsilverfox2 · · Score: 3, Interesting

      Maybe modern ones, but if you go back a few generations your chances of it existing drop drastically. so what you do for high security....

      1 - rely on OLDER hardware. Stuff from before the past two administrations would have a significantly higher chance of not having government back doors. Clinton era computers to start with.

      2 - use a completely different architecture. ARM is your best friend here or SPARC. The chances of SPARC having this are insanely small

      3 - Get processors from your countries "enemy" Russians dont use Intel processors for their KGB and Government operations. If they did they would be the biggest morons on the planet. Find out what they use and try to source them through the black or grey market channels.

      Welcome to the new world of underground computer science. Oh and keep your mouths shut. Don't do stupid shit like bragging as to what you have and where you got it. I'd say "hack the planet" but the safest thing is to go off the net and transfer data via offline means for the highest security.

      You forgot a 4th option. If you were TRULY paranoid, you could write your own CPU and emulate in a FPGA. You would also have to design the fpga on a wire wrapped CPU, which would suck, but it's possible.

      --
      Restore the madness of youth's lechery
    66. Re:Ken Thompson, Anyone? by Lawrence_Bird · · Score: 1

      No - you can't trust code that you either can't read or can't understand (either because of your lack of knowledge or the sheer number of lines and complexity of the code). While I may have a basic understanding of lexx,yacc and compilers in general I doubt I ever would be able to pick out a flaw.

    67. Re:Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

      I tend to agree with the statement about not trusting what you didn't create. The back door problem pretty well negates all security unless you do your work in such a way that the computer generating and encrypting the message is not on the Internet and the data is filtered through a second device that is internet connected. Better yet use some really dumb device like an Arduino and use it to do the file transfer with only accepted file types etc then move it to the internet. As to the encryption guys. AES is broke and has been for some time. PGP suffers from the fact that Sum = High_Prime * Low_Prime. High_Prime = C+D and Low Prime = C-D. This means that Sum = C(Squared) - D(Squared) It all resolves C(Squared) + C = Sum. Fun isn't it! That is 2 encryptions down. Shall I go on? The only real problem here is that the NSA keeps trying to make sure we don't have any security. We need it for our most basic things like banking! Isn't it about time we sink these robbers where the sun doesn't shine?

    68. Re:Ken Thompson, Anyone? by cavreader · · Score: 1

      "It is not easy to discover vulnerabilities through code examination."

      This is blasphemy to all those who argue that if they just had the source code the "many eyes" approach could find and remove any security holes found.

    69. Re:Ken Thompson, Anyone? by smash · · Score: 1

      I"m not ADVOCATING IT. I'm saying there is a difference between deliberate malice, and incompetence.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    70. Re: Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

      But the paper suggests using two different compilers to produce the same binary which is nearly impossible as they will optimize and order things differently. Hell, you can't even get the same binary from two different versions of gcc.

    71. Re:Ken Thompson, Anyone? by Jeremiah+Cornelius · · Score: 1

      It is a misunderstanding.

      You are freer in getting them fixed. You usually - not always - find them in derived objects, deployed as intended.

      --
      "Flyin' in just a sweet place,
      Never been known to fail..."
    72. Re:Ken Thompson, Anyone? by marxmarv · · Score: 1

      Well, good. Religion has no place outside of religion, and certainly not in math.

      --
      /. -- the Free Republic of technology.
    73. Re:Ken Thompson, Anyone? by Aaden42 · · Score: 3, Insightful

      1 Russian Firewall in front of one US firewall in front of one Chinese firewall

      So you’re looking for 100% packet loss? Why not just unplug the cord. Would be cheaper, less stuff to patch...

    74. Re:Ken Thompson, Anyone? by chill · · Score: 1

      If you haven't already, you should read thru this. Both the article and, if you're seriously interested, the accompanying PhD thesis document.

      David A. Wheelerâ(TM)s Page on Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers

      --
      Learning HOW to think is more important than learning WHAT to think.
    75. Re:Ken Thompson, Anyone? by Jeremiah+Cornelius · · Score: 1

      Thanks. It definitely goes on my reference shelf. Leisure reading, when time again permits. ;-)

      --
      "Flyin' in just a sweet place,
      Never been known to fail..."
    76. Re:Ken Thompson, Anyone? by romons · · Score: 1

      THIS is the 1%. These are the perpetrators of NSA surveillance, to further their needs...NOT yours. People with connections to these firms need to be removed from any position of power, especially government. Their future actions need to be monitored by the rest of society, if for no other reason then to limit their power.

      While this may all be true, there is really nothing you can do about it. They own you and your kids, and they will continue to own you and your kids. All you can really do is keep your head under the radar, and hope to hell they don't spot you. If they do, they have cyber weapons, armies, crime organizations, banks (but I repeat myself) and police to deal with you.

      In order to win, you need to play another game. They already have all the property, and have hotels on all of them. The best you can do is concede, and try another game. There are lots of them to choose from. Religion, Science, Philosophy, Sports. Maybe even sailing, running, hiking. You and I, however, are never going to win at their game, which is Monopoly, until this civilization turns belly up. And then, you'll probably be excluded as well, because whoever takes charge will keep you out of their club, which typically consists of the folks who are the most ruthless. Chances are, you are not one of them.

      Interesting side note. Turns out that genetic testing concludes that most europeans today come from the stock of kings. If you are from Mongolia, you are quite likely to be descended from Genghis Khan. Poor people just don't survive as well as the 1%. That means breeding, as a game, is probably also lost to you as well, since the poor will starve, or maybe be eaten in whatever apocalypse comes next.

      --
      Go to Heaven for the climate, Hell for the company -- Mark Twain
    77. Re: Ken Thompson, Anyone? by NateTech · · Score: 1

      Every processor core since Pentium from a U.S. company, was designed in Israel.

      --
      +++OK ATH
    78. Re:Ken Thompson, Anyone? by fustakrakich · · Score: 1

      Well since it's turtles all the way down, that would be a rather unique rabbit hole.

      --
      “He’s not deformed, he’s just drunk!”
    79. Re: Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

      Lies.

      Like he said SPARC and others, or dont you know anything at all about processors in general.

    80. Re:Ken Thompson, Anyone? by Lumpy · · Score: 1

      Nothing obscure at all, talking about security through not buying things with backdoors embedded in them.

      --
      Do not look at laser with remaining good eye.
    81. Re:Ken Thompson, Anyone? by LO0G · · Score: 1

      Here's the problem: When did you last perform this analysis? If you didn't do it, when did someone else last do it? How do you know you can trust the person who claims to have last done the analysis?

      Ultimately you MUST trust someone. Because all modern systems are far too complex for any one person (or team of persons) to fully understand and analyze. It would NOT be unreasonable to spread a single backdoor across multiple components (especially if the implementation of those components isn't the best documented code). Such a backdoor would be extremely difficult to find even WITH assembly and source code auditing.

    82. Re:Ken Thompson, Anyone? by FriendlyLurker · · Score: 1

      I quoted you here, nice ideas.

    83. Re:Ken Thompson, Anyone? by TheRealLifeboy · · Score: 1

      Is this a feasible project, ie can I start a new project on SourceForge to do this?

      I'm not joking! Surely this should be a priority, not so?

    84. Re:Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

      You don't need to be sure of this, you just need to be sure it's not the same infection, but you do probably want to avoid compilers from common parents.

    85. Re:Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

      But software like PROMIS had trojans already in the 80s
      http://www.wired.com/wired/archive/1.01/inslaw.html?topic=&topic_set=
      http://www.fromthewilderness.com/free/pandora/052401_promis.html

    86. Re:Ken Thompson, Anyone? by someone1234 · · Score: 1

      You vastly misunderstood me. Copying the binary to another system is to defeat the on-the-fly rootkit that would alter the data on read.
      Nowhere near i suggested that you recompile the code.
      You check the BINARY on two different architectures.

      --
      Patents Drive Free Software as Hurricanes Drive Construction Industry
  9. Comparatively by ciscon · · Score: 0

    There are no guarantees, but I'm much more concerned with what Microsoft/Oracle/Cisco does than what Redhat, Ubuntu, or OpenBSD throws into their builds/source.

  10. There is no such thing as "Security"... by dryriver · · Score: 3, Insightful

    or "Privacy" anymore. Perhaps there hasn't been for the last decade or so. We just didn't know at the time. ---- Enjoy your 21st Century. As long as people fail to defend their basic rights, there will not be such a thing as "security" or "privacy" again. My 2 Cents...

    --
    Why did the chicken cross the road? Because Elon Musk put an AI chip in its head.
    1. Re:There is no such thing as "Security"... by donb3 · · Score: 1

      or "Privacy" anymore. Perhaps there hasn't been for the last decade or so. .

      Relatives of mine who are really smart software engineers do not have Facebook accounts and little to no web presence. They are over 50, so some of this may be generational, but for years, I wondered what they knew that they couldn't tell me. Now, I know.

    2. Re:There is no such thing as "Security"... by Anonymous Coward · · Score: 0

      I don't have a FB account. Or G+, or Twitter. Yes, there's a reason. It's the same reason I checked the "anonymous" box just now.

    3. Re:There is no such thing as "Security"... by Anonymous Coward · · Score: 1

      What, you're a paranoid delusional with a persecution complex? Honestly, I don't know who you are but I'd put vast amounts of money on two facts:
      1) I wouldn't give a flying fuck if I had your home address and a copy of your keys
      2) Neither would the NSA
      Honestly man, grow *up*. Just because they're logging vast amounts of data doesn't for the slightest minute mean they can, or even will, analyze it all. They have to focus, and I very strongly doubt that you've ever done anything in your life that would get them to focus on you.

      This is not a statement that what the NSA do isn't beyond remit. It is, and that has to be addressed. But seriously, just listen to yourself. There's a vast gulf between acknowledging that the NSA are beyond remit and have to be restrained, and paranoid delusions. The internet is so vast, and the data you can pull from it so overwhelmingly so, that unless they specifically focus on you you'd have to really try to get them to even notice you exist - and even then in their morning meeting they'd probably conclude you're a nobody. And that goes for whether you're unemployed all the way up to whether you're a professor of chemical engineering, and beyond. There's just too much data and too little time and too few people to regulate the activity.

    4. Re:There is no such thing as "Security"... by AHuxley · · Score: 1

      Re anything in your life that would get them to focus on you....
      Thats very trusting. Work like http://en.wikipedia.org/wiki/Main_Core should hint to the average person that the tracking is not restrained over many years.
      As color of law reshapes basic legal protections data about your can be shared with huge numbers of cleared staff/contractors, locally and very politically.
      Much data when compressed, filed has never been the problem. Too little time and too few people to regulate the activity ?????.... They can keep and use your phone usage data for life by default with no court needed. Re "too few people" - computers via firms and contractors sort public and private data every day and sell it in bulk.
      The number of cleared workers, contractors and expert staff is up over the past 10 years.
      The only issue was a legal one and that can now be understood.

      --
      Domestic spying is now "Benign Information Gathering"
  11. Linux and RdRand by Digana · · Score: 5, Informative

    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.

    1. Re:Linux and RdRand by Greyfox · · Score: 4, Funny

      Yeah yeah and I'm having to go through the last couple years of E-mails and tell the various paranoid whackos, slightly demented old relatives and that one guy with the tinfoil that they were right and I was wrong. How do you think that makes ME feel?

      --

      I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

    2. Re:Linux and RdRand by KiloByte · · Score: 1

      /dev/random has been fixed, anything that uses get_random_int() is not. And that function could trivially be modified to mix RdRand's output rather than use it exclusively.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    3. Re:Linux and RdRand by Anonymous Coward · · Score: 0

      Like an asshat. Which isn't undeserved - especially after insulting someone with the tinfoil label.

    4. Re:Linux and RdRand by 1s44c · · Score: 1

      So Linus either doesn't know how critical good quality random data is to encryption or was deliberately weakening encryption in the kernel.

      Linus rarely seems like he doesn't know what he is talking about.

    5. Re:Linux and RdRand by mdielmann · · Score: 1

      Is it a label if he's actually wearing a tinfoil hat? Is the insult really because it's probably aluminum? Or is it an actual vintage tinfoil hat?

      --
      Sure I'm paranoid, but am I paranoid enough?
    6. Re:Linux and RdRand by Anonymous Coward · · Score: 0

      Torvalds is a large soiled douchebag. He's pissed off just about every good Linux developer over the last two decades.

    7. Re:Linux and RdRand by Greyfox · · Score: 2

      No! It seemed like an ENTIRELY reasonable position, at the time, that there was NO CONCEIVABLE WAY that "they" would be listening to EVERYONE! That would be a COMPLETELY USELESS waste of resources to catch then probably-less-than-a-thousand people who were ACTUAL THREATS to security! People, I might add, who already knew NOT TO USE THE INTERNET for communication! "Mom," I told mom, in a reassuring tone of voice, "go ahead and use the internet. 'They' already know you're not a threat. Their file on you says 'mostly harmless.'" She's gone dark since this story broke. Now I'm going to have to find a motherfucking CAVE somewhere in Florida and send a motherfucking CARRIER PIGEON there with a note that says "Fine, you were right." AND I'm going to have to give tinfoil-hat-guy $20 next time I see him, because if he was right about THAT, then ALL BETS ARE OFF! Now I'm having to rethink my position on ALIEN MIND CONTROL rays! Thank you VERY GODDAMN MUCH, NSA!

      --

      I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

    8. Re:Linux and RdRand by gweihir · · Score: 1

      The way I read it is that RdRand is used, but only as one part. T'so rightfully called Linus an idiot on this, because Linux wanted to use it exclusively. Now, from the _published_ specs, Linux was right, but T'so actually understands security, while Linus has demonstrated quite a few times that he does not. I do not think he is subverted either, just sometimes full of himself without being justified (usually he is). Not a problem, there are some quite smart people in there and subverting them all is likely impossible. In fact, subverting people is bloody hard and risky. Usually you try to insert your own people instead.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    9. Re:Linux and RdRand by gweihir · · Score: 1

      Linus has messed up on security things before. I think he just has a selective blindness to his incompetence in this specific area. The other kernel devs compensate nicely.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    10. Re:Linux and RdRand by TechyImmigrant · · Score: 1

      Fixed in the sense that no one uses it because it always blocks.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    11. Re:Linux and RdRand by TechyImmigrant · · Score: 1

      Read what Linus had to say this on the LKML. His logic was and still is sound.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    12. Re:Linux and RdRand by Anonymous Coward · · Score: 0

      Now I'm going to have to find a motherfucking CAVE somewhere in Florida and send a motherfucking CARRIER PIGEON there

      Whatever makes her feel good.

    13. Re: Linux and RdRand by Anonymous Coward · · Score: 0

      Insulted? Please do read the thread on lkml and see for yourself what Linus said: https://lkml.org/lkml/2011/7/30/116

    14. Re:Linux and RdRand by dotancohen · · Score: 1

      This is rather insightful, but doesn't stand merit on it's own. Can you find other instances of Linux seemingly deliberately weakening Linux security mechanisms?

      --
      It is dangerous to be right when the government is wrong.
    15. Re:Linux and RdRand by gishzida · · Score: 1

      And don't forget the Reptilians who are *REALLY* the ones behind all of this...

    16. Re:Linux and RdRand by Anonymous Coward · · Score: 0

      "Insulted repeatedly"? Do read the mail thread for yourself: http://thread.gmane.org/gmane.linux.kernel/1173350/

    17. Re:Linux and RdRand by 1s44c · · Score: 1

      This is rather insightful, but doesn't stand merit on it's own. Can you find other instances of Linux seemingly deliberately weakening Linux security mechanisms?

      Can I find? Maybe. Will I? Hell no! Have you seen the size of the kernel these days? And the size of the LKML? You're asking me to move mountains.

      It seems more likely Linus was just plain wrong rather than in the pocket of the NSA. Linus really should have known better then to trust an untrustworthy source of entropy but everyone is stupid every once in a while.

    18. Re:Linux and RdRand by dotancohen · · Score: 1

      I wasn't expecting you to go out and start hunting. I meant that if you are to imply that Linux is poisoning Linux, then more than a single incident would have to be shown.

      However, it is probably not a bad idea for someone to go out and actually start hunting! Thank you for the insight.

      --
      It is dangerous to be right when the government is wrong.
  12. You can't trust any mainstream Linux distro by 1s44c · · Score: 1

    It's sad but you can't trust any mainstream Linux distro created by a US company, and you likely can't trust any created in other countries either. I'm not saying that as a pro-windows troll because you can trust MS's efforts even less.

    I believe you can trust OpenBSD totally but it lacks many of the features and much of the convenience of the main Linux distros. It is rock solid and utterly secure though, and the man pages are actually better than any Linux distro I've ever seen.

    The possibly bigger problem is that no matter what OS you use you can't trust SSL's broken certificate system either because the public certificate authorities are corruptible. And before someone says create your own CA, sure, for internal sites, but you can't do that for someone else's website.

    1. Re:You can't trust any mainstream Linux distro by Noryungi · · Score: 4, Interesting

      I believe you can trust OpenBSD totally but it lacks many of the features and much of the convenience of the main Linux distros. It is rock solid and utterly secure though, and the man pages are actually better than any Linux distro I've ever seen.

      Three points:

      1) See the above discussion: you cannot trust anything that you did not create and compile yourself. With a compiler you wrote yourself. On a machine you created yourself from the ground up, that is not connected to any network in any way. OpenBSD does not make any difference if your compiler or toolchain is compromised.

      2) Speaking of which, I cannot but note that OpenBSD had a little kerfuffle a while back, about a backdoot planted by the FBI in the OS? (Source 1) (Source 2). I am willing to bet that (a) it's perfectly possible (though not likely), (b) if it was done, it was not by the FBI and (c) that the dev @openbsd.org are, right now, taking another long and hard look at the incriminated code.

      3) Finally OpenBSD lacking features and convenience? Care to support that statement? I have a couple of computers running OpenBSD here, and they are just as nice - or even nicer - to use than any Linux. Besides, you don't choose OpenBSD for convenience - you use it for its security. Period.

      The possibly bigger problem is that no matter what OS you use you can't trust SSL's broken certificate system either because the public certificate authorities are corruptible. And before someone says create your own CA, sure, for internal sites, but you can't do that for someone else's website.

      This goes way beyond a simple question of OpenSSL certificates - think OpenSSH and VPN security being compromised, and you will have a small idea of the sh*tstorm brewing right now.

      --
      The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
    2. Re:You can't trust any mainstream Linux distro by 1s44c · · Score: 1

      Point 1 - You're right of course. OpenBSD uses gcc too and it's unknown how much we can trust CPUs made by AMD or Intel.
      Point 2 - Yep, saw that. I got the impression that backdoor may never have existed or if it did it was wiped out quickly. There isn't an easy way to prove it doesn't exist though.
      Point 3 - There isn't anything like Ubuntu for OpenBSD, it doesn't 'just work' with modern hardware on things like laptops. OpenBSD is a very nice OS but it's not got cool Linux toys like LVM, ext4, systemd, easy errata updates, and so on. I love OpenBSD and run it on firewalls but it's not the same easy end user OS that Linux is. Conversely OpenBSD's pf beats Linux's iptables hands down so it's horses for courses.

    3. Re:You can't trust any mainstream Linux distro by HiThere · · Score: 1

      I don't know about currently, but in the past I believe that NO Linux system was secure. Think of a cross between login and rainbow tables.

      That said, I find it amazing that simple precautions that could be default aren't even easy. E.g., after the first failed login you need to wait 2 seconds before you can try again. Square the delay for each successive failure. (2, 4, 16, ... seconds) (It's still reasonable to log failures, but if you don't keep the penetration from happening, the log can just disappear.)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    4. Re:You can't trust any mainstream Linux distro by Anonymous Coward · · Score: 0

      I suspect most people fail to realize that to build your own machine "from the ground up" means not to trust any circuits nor ICs you didn't design and fabricate yourself. It certainly doesn't mean to buy some PC components and stuff them into a box with extra dorky anodized aluminum and colorful LEDs. And, not only do you need to write your own compiler, you need to compile and assemble it yourself, before you can start using it to compile more stuff. That will take a long time on your wire-wrapped computer made with only discrete transistors and such!

      But since you've clearly thought about this a bit, I'll also suggest that you need to evaluate your own programming before you decide whether to trust yourself to perform all of the steps outlined above. Have you had any subtle backdoors embedded in your education that would lead you to construct a faulty computer or compiler that others could exploit...?

    5. Re:You can't trust any mainstream Linux distro by Culture20 · · Score: 1

      if you don't keep the penetration from happening, the log can just disappear.

      not if you copy the logs to another server and constantly print the logs with a line printer.

    6. Re:You can't trust any mainstream Linux distro by Anonymous Coward · · Score: 0

      You also can't trust Theo de Raadt's *practices* on security. OpenSSH still keeps its host keys, and by default its private keys, in plain text. And the maintainers of OpenSSH, and upstream of OpenBSD, have made clear that they do not consider storing passwords or keys unprotected in plain text to be a problem, because "you have to trust the machine you're working on, or you shouldn't be using it"

      There was also a glaring remote root exploit exposed in OpenSSH back in.... 1993? So let's not pretend that OpenBSD or its components have ever been immune from major security flaws. And do not waste my time saying OpenBSD has anything resembling the available scientific analysis software, graphical management tools, or evern hardware drivers availble to evne the most lame modern Linux.

    7. Re:You can't trust any mainstream Linux distro by Anonymous Coward · · Score: 0

      4) All BSD operating systems come with binary firmware... So much for security and freedom in the BSD land.

  13. Be afraid by Anonymous Coward · · Score: 1

    If the powers that be had their way, you would do nothing but lie in your bed with the sheets pulled up around your chin, your eyes darting left and right. Nice life you have there. It would be a shame if something... happened to it.

    Meanwhile, if you care about keeping your data private, don't use encryption and think that you can just trust it all to keep it hidden. Your data might be safe, it might not. Be smarter. Learn from baseball players. They keep their signals safe, and they don't even need a computer to do it.

  14. Subversion possible but unlikely and temporary by Todd+Knarr · · Score: 4, Insightful

    It's possible the NSA did something bad to the code, but it's not likely and it won't last.

    For the "not likely" part, code accepted into Linux projects tends to be reviewed. The NSA can't be too obvious about any backdoors or holes they try to put in, or at least one of the reviewers is going to go "Hey, WTF is this? That's not right. Fix it.". and the change will be rejected. That's even more true with the kernel itself where changes go through multiple levels of review before being accepted and the people doing the reviewing pretty much know their stuff. My bet would be that the only thing that might get through would be subtle and exotic modifications to the crypto algorithms themselves to render them less secure than they ought to be.

    And that brings us to the "not going to last" part. Now that the NSA's trickery is known, the crypto experts are going to be looking at crypto implementations. And all the source code for Linux projects is right there to look at. If a weakness were introduced, it's going to be visible to the experts and it'll get fixed.

    That leaves only the standard external points of attack: the NSA getting CAs to issue it valid certificates with false subjects so they can impersonate sites and servers, encryption standards that permit "null" (no encryption) as a valid encryption option allowing the NSA to tweak servers to disable encryption entirely, that sort of thing. There's no technical solution to those, but they're easier to monitor for.

    1. Re:Subversion possible but unlikely and temporary by Anonymous Coward · · Score: 0

      You're a naive idiot. Have a look at professionally-obfuscated C code as an example, then come back and say that casual patch-reviewing is enough.

    2. Re:Subversion possible but unlikely and temporary by Todd+Knarr · · Score: 4, Interesting

      That won't even make it through the casual review. Most project maintainers don't like code that's impenetrable. Unless it's a fix for a critical bug that nobody else even has a proposal for a fix for, they're going to take one look at obfuscated code and toss it back with a "No thanks.". Especially if it's coming from a source they don't recognize, because messy complex obfuscated code also tends to be buggy unreliable unmaintainable code and they don't want the headache.

    3. Re:Subversion possible but unlikely and temporary by Anonymous Coward · · Score: 1

      Did you know that, LINUX FOUNDATION is based in CA, US of A ? Do you know what that means ?
      It means it must comply with the rules and laws and orders and also it *MUST* play nice with NSA for national interests and security of US of A and interests of it.

      Think about it this way: Any US citizen (i.e. Linus Torvalds) who is contributing to Linux can be forced to implant anything NSA demands. Pledge of Allegiance ?

      Now what ? All your theory of maintainers, reviewers all that *IS BULL$HiT*.

    4. Re:Subversion possible but unlikely and temporary by gweihir · · Score: 1

      Indeed. I completely agree. What NSA sabotage of critical infrastructure is known is weakening random number generation (subtle, and to find them you need somebody that is both an expert on the use of crypto and somebody that can program, not so many of those around) and ECC constants (even more subtle, requires specific hardcore mathematical skills, _and_ may not be detectable except when you know how the backdoor was constructed).

      The attack on the SSL certificate system is both obvious, easy (if you have money and can coerce or hack them), and covers a lot of traffic. It stems form the fundamental flaw that people allow CAs to generate keys for them (and hence the CAs have the keys), instead generating them by themselves and merely letting the CA sign them. The latter was the original idea, but it was deemed (likely correct) that most people are incapable of generating their own keys.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    5. Re:Subversion possible but unlikely and temporary by gweihir · · Score: 2

      Obfuscated code is pretty obvious. There is a large body of conventions you have to follow to get anything into the kernel, precisely to prevent unreadable code. I have looked at a few kernel security patches and they were all clan and clear.

      If you do not follow strong simplicity guidelines, a project the size of the Linux kernel will just fail by eventually becoming unmaintainable.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    6. Re:Subversion possible but unlikely and temporary by Anonymous Coward · · Score: 0

      Of course Subversion is possible! I use svn practically daily.

    7. Re:Subversion possible but unlikely and temporary by Anonymous Coward · · Score: 0

      That won't even make it through the casual review. Most project maintainers don't like code that's impenetrable. Unless it's a fix for a critical bug that nobody else even has a proposal for a fix for, they're going to take one look at obfuscated code and toss it back with a "No thanks.". Especially if it's coming from a source they don't recognize, because messy complex obfuscated code also tends to be buggy unreliable unmaintainable code and they don't want the headache.

      He probably means something more along the lines of The Underhanded C Contest. For a quick example, here's the one from earlier in this comment section about a kernel backdoor that was attempted to be inserted:

                  if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
                              retval = -EINVAL;

      Sure if you only look at these two lines, you may easily see it's an assignment and not a test. Shoved into a few other thousand lines, though, it's probably going to evade visual scrutiny. This is also a direct consequence of the language involved, a logic error in an algorithm can be far more subtle.

      A previous year's Underhanded C Contest finalist made a 'programming mistake' in an RC4 implementation that would slowly weaken the stream until it was only plaintext. A visual inspection and even a quick execution test would not show the problem.

    8. Re:Subversion possible but unlikely and temporary by Todd+Knarr · · Score: 1

      Why would you need to look at the code to find that? The compiler will flag that one (assignment within an 'if' statement test is extremely questionable, it's more likely a typo than correct code) and the code will be rejected as "Fails to compile cleanly.". Adding the pragma or compile option to suppress that warning likewise will get the code rejected because you shouldn't need to suppress that warning to get a clean compile.

    9. Re:Subversion possible but unlikely and temporary by Anonymous Coward · · Score: 0

      You specified casual review and impenetrable code. The assignment example was indeed caught, but the point I was trying to make is that it was deliberately designed to attempt to pass human visual scrutiny, not the compiler. Anyway, this was ten years ago, and so comments from the dawn of time:

      "Ah, but it wouldn’t give you a warning because its encapsulated in an extra set of ()’s. Actually it is a rather elegant hack."

      "Yup, Trent’s right. I tested something similar. It passed just fine using 'gcc -Wall -pendantic -O'. Brrr quite an evil little thing, and very easy for a reviewer to miss, as easy as missing a typo."

      This is a decade-old example of abusing a language syntax for malicious purposes. I don't know what to tell you if you think the compiler is going to save you in the event of a syntactically valid, but purposefully flawed, implementation.

  15. Pointless Worrying by Luthair · · Score: 3, Insightful

    The NSA doesn't really need to have backdoors written into the systems, they have a lot of exploits in their bag of tricks that they've bought or found. Unfortunately the NSA only needs to find one exploit, but truly secure systems we need to find and fix them all :/

    1. Re:Pointless Worrying by chr1st1anSoldier · · Score: 2

      Also, all they need is to route traffic over their hardware. Sure, you can use SSL and TLS, but I recall an article about the NSA have a majority of the keys from Certificate Authorities. Even if they do not have the correct CA key, I am sure they have a farm of computers ready to brute force crack the key and get the information they need. And no, this doesn't give access to data stored locally on your hard drive, but if you ever upload that data anywhere it can be captured.

    2. Re:Pointless Worrying by Lorien_the_first_one · · Score: 1

      A farm of computers, eh? How big is it? Here's an article from Schneier that discusses the physical limitations of computation relative to brute force attacks for private keys:

      https://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html

      To put it simply, brute force attacks are about trying every possible combination in a counter. Just to run a counter through 256 bits, You're going to need all the power of the sun for 32 years or more, or a supernova. Take your pick. That doesn't include power for any other useful computation. And then of course, there is time. How much time do you have?

      The computer scientists of the world who believe in freedom will be happy to put the kibosh on on any code that permits side-attacks on encryption software. That is where the weakness is more likely to be, not the encryption algorithms.

      Now I could be completely wrong about this, but based on the best available information I have, I don't think anyone is capable of brute force attacks against strong encryption except for poorly implemented crypto or really weak passwords.

      --
      The diversity and expression of human opinion is essential to human survival.
    3. Re:Pointless Worrying by SuricouRaven · · Score: 2

      The use of all that power isn't to brute force directly. It's to render possible other attacks that can reduce the key space, like side-channel attacks or known weaknesses in the RNG.

    4. Re:Pointless Worrying by SuricouRaven · · Score: 2

      Specifically the leaks indicate - and this is based largely on speculation - that they have some sort of central database. That means they can collect keys opportunistically (Trojans, interception of cleartext communications containing the key like VM migrations, cracking via advanced mathematics, old-fashioned espionage, secret court orders, backdoors, etc) whenever they get a chance. So when they need to decrypt a communication, there's a chance the key is already in the database - even if they only obtained it years previously and didn't realise at the time it could be useful.

    5. Re:Pointless Worrying by marxmarv · · Score: 1

      They have lots and lots of things for every occasion. And remembers, keys do not only encrypt, but authenticate. How does it feel having a copy of one's car keys left with the NSA, especially post-Hastings?

      --
      /. -- the Free Republic of technology.
  16. What about the hardware or compiler? by BitterOak · · Score: 4, Insightful

    The big concern is back doors built into distributed binaries.

    And what about the hardware? And how can you be sure the compilers aren't putting a little something extra into the binaries. There are so many places for NSA malware to hide it's scary. Could be in the BIOS, could be in the keyboard or graphics firmware, could be in the kernel placed there by a malicious compiler. Could be added to the kernel if some other trojan horse is allowed to run. And just because the kernel, etc. are open source doesn't mean they have perfect security. The operating system is incredibly complex, and all it takes is one flaw in one piece of code with root privileges (or without if a local privilege escalation vulnerability exists anywhere on the system, which it surely does), and that can be exploited to deliver a payload into the kernel (or BIOS, or something else). Really, if the NSA wants to see what you're doing on your Linux system, rest assured, they can.

    --
    If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
    1. Re:What about the hardware or compiler? by AHuxley · · Score: 1

      Recall the cell phone 'testing' layer that was able to look at every key press/data input before the "open" OS apps could https?
      Also recall the hardware and software networking products used too.

      --
      Domestic spying is now "Benign Information Gathering"
    2. Re:What about the hardware or compiler? by Anonymous Coward · · Score: 0

      Yup. Basically at some point or another, you have to trust somebody . Unless you make your hardware circuits from scratch then write a bootstrapping compiler in binary.

    3. Re:What about the hardware or compiler? by Anonymous Coward · · Score: 0

      I agree that complexity adds to the possibility of 'hiding in plain sight', but I would take your hardware add-on and say that regardless of software, hardware is a permanent way of embedding snoopology into a computer. The latest add on is the secure boot protocol. Microsoft insisted on it. I'm sure they would have been willing participants in any ruse by the NSA to add mail-home technology to every computer made.

  17. Absolute Anonymity by Anonymous Coward · · Score: 0

    Absolute Anonymity is a weapon of mass destruction and will never be allowed by any government.

    1. Re:Absolute Anonymity by Tiger+Smile · · Score: 1

      Absolute Anonymity is a weapon of mass destruction and will never be allowed by any government.

      Who said that?

      --
      -- Prepared at the direction of, or to be sent to Legal Counsel, in anticipation of litigation. Attorney Client Pri
  18. Why no mention of SELinux? by Anonymous Coward · · Score: 0

    Seems like the obvious choice if you want to be more secure, because it's NSA appr.... wait a second.

  19. Until proven otherwise... by Anonymous Coward · · Score: 0

    ... we can only assume that the Linux Kernel is compromised and has government (and not necessarily the US government) backdoors in it.

  20. nothing's safe, but there are obvious things to do by hedrick · · Score: 5, Interesting

    No, but there's no reason to think that Linux is worse than anything else, and it's probably easier to fix.

    If I were Linus I'd be putting together a small team of people who have been with Linux for years to begin assessing things. From Gilmour's posting it seems clear that IPsec and VPN functionality will need major change. Other things to audit include crypto libraries, both in Linux and the browsers, and the random number generators.

    But certainly some examination of SELinux and other portions are also needed.

    I don't see how anyone can answer the original question without doing some serious assessment. However I'm a bit skpetical whether this problem can actually be fixed at all. We don't know what things have been subverted, and what level of access the NSA and their equivalents in other countries have had to be code and algorithm design. They probably have access to more resources than the Linux community does.

  21. what we will learn next by Max_W · · Score: 1

    I would not be surprised if visionaries and leaders of the computer industry, including FOSS, turn out to be generals, admirals and colonels. And that the leading technological companies are just the departments of the single organization.

    1. Re:what we will learn next by u38cg · · Score: 1

      It doesn't work like that. But we do know the NSA has people in place inside every major Western telecoms/data firm. Now think for a second about the capabilities that could be inserted by someone smart enough to be hired by NSA *and* Google.

      --
      [FUCK BETA]
  22. Government? What About Other Bad Guys? by rueger · · Score: 5, Insightful

    We are being told - and some of us suspected as much for a very long time - that the NSA &Co track everything we do, and have the ability de-encrypt much of what we think is secure; whether through brute force, exploits, backdoors, or corporate collusion.

    Surely we should also assume that there are other criminal and/or hacker groups with the resources or skills to gain similar access? Another case of "once they know it can be done, you can't turn back."

    I honestly believe that we're finally at the point where the reasonable assumption is that nothing is secure, and that you should act accordingly.

    1. Re:Government? What About Other Bad Guys? by AHuxley · · Score: 1

      Similar access would be Russia and China. The CIA and MI6 would bait that side and wait. The codes along the international pipes has always been good. If not the Soviet Union would have understood the US a lot better and not needed to resort to so many risky/failed human/hardware efforts.
      Nothing allowed to be sold or free over time is secure from govs but the products/projects will on average let you buy/sell/trade with commercial confidence.

      --
      Domestic spying is now "Benign Information Gathering"
    2. Re:Government? What About Other Bad Guys? by aztracker1 · · Score: 1

      But that doesn't mean you shouldn't try... if you make an effort to do something that causes $BADGUY$ even a few minutes of extra effort per transaction to decrypt.. that all adds up.

      bcrypt/scrypt your passwords with a crypto/appropriate salt generator. Use strong tokens against your passwords (such as bcrypt/scrypt) for Cipher/IV for 2-way encryption. Push seed/salt bytes at the beginning of your 2-way encrypted data that goes over a network connection (or into a cookie). As for private/public based encryption methods, I don't know enough about them. There are ways to at least make it difficult. If nothing else, use what are considered strong, though not as mainstream methods, though this may well be a really bad idea.. Rijndael (AES) is pretty well reviewed as an example, and I feel that AES256 is good for now, but that a 512bit use may be needed in the near future.

      scrypt itself has been particularly interesting to me.. been looking at it in more detail recently, mainly for some project work for both password use, and for cipher/iv generation from a plain string input. Then again who knows...

      --
      Michael J. Ryan - tracker1.info
  23. Yes by Anonymous Coward · · Score: 0

    I can guarantee that unless you're very much out of the ordinary -- meaning that you're either guilty of million $1,000,000+ fraud (although even that is probably well on the low side), or else a member of organizations directly associated with extremist views -- then the NSA do not give the slightest fuck about you and it's an enormous arrogance to think they do. Honestly, just think about it: there are hundreds of millions of Americans, none of whom the NSA have a legal basis for probing so they have to be at the very least slightly circumspect, and a good few billion people outside America who they have every right to snoop on. You'd have to fucking go some for them to give a fuck about you and my guess is that, honestly, they really, really, really couldn't give a toss if you lived or died. That means they're not going to break into your personal desktop (honestly, why the hell *would* they?) and your imprint on their databases will go back to your internet metadata, none of which you've ever been assured by anyone at all is in the slightest bit private.

    Everything I've said also goes for GCHQ who are my local legally-dubious group of spooks, and for anything I might ever say about them or, indeed, anything. They really don't care about me.

    1. Re:Yes by AHuxley · · Score: 1

      Politics is expensive and risky. Deals done, groups supported and experts have pasts. Over time you have a lot of exstaff who just know too much and might be tempted to talk to the press or write a book without that expected 30-50 year gap.
      That ability to get to the publisher in time existed till the early 1980's
      Its really just a keyword hunt for past and existing projects to save embarrassment and legal issues.
      Better to find the press/staff/political activism/conscience before it is published and do a deal or have your spin ready.

      --
      Domestic spying is now "Benign Information Gathering"
  24. Can you sleep soundly? by cold+fjord · · Score: 5, Insightful

    I think that depends on what keeps you up at night.

    In one of the earlier stories today there was a post making all sorts of claims about compromised software, bad actors, and pointing to this paper: A Cryptographic Evaluation of IPsec. I wonder if anyone bothered to read it?

    IPsec was a great disappointment to us. Given the quality of the people that worked on it and the time that was spent on it, we expected a much better result. We are not alone in this opinion; from various discussions with the people involved, we learned that virtually nobody is satised with the process or the result. The development of IPsec seems to have been burdened by the committee process that it was forced to use, and it shows in the results. Even with all the serious critisisms that we have on IPsec, it is probably the best IP security protocol available at the moment. We have looked at other, functionally similar, protocols in the past (including PPTP [SM98, SM99]) in much the same manner as we have looked at IPsec. None of these protocols come anywhere near their target, but the others manage to miss the mark by a wider margin than IPsec.

    I even saw calls for the equivalent of mole hunts in the opens source software world. What could possibly go wrong?

    Criminals, vandals, and spies have been targeting computers for a very long time. Various types of security problems have been known for 40 years or more, yet they either persist or are reimplemented in interesting new ways with new systems. People make a lot of mistakes in writing software, and managing their systems and sites, and yet the internet overall works reasonably well. Of course it still has boatloads of problems, including both security and privacy issues.

    Frankly I think you have much more to worry about from unpatched buggy software, poor configuration, unmonitored logs, lack of firewalls, crackers or vandals, and the usual problems sites have than from a US national intelligence agency. That is assuming you and 10 of your closes friends from Afghanistan aren't planning to plant bombs in shopping malls, or try to steal the blueprints for the new antitank missiles. Something to keep in mind is that their resources are limited, and they have more important things to do unless you make yourself important for them to look at. If you make yourself important for them to look, a "secure" computer won't stop them. You should probably worry more about ordinary criminal hackers, vandals, and automated probe / hack attacks.

    --
    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
    1. Re:Can you sleep soundly? by Lorien_the_first_one · · Score: 1

      Nice sig. Nice post, too. We each have to choose our battles carefully. In the meantime, enjoy life.

      --
      The diversity and expression of human opinion is essential to human survival.
    2. Re:Can you sleep soundly? by AHuxley · · Score: 1

      Cold most of the big projects where air gapped... if contractors have public global supply networks and are leaking details, the CIA and MI6 will discover that fault over time.
      People dont "just" make mistakes in writing software - backdoors and weakness are been coded in by default over the life of the projects.
      People dont want their internet to work reasonably well - they pay for quality hardware and software or work very hard to make it the best they can.
      Resources are not limited anymore due to computing power and most understand the ability to just keep everything of use now. "Limited" was the data storage in the 1960~70.
      Opens source software should be looked at all the time - thats one of the many useful aspects of the open source.

      --
      Domestic spying is now "Benign Information Gathering"
    3. Re:Can you sleep soundly? by Anonymous Coward · · Score: 0

      Ah yes, the old "if you have nothing to hide, you have nothing to fear" argument. Plain old privacy be damned.

    4. Re:Can you sleep soundly? by Anonymous Coward · · Score: 0

      Frankly I think you have much more to worry about from unpatched buggy software, poor configuration, unmonitored logs, lack of firewalls, crackers or vandals, and the usual problems sites have than from a US national intelligence agency. That is assuming you and 10 of your closes friends from Afghanistan aren't planning to plant bombs in shopping malls, or try to steal the blueprints for the new antitank missiles. Something to keep in mind is that their resources are limited, and they have more important things to do unless you make yourself important for them to look at. If you make yourself important for them to look, a "secure" computer won't stop them. You should probably worry more about ordinary criminal hackers, vandals, and automated probe / hack attacks.

      Frankly I think you say everything is good, because you got nothing to hide?

  25. Recall the NSA/FBI OpenBSD story? by Anonymous Coward · · Score: 2, Interesting

    Hmmm - all of a sudden this looks interesting again:

    http://news.cnet.com/8301-31921_3-20025767-281.html

  26. Best Strategy - No encryption by kawabago · · Score: 1

    No one will bother with unencrypted text as it will be assumed to have nothing interesting. If a computer scanning your text and forgetting it bothers you, hide the real text inside other boring text. Obscurity by tedium.

    1. Re:Best Strategy - No encryption by SuricouRaven · · Score: 1

      You'd need a cover that looks suspicious enough to explain why you might be taking efforts to hide it, and has enough sheer volume and complexity to make analysis difficult.

      Piracy is ideal. The best cover for a serious crime is a lesser crime - that way when the investigators ask why you were acting like you had something to hide, you can explain why.

    2. Re:Best Strategy - No encryption by Lorien_the_first_one · · Score: 1

      This is an interesting point. No matter how much data they collect, someone has to look at it and make a judgement call about it.

      --
      The diversity and expression of human opinion is essential to human survival.
    3. Re:Best Strategy - No encryption by SuricouRaven · · Score: 1

      Can do a lot with automated search. Beyond that, were I in their place, I'd focus on metadata analysis for targetting. Ie, if I detect that you have been twice in email contact with a subversive organisation*, then I'd know you were potentially a person of interest and pass your archived emails for the last three years through to a human to skim.

      *Think less terrorists and more protest groups. OWS or Tea Party, doesn't matter which side, they are making some politicians life difficult.

    4. Re:Best Strategy - No encryption by mark-t · · Score: 1

      Nope... the best cover for *ANY* crime is one that leaves people with no knowledge or even idea that the crime ever even happened in the first place. Failing that, the next best cover is not leaving behind any trail that could potentially be traced back to you. Trying to obfuscate it with a less serious one that might draw attention still has the effect of actually putting your actions under the spotlight and as a side-effect carries some additional risks that anything you may have done which was more serious will actually be exposed anyways.

  27. "pretty safe?" by bill_mcgonigle · · Score: 4, Insightful

    Yes, it's "pretty safe". It's not absolutely safe or guaranteed to be safe. But if your other alternative is a hidden-source OS, especially one in US jurisdiction, then OSS is "pretty safe."

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  28. No, you are no safe by drolli · · Score: 0

    Even if you did use ssl to get an proper kernel image (which i doubt), ssl relies on companies issuing certificates, which have been issuing bad certificates for much less important entities than the NSA.

    So, not you can not rely on that. Anybody could have given you any binary

  29. Hardware cocnerns by Anonymous Coward · · Score: 1

    Don't forget that there are concerns in the hardware as well. Are you using NVIDIA chip, a ATI chip, a non-atheros wireless chip, a non-HP printer (and even if it is HP in many cases), etc. All these things have non-free code where shit hides. Then there is also Chrome, Adobe Flash, Adobe Reader, Skype, and a number of other non-free components in most distributions. You have to be really careful. You may want to check out Trisquel. It's based on Ubuntu, compiled from scratch, patched for free software reasons, and some privacy related ones.

  30. Truecrypt Re:Not much worry with a source build by Anonymous Coward · · Score: 3, Interesting

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

    1. Re:Truecrypt Re:Not much worry with a source build by Sean · · Score: 3, Interesting

      Cryptome notes this document is claimed to be a hoax by a Hacker News user.

      http://cryptome.org/2013/09/computer-forensics-2013.pdf

    2. Re:Truecrypt Re:Not much worry with a source build by lister+king+of+smeg · · Score: 1

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

      yes it called the $5 dollar wrench but only get used against you if they think your a terrorist (OR your father's brother's nephew's cousin's former room-mate is suspected terrorist.)

      --
      ---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
    3. Re:Truecrypt Re:Not much worry with a source build by Trax3001BBS · · Score: 4, Informative

      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

    4. Re:Truecrypt Re:Not much worry with a source build by Anonymous Coward · · Score: 0

      your father's brother's nephew's cousin's former room-mate

      But what does that make us?

      Absolutely nothing, which is what you're about to become.

      - Spaceballs, if anyone didn't catch it.

    5. Re:Truecrypt Re:Not much worry with a source build by Anonymous Coward · · Score: 1
    6. Re:Truecrypt Re:Not much worry with a source build by u38cg · · Score: 1

      There was some discussion on this on Schneier's blog re the NA decryption story. Halfway down the (very erudite) thread this is discussed. The originally leaked PDF is an April's Fool joke but it was based on a real one, now missing. Some further discussion ensued on the security of Truecrypt, sufficiently interesting to make me doubt it.

      --
      [FUCK BETA]
  31. Re:If it is off - it might get stolen by Chemisor · · Score: 4, Insightful

    10000 laptops are stolen at airports every year. Presumably, they are off when that happens.

    The NSA is not your problem; you are not important enough to be a target. When thinking about security, thieves are your problem. Theft happens, and happens often. Your computer is far more likely to get stolen than to be inflitrated by the NSA. And the solution is to encrypt your hard drive. Without encryption the thief will have access to everything you normally access from the computer - like your bank account. You wouldn't want that, would you? Today's CPUs all have AESNI support, so there is no excuse for not encrypting your laptop's hard drive. Do it today and get some financial peace of mind.

  32. Re:nothing's safe, but there are obvious things to by SuricouRaven · · Score: 2

    The good news is that for linux, this can, in theory, be audited.

    For Windows...no. Not a hope. None. At all. Likewise OSX.

    Which means that any and every government that might possibly have any future dispute with the US is, right now, going over all their Windows servers and desktops in the military. diplomatic and intelligence services to see how much they can replace.

    It'll take months just to write up the reports, and months more to run through the political commitees, and even then it'll be very undiplomatic to openly admit the reason for the switch - but in a year or so, I think we are going to see a lot of governments decide that linux is more 'cost effective' in sensitive roles.

  33. fuck the NSA and US Govt by FudRucker · · Score: 4, Insightful

    they destroyed my trust in anything, i dont trust any operating system and software anymore, i dont trust the internet or any encryption method, the US Govt and all its elements have been proven to be a criminal gang of fascist kleptocratic totalitarian warmongering pigs.

    --
    Politics is Treachery, Religion is Brainwashing
    1. Re:fuck the NSA and US Govt by Anonymous Coward · · Score: 0

      "they destroyed my trust in anything, i dont trust any operating system and software anymore, i dont trust the internet or any encryption method, the US Govt and all its elements have been proven to be a criminal gang of fascist kleptocratic totalitarian warmongering pigs."

      "Pigs" makes you sound biased...

  34. SELinux? by Anonymous Coward · · Score: 0

    Makes you wonder about using it . As SELinux came about from NSA work in the first place, maybe it's time to re-look at including it in major distributions.

  35. Not just backdoors by Dorianny · · Score: 1

    Everyone on this thread is concerned with the possibility of nsa backdoors code but from my understanding the attack is much more insidious and the consequences much more severe than just a backdoor that only the nsa could use. By hiring most of the wrolds talent in cryptography and then deliberately having them design algortihms and code that is not as secure as it could be, or it should be then are they not only leaving everyone open to attack just by the NSA but from anyone else as well.

  36. reverse engineering processors by Anonymous Coward · · Score: 0

    Fit in one conference hall? I'll bet they would all fit in a medium sized office: all dozen of them.

    Or, perhaps more appropriate to the topic of this discussion, which I personally think it worrying about low level stuff "because it can" rather than bigger high level issues "because it can't": a portion of a wing at Camp Delta at Guantanamo, or one tiny cell in some friendly rendition country, etc.

  37. umm... by buddyglass · · Score: 1

    Define 'safe'.

  38. Ancient hardware by Anonymous Coward · · Score: 0

    What if you made an amd64 cross compiler for a PDP 11? Then, you could build a trustworthy compiler, knowing the compiling machine is too old or uninteresting for the NSA to have infiltrated.

  39. Ken Thompson, Anyone? by Anonymous Coward · · Score: 0

    After the NSA and anyone else found out about this sleight of hand trick, there would be a REQUIRED modification of the compiler to do one of several things....
    Some code buried somewhere in the Linux kernel would be a check on the compiler to ensure that back door is still in the compiler, and if it wasn't the compiler would, pick one or more; destroy itself, insert the back door, send a message to some agency that some one was trying to fix the back door issue and shut them down. So the likelihood of someone actually fixing the security hole and submitting it to anyone outside of some small cadre of friends and cohorts is small to non-existent. The person or persons would be immediately put under NSL letters and silenced. So is there any security, not likely; some agency somewhere in the world will have a back door to any worthwhile OS one creates or has developed.

    This brings up the next quandary how does one ensure that one can trust someone implicitly? With the NSL letters one can not be trusted to be telling the truth. One can attempt to do the whole thing oneself, but that quickly gets out of hand. As soon as one gets the assistance of some other person the jig is up and trust is lost. So we now have levels of trust and certification. As has been clearly indicated by some of the DEA documents, they LIE and can NOT be trusted to tell the truth about anything. Someone should edit the dictionary and clearly indicate on the word trust and truth, that the only person one can trust and ensure truthfulness is oneself. Anyone else can be "encouraged" to be UN-truthful or UN-trustworthy.

    Sorry for the long harangue! I am not a wordsmith. Someone rewrite this shorter and more concisely.

  40. Here's how to add security later: by Burz · · Score: 1

    http://qubes-os.org/trac/wiki/QubesArchitecture

    Compartmentalize the high-risk parts of the OS (like network and X11) into separate VMs that each get access to only the hardware they need via the IOMMU.

    Then you make it easy to use the hypervisor to graphically create separate color-coded domains: personal info, banking etc. go into one domain; work-related stuff into another; general browsing and other higher-risk stuff go into a third. The app windows from each of these "app domains" appears with the corresponding border color.

    If your network stack becomes compromised, the infection goes away when you reset the netVM or reboot the system. Same goes for the display, and for the disposable app VMs. Theoretically, nothing should be able to touch your Dom0 hypervisor or your other domains... or at least that task becomes extremely difficult for an attacker.

    You need certain late-model systems to take advantage of these security features, though.

    1. Re:Here's how to add security later: by Anonymous Coward · · Score: 0

      ... and we know for a fact that those late-model systems don't have compromised hardware, because the CPU and platform system tapeouts are open source. Don't we?

    2. Re:Here's how to add security later: by Burz · · Score: 1

      ... and we know for a fact that those late-model systems don't have compromised hardware, because the CPU and platform system tapeouts are open source. Don't we?

      We don't know this. But a scheme like QubesOS vastly reduces the number of components that require trust; both hardware and software.

      And lets be clear here: By "trust", we are all referring not only to a lack of intentional betrayal, but also to the competence of people who write, engineer and distribute systems. Knowing that nothing is perfect, security is not a boolean so its a matter of who you trust to give you the greater degree of privacy and security.

  41. Re:If it is off - it might get stolen by Dunbal · · Score: 5, Insightful

    you are not important enough to be a target.

    Wrong. You may become important in the future. So you are important enough to target. They are collecting data on everyone, and holding on to it. They just might not be actively going through all the data from everyone (or they might be, if they have enough computing power). But if it's recorded it doesn't really matter if they do it today or in 20 years. They've got you. "If you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him." --Richelieu

    --
    Seven puppies were harmed during the making of this post.
  42. Is there anything better this this? by rs79 · · Score: 1

    http://vimeo.com/18279777

    http://cr.yp.to/talks/2010.12.28/slides.pdf

    (Bernstein on Elliptical curve cryptography.)

    --
    Need Mercedes parts ?
    1. Re:Is there anything better this this? by Burz · · Score: 1

      Schneier says that discrete log-based ciphers are preferable for public key encryption.

      I think that is a reference to ElGamal. The only reason I know this is because that is the public cipher used by I2P, which along with the 2048-bit key size makes I2P look a lot more secure than Tor right now.

  43. Yes, the NSA will help protect you by dutchwhizzman · · Score: 1

    Seriously, the NSA will help protect you from anyone but themselves. As long as the NSA has nothing to do on your box, they will do their utmost to prevent foreign intelligence, hackers and other mischievous individuals gaining entrance to the average Linux distribution. Even if they do have something to do on your box, they'll still try to keep others out. Now if you want to hide your stuff from the NSA, you will have to do a bit more than just run an up to date linux distribution. It doesn't really matter what you run, they will probably have researched it, or it will be so small that it will be hard to find useful applications for it....

    --
    I was promised a flying car. Where is my flying car?
  44. What about ET phoning home? by Anonymous Coward · · Score: 0

    Your comment however only addresses one part of surveillance. The other is that the NSA has to communicate with home base. Two places to catch a snoop.

  45. Re:If it is off - it might get stolen by SuricouRaven · · Score: 1

    Correction: Only some Atom chips have AESNI. Not all models. That's an issue with netbooks, where processor speed can easily become a bottleneck.

  46. Faith in experts possible but unlikely & tempo by Anonymous Coward · · Score: 0

    Did the "experts" know about Differential cryptanalysis and the S-boxes at the time?

  47. Re:nothing's safe, but there are obvious things to by Anonymous Coward · · Score: 0

    What makes you think that if the NSA wanted in badly enough, they wouldn't just go and talk to / threaten Linus? Is that too paranoid? I mean, they haven't done the same thing to any other upper management types at other companies have they? They didn't go talk to the Skype team (prior to the MS buyout) either. Totally out of character and unprecedented, huh. They've proven that they're not just going to quit when they really want something, and they have a -lot- of weight they can swing around.

  48. Re:nothing's safe, but there are obvious things to by Anonymous Coward · · Score: 0

    None of this should be news to foreign governments. All of this stuff has been an open secret for at least a decade. But the NSA always had plausible deniability in the civilian sphere. But any government worth it's mettle should have known (and undoubtedly has known) that the NSA was embedding backdoors into Windows as well as Cisco and similar equipment.

    When the NSA is accusing the Chinese of doing this stuff--e.g. Huawei--you can be darn sure that the NSA was doing it even earlier.

    I work at a largish corporation that sells security appliances, and I'm fairly certain that the company has defense ties, based on the coyness the CEO, CTO, and others have shown when I ask certain questions. But I also have access to _all_ the source code as one of the biggest committers. Which tells me that they patch the firmware outside of the regular [known] chain of manufacturing control, probably on a client-by-client basis. That is, expensive installations for huge customers get "special" treatment, but smaller orders for smaller companies are pretty much ignored. Which makes sense, because security researchers regularly scan our firmware, and you wouldn't want them getting hold of a copy of the firmware with NSA backdoors.

  49. Re:nothing's safe, but there are obvious things to by Anonymous Coward · · Score: 0

    Remember how that kid that created a secure chat client has been endlessly harassed? That's just for a piddly-assed IM system. You don't think that they'd do the same to the high-level maintainers of an OS?

  50. Pig Latin Crypto FTW ! ! ! ! by Anonymous Coward · · Score: 0

    To throw off the NSA I use a Pig Latin Crypto plug-in.

    Eythay Ontday Ownay Atway Etsgay Entsay!

  51. ... Almost ... by Anonymous Coward · · Score: 0

    Our server room has some (hardware) utilities for remote administration, including remote reboots. Dell and HP have them, probably other vendors. You can actually turn the computer on remotely. As well, some desktops are set to Wake-on-LAN for support purposes ... again, they come on via remote signals.

    You can't have too much paranoia ...

  52. use your own memory by Anonymous Coward · · Score: 0

    Keychain is for throwaway logins, eg slashdot forums, all those stupid sites that demand a login and password, and all with different rules and
    requirements fro unique logins. Those go in the keychain, under one master password. I've always considered it to be of lower-level security, and the browser password store lower level again.

    I don't put financial account numbers or passwords in the keychain or browser store- I memorize those. I also memorize my mastercard number, expiry and code.
    Ones I haven't memorized go in a text file inside an encrypted container file.

  53. Remember this? by Voline · · Score: 5, Interesting
    Remember this? In December 2010 there was a scandal when a developer who had previously worked on OpenBSD wrote to Theo de Raadt and claimed that the FBI had paid the company he had been working with at the time, NETSEC Inc (since absorbed by Verizon), to insert a backdoor into the OpenBSD IPSEC stack. They particularly pointed to two employees of NETSEC who had worked on OpenBSD's cryptograhpic code, Jason Wright and Angelos Keromytis. In typically open-source fashion, de Raadt published the letter on an OpenBSD mailing list. After the team began a code audit de Raadt wrote,

    "After Jason left, Angelos (who had been working on the ipsec stack alreadyfor 4 years or so, for he was the ARCHITECT and primary developer of the IPSEC stack) accepted a contract at NETSEC and (while travelling around the world) wrote the crypto layer that permits our ipsec stack to hand-off requests to the drivers that Jason worked on. That crypto layer contained the half-assed insecure idea of half-IV that the US govt was pushing at that time. Soon after his contract was over this was ripped out. ...

    "I believe that NETSEC was probably contracted to write backdoors as alleged."

    I'd like to find a more recent report of what they found.

    1. Re:Remember this? by Anonymous Coward · · Score: 0

      http://cryptome.org/2012/01/0032.htm

  54. Re:nothing's safe, but there are obvious things to by AHuxley · · Score: 1

    Yes it will be fun as diplomats spin up their international story telling skills on their embassy equipment and create believable plots.
    Their intelligence services will sit back waiting for the first hint of their work to drop into the press.

    --
    Domestic spying is now "Benign Information Gathering"
  55. Re:If it is off - it might get stolen by Anonymous Coward · · Score: 0

    If it is compromised, then someone other than NSA will figure out how, and exploit it.

    Thieves are just as smart as spies, and far more motivated.

  56. Regarding NSA recommendations ... by Anonymous Coward · · Score: 1

    I have always been an Advocate of using Serpent over Rinjdael, which eventually became AES, simply because Serpent's higher security level was never in doubt; Rinjdael was chosen primarily because it is faster. However, in light of all this news, I think People should jump ship to Serpent on principle.

  57. Re:nothing's safe, but there are obvious things to by Anonymous Coward · · Score: 0

    No, but there's no reason to think that Linux is worse than anything else, and it's probably easier to fix.

    If I were Linus I'd be putting together a small team of people who have been with Linux for years to begin assessing things. From Gilmour's posting it seems clear that IPsec and VPN functionality will need major change. Other things to audit include crypto libraries, both in Linux and the browsers, and the random number generators.

    But certainly some examination of SELinux and other portions are also needed.

    I don't see how anyone can answer the original question without doing some serious assessment. However I'm a bit skpetical whether this problem can actually be fixed at all. We don't know what things have been subverted, and what level of access the NSA and their equivalents in other countries have had to be code and algorithm design. They probably have access to more resources than the Linux community does.

    If you look hard at the history, you will find Gilmor's is rewriting history to his point of view. He was in a fight with the US crypto export policy and won. He carried that baggage over into FreeSwan development. The code he is talking about was rejected because he placed restrictions that only non-US developers could contribute to it. Also the code had a non-standard coding style. The combination of the two meant the code was not going to be accepted. He wants to believe it was related to NSA which is bullshit.

  58. Conversly by DrYak · · Score: 1

    improving a single ASIC design for breaking it.

    On the other hand, computer technology and cryptography have advanced to the point where crypto-algos are so complex that it would require more than the universe' worth of energy for exhaustively brute-force the whole key-space (or at least we're quickly approaching this point).

    Currently, breaking crypto isn't done by trying to built faster machine to make more brute-force tries pers nanosecond. Instead it's done:
    - by circumventing the crypto: breaking the software it self so generate broken cryptography (remember the broker SSL keygen in Debian making relatively predictible keys?) or having exploits leading to leaks of plaintext before encryption.
    - by finding flaws in the algorithm itself: finding weakpoints so that you don't actually have to scan the whole key space in brute force, but instead have only a reduced set of possible way to break it, thus making it feasible before universe heat death.

    we should be using hundreds of different algorithms.

    On the other hand you should be using algorithms which have been thoroughly studied and examined by the academics and for which we have a high level of confidence that the maths are sound and no shortcut could be developped.
    And you should implementation which have been throughly reviewed against bugs.

    Using a dozen of well done encryption algo could be a good idea.
    Moving to the thousands: you dilute the amount of eyeball looking for bugs and thus have a higher risk that some algo or implementation haven't been reviewed enough and might actually be flawed.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  59. Re:If it is off - it might get stolen by multimediavt · · Score: 1

    10000 laptops are stolen at airports every year. Presumably, they are off when that happens.

    The NSA is not your problem; you are not important enough to be a target. When thinking about security, thieves are your problem. Theft happens, and happens often. Your computer is far more likely to get stolen than to be inflitrated by the NSA. And the solution is to encrypt your hard drive. Without encryption the thief will have access to everything you normally access from the computer - like your bank account. You wouldn't want that, would you? Today's CPUs all have AESNI support, so there is no excuse for not encrypting your laptop's hard drive. Do it today and get some financial peace of mind.

    Ok, I till give you the-best-secure-computer-is-the-one-off-locked-in-a-safe-in-the-bottom-of-a-salt-mine award. However, everyone is currently on the NSA radar. If not for terrorism for some other reason, so to say that you are more likely to lose data to theft than the NSA is impossible to prove. Encryption won't get your laptop back from a thief. Even if they can't get at the data you're still without data or a computer. How is that financial piece of mind? Mod parent down for lack of critical thinking.

  60. Re:nothing's safe, but there are obvious things to by Anonymous Coward · · Score: 0

    most governments of the world and universities etc all have full code access to windows for audit purposes. I would not be surprised if OSX was the same, So no Linux is not a special animal with its ability to be audited.

  61. Isn't it really worse than that? by smittyoneeach · · Score: 2

    Isn't the compiler software?
    And doesn't the compiler target an architecture?
    And isn't that architecture rife with microcode you never see?

    --
    Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
  62. Tcpdump by Anonymous Coward · · Score: 0

    So I'm not a programmer and I can't write my own OS... However, I do wonder why it is that I haven't saw much postings (if any) about monitoring the network traffic surrounding your boxes. I don't find it hard to believe that it is possible to insert malicious code into a program (open source or not) however I do find it hard to believe that someone... Anyone... Could not see the inbound/outbound traffic with a network monitoring box somewhere. Heck, take a look top dump data or net flow data and look for anomalies. Am I really that far off the reservation on this?

  63. Most commercial security software sucks by gweihir · · Score: 1

    I have reviewed some, and what a terrible, terrible collection of beginner's mistakes it was. This is not the NSA having god-like powers. This is most commercial software being incredible bad with regard to security. Add to that the broken, NSA compromised SSL CA system, and you get the current claims, all without any backdoors in OSes (no, not even Windows).

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  64. It might be slow, but... by Anonymous Coward · · Score: 1

    ...perhaps it is time to dust off my old Apple II?

    1. Re:It might be slow, but... by u38cg · · Score: 1

      Check Scheier's blog on the NSA decryption story and find Clive Robinson's post on airgapping and building provably secure code.

      --
      [FUCK BETA]
  65. BIOS loads modules from cards, to boot raid or pxe by raymorris · · Score: 3, Interesting

    The reason you can boot from a raid card or network is because the BIOS loads and runs BIOS modules from those cards. You may be familiar with the Linux kernel, where most of the functionallity is in modules that become part of the kernel. BIOS is the same. One differentiator between a server motherboard and a consumer one is how much BIOS memory it has, to load modules from many different pieces of hardware. I have one machine with at least four different pieces of hardware that include BIOS. MOST of the BIOS on that machine didn't come with the motherboard.

  66. we already do that for QC. All maintainers see all by raymorris · · Score: 4, Interesting

    For the Linux kernel, that's how development is done already, for quality control and bloat reduction. Nobody can commit by themselves, it takes at least three people to get a change into mainline. Each developer has their own copy of the tree into which changes are pulled, so they can see all changes that are made, and who made them.

    For each part of the kernel, there are a number of people particularly interested in that bit who watch it and work on it. For example, the people making NAS and SAN devices and services keep a close eye on the storage subsystems. Myself, I watch the cm storage stack generally, more specifically LVM, and even more specifically snapshots. There are a few dozen people around the world with special interest in that particular part of the code. No backdoors will come in without some of us spotting it. What COULD happen is that some code could come in that isn't quite as secure as it could be.

    It just so happens that I'm a security professional who uses advanced Linux storage systems for a security product called Clonebox, so that's at least one security professional closely watching that part of the code. Thousands of others watch the other parts.

    It's convenient that a lot of the development is done by companies like Netapp, Amazon (S3) and Google. You can bet that when Amazon submits code, Netapp and Google are looking closely at it. When RedHat submits something, Canonical will point out any reasons it shouldn't be accepted.

  67. No matter how safe... by Darinbob · · Score: 1

    No matter how safe you think something is, you should always assume someone else has broken it. That is, don't do anything with your computer that you don't want the NSA to see.

  68. Hypervisors are probably the biggest targets by Anonymous Coward · · Score: 0

    If you were the NSA looking to get the biggest bang for your bugging dollar, planting backdoors into hypervisors would get you the most bang for your buck. Almost all medium to large companies now use hypervisors, usually Microsoft's or VMWare. As the hypervisor already has access to everything the VM does, including all network and disk access as well as the contents of memory (think data while it's still in the application before it's encrypted), they would make the perfect target for someone wanting to clandestinely spy on people. I'd be willing to bet the farm that Hyper V and VMWare have been compromised. In VMWare's case all you have to do is search on VMWare and NSA to see all these announcements by VMWare over the last five or six years where they are trumpeting their "partnership" with the NSA to make more secure products. I think we can all figure out what that really means now.

  69. Re:we already do that for QC. All maintainers see by Anonymous Coward · · Score: 0

    Please correct me if I am wrong, but isn't it true that nearly any dusty old driver or any peripheral with bus-mastering or DMA capability could be turned into a binary patcher to insert arbitrary backdoor functions into a Linux kernel at runtime?

    Does this mean we'd have to (at least) audit all peripheral hardware and their firmware to have any real confidence in the integrity of a particular kernel instance?

    Could a storage HBA maliciously insert code into the kernel as a side-effect of other I/O transfers it is performing, e.g. assuming the HBA firmware was compromised before the system even booted? Assuming we trusted the IO-MMU features of modern processors, are they used in a sufficiently fine-grained manner to prevent an HBA from modifying kernel code (or stack space) outside of the specific buffer pages that were supposed to receive disk data from that HBA?

  70. You again! by Anonymous Coward · · Score: 0

    ...store it's passwords in it's own keystore...

    Store it is passwords in it is own keystore?

    Didn't even have to check to know that you were the guy doing the same thing in the Atlas Robot story comments. Gah...

  71. Re:Not much worry a CPU... by neurocutie · · Score: 1
    "Backdooring a CPU wouldn't actually be that difficult."

    but fairly unlikely, at least not in the way you describe, with a "specific command sequence". 1) its at too low a level to be really useful as a backdoor, not without the help of backdoor software higher up, but then what's the point? there are already many "backdoor"-like ways to gain privileges as long as the software is there to support them, 2) it would have to be designed to NOT slow the CPU down or take up obvious chip real estate... the CPU biz is so competitive that any extra overhead of either type would make that chip less competitive in the market.

  72. Re:Obama Fellatio HQ by shentino · · Score: 1

    Don't blame me, I voted for Kodos.

  73. Re:nothing's safe, but there are obvious things to by Anonymous Coward · · Score: 0

    How about sending messages through J-Peg

  74. Re:If it is off - it might get stolen by Anonymous Coward · · Score: 0

    The NSA is a problem. Their theft, of business data, private political information, and personal correspondence of any "person of interest" is organized and legally protected in ways that your average laptop thief could only dream about. A laptop thief can waste months of your income. The NSA can, and has, helped lead the USA into unwinnable wars by manipulating, or failing to correct, fraudulent information fed to Congress by nutjobs with an agenda. (See the history of Dick Cheney's manipulation of intelligence reports to get a glimpse of how this was done.)

  75. Re:we already do that for QC. All maintainers see by DF5JT · · Score: 2

    When RedHat submits something, Canonical will point out any reasons it shouldn't be accepted.

    I had a good laugh when I read this.

    Red Hat employs hundreds of software engineers, contributing a lot to the entire Linux ecosystem. Canonical's resources in terms of code contribution are laughable in comparison and being a streamlined business Cacnonical has few, if any, resources to review third party code. They are happy to ride along, but the number of people at Canonical who actually write and read code outside the shiny UI field are hardly those with the expertise to review low level kernel code.

  76. NSA's actions damage their credibility forever by caseih · · Score: 3, Insightful

    Over the years the NSA has contributed what seemed like positive things to computer security in general, and Linux specifically. They have helped correct some algorithms to make them more secure, and implemented things like SELinux.

    However, now that their other actions and intentions have been starkly revealed, any and all things the NSA does (and has done) are now cast into steep doubt. Which is unfortunately because the NSA has a lot of really smart cryptographers and mathematicians that could greatly contribute to information security.

    Now, however, their ability to contribute in any positive way to the open source community, or even to the industry at large, is gone forever. No one will trust them again. A sad loss for them, but also a potential loss for everyone. Nothing will quite be the same from here on out. And in the long run, without the help of smart, honest mathematicians and cryptographers, our security across the board will suffer. It's not the the revelations caused the damage, but that the NSA sabotaged things. Shame on them. Kudos to Snowden for helping us learn the extent of the damage.

  77. Protecting Linux/Ubuntu by Czarek+Tomczak · · Score: 1

    The binary releases for Ubuntu or any other Linux should be compiled from scratch (including compiling the compiler) by many trusted people (not a one company) and then the binary code should be compared. NSA will definitely want to hire the people that are responsible for creating binary distributions for Linuxes, as their secret agents. So we should make sure there are many of them and they are of high morality.

  78. who is worring at night? by Anonymous Coward · · Score: 0

    maybe to stay sane, a change in perspective is in order.
    one has adapted to sleep okay even though one reads
    about new CVS and software problems "all the time".
    now just assume that NO ONE doing opens source wants a
    backdoor, then further just assume a backdoor (government or not) is just
    a flaw that will be discovered and get its own CVS in time ...
    furthermore, don't forget that modern OS and software in general is HUGE!
    bits and bytes wise AND human intelligence wise. it gets more and more
    complex as it moves into the future.
    so it is safe to assume that it is close to impossible to write a OS (and tools)
    from scratch, for this is what a deliberate sabotaging agent would need to have first.
    if there is no safe (secure and backdoor free) base to fall back to, then what is the
    sabotaging agent going to fall back on, once his mission as been accomplished?
    banks run on open source and so do governments etc. etc. etc. hell, even the sabotage
    agent mission planning office is probably running it.
    so in the end, it is probably NOT the desktop user that should be worried, but people
    who want to use (open source powered) computers to "save the planet" from ... errr .... people.
    *waves to 3 letter*

  79. NSA & BSD by unixisc · · Score: 1

    No, the NSA has pretty much blacklisted not just Open BSD, but all the BSD's over Theo's opposition to them. So if one is paranoid about the NSA, just go w/ any one of the BSDs, they simply don't touch it. And since they don't support BSD devs, one can be sure that BSD devs don't build in any back doors for them.

    1. Re:NSA & BSD by Anonymous Coward · · Score: 0

      No, the NSA has pretty much blacklisted not just Open BSD, but all the BSD's over Theo's opposition to them. So if one is paranoid about the NSA, just go w/ any one of the BSDs, they simply don't touch it. And since they don't support BSD devs, one can be sure that BSD devs don't build in any back doors for them.

      Citation needed.

      Since a lot of code in the bsd world is borrowed from the lunix world these days, you can expect some cross infection to be going on.

    2. Re:NSA & BSD by unixisc · · Score: 1
      DARPA funding cancellation

      After De Raadt stated his disapproval of the U.S.-led occupation of Iraq in an April, 2003 interview[8] with Toronto's Globe and Mail, a multi-million-dollar US Department of Defense grant to the University of Pennsylvania's POSSE project was cancelled, effectively ending the project. Funding from the grant had been used in the development of OpenSSH and OpenBSD, as well as many other projects and was to be used to pay for the hackathon planned for May 8, 2003. Despite money from the grant already having been used to secure accommodations for sixty developers for a week, the money was reclaimed by the government at a loss and the hotel was told not to allow the developers to pay the reclaimed money to resecure the rooms.[9] This resulted in criticism among some that the US military held an anti-free speech attitude. The grant termination was, however, not as bad a blow as some portrayed it. The project's supporters rallied to help and the hackathon went on almost as planned. The funding was cut mere months before the end of the grant, further fueling the speculations regarding the situation surrounding the grant's termination. It did, however, also negatively influence DARPA funding on other BSD-related projects, such as FreeBSD.

  80. The perfect GNU CPU by unixisc · · Score: 1

    The perfect GNU CPU would be a VLIW CPU. The FSF could try & get the HDLs from whoever owns the VLIW core of Transmeta's Crusoe, and put them under GPL3. Then they could try working w/ a fab on creating a CPU based on this - not the x86 part, mind you, just the VLIW core.

    From that point, they could create their own VLIW CPUs every time, and since it's a pure VLIW and not EPIC/RISC, all programs would have to be recompiled every time a new CPU is out. The FSF can also work to ensure that there are no backdoors or anything, and then also work on getting their 'Libre-Linux' or HURD on this platform. For compiler, they'd have the good ole GCC. Sounds so hunky dory - they should try it.

  81. Re:Obama Fellatio HQ by gishzida · · Score: 1

    Being one of those liberal hippies you seem to be attempting to blame for "Republican Military-Industrial Complex Elitism As Usual" let me speak on our behalf:

    No. Mr. O does not speak for me. Mr. O is just another "Republican Moderate" in allegedly liberal clothing [if he had been a *real* liberal he would have gotten us the "Single Provider" [aka Socialist} version of healthcare like all reasonable western countries have rather than the Capitalist "bend over, here's the bill" Romney-care.

    I do not support Mr. Obama and his Republican backers in regards to spying and their violation of privacy and free speech. I have to ask tho': Is your memory so short? The NSA making war on the American People has nothing to do with a particular politician... I'm sure that if Romney-bama had won it would be exactly the same [except Snowdon might have gotten a drone strike] Don't you get it? Or are you just one of those who can't think any further that "the wise words" of Limbaugh, Beck, or Hanity? All that has happened is Obama has become Bush III. [or should we say Nixon IV? All this stuff began under Bush II and probably even Bush I [since he was an ex Director CIA]....

    Our allegedly two party system is actually two faces of the same 1% Capitalists -- who believe that lying, cheating, stealing, and sticking their nose in to the lives of the proles is acceptable to their comfort... after all they aren't snooping on each other are they? -- Except to get what they want... Which is how Mr O. has become "a Liberal that Joe McCarthy could love"(TM)... How many of our "Freedom loving" Republicans or Or "I am a rugged individualist Tea DoucheBagger" are actually saying "this is "wrong and I'm writing veto proof legislation to kill the spying"? Where is the Republican or conservative Congressional censure? Look! There IS none! Most of your Conservative friends are cheering this on... Welcome to the Barry Goldwarter 1984...

    Just wait till the morals proctors get a hold on this stuff then we'll have the Scarlett Alphabet of offenses against the state

    Mister O. does not make laws. Congress does. Where is your outrage at the violation of the constitution? Why aren't you throttling your Congress with questions like: Where does it say in the constitution there is a guarantee to the government that "State Secrets" is a free pass to tyranny or violating the constitution? You see? Everything your "Douchebag Conservative Establishment (TM)" [including Limbaugh, Beck, & Hanity} has ever said about us Socialist-leaning Hippies is wrong...

    Hippies never started any wars... Hippies never napalmed anyone [United States in South Vietnam], nor released Sarin gas [Syria & Iraq]... Hippies don't chop off people's heads for moral infractions [Saudi Arabia anyone?] nor encourage lying [Most governments]... Hippies don't condone nor control drone assassination teams [The CIA]... Your Duly Elected Washington Representatives don't speak for us at all... All of the lying Corporation Bought Representatives of our Congress as well as the secondary Legislative branch call the Supreme Court are no one we would call friend... Nor the current POTUS nor any of the potential future ones... as they are all bought and paid for by all of the corporations you know and love...

    by the way... Hippies don't like corporations... but the corporations love people that they can lead around by the noses... like maybe some of your congress persons or you since you seem to be fixed on the wrong Villain in this skit....

    In the future please remember our motto-- Make Love, Not War!

    If you don't like what America has become, I advise you, as we hippies were advised by the conservatives and red-necked Southern Good Ol' Boys way back when: "America, Love it or Leave it!"

  82. Linus Torvalds is an NSA asset by Anonymous Coward · · Score: 0

    The Truth Will Out.

  83. The army of de-compilers - an army of one? by Anonymous Coward · · Score: 0

    It only take one guy, checking random important spots in different distros.

    Anyone need a new hobby?

    (anonymous at work cuz I did not memorize the password for my user)

  84. Re:If it is off - it might get stolen by nickmh · · Score: 1

    you are not important enough to be a target Tell that to 1930's Europeans!

  85. Re:we already do that for QC. All maintainers see by Lennie · · Score: 1

    If you only look at the diffs, you won't notice a change which they'll spread out over a couple of months.

    --
    New things are always on the horizon
  86. Trust nothing by gatkinso · · Score: 1

    Rebuild from the ground up. It's the only way to be sure.

    I predict a huge increase in use of BitBake.

    --
    I am very small, utmostly microscopic.
  87. Stop trusting Truecrypt by gatkinso · · Score: 1

    The suspicions surrounding Truecrypt have never been fully explained.

    --
    I am very small, utmostly microscopic.
  88. Be wary of your hardware by gatkinso · · Score: 1

    The US government certainly is.

    http://www.darpa.mil/Our_Work/MTO/Programs/Trusted_Integrated_Circuits_(TRUST).aspx

    Every wonder why National Semiconductor (now TI I guess) runs a FAB at Fort Meade?

    http://www.trustedfoundryprogram.org/

    --
    I am very small, utmostly microscopic.
  89. Where are they now? by Anonymous Coward · · Score: 0

    Jason Wright and Angelos Keromytis where are they now? Jason Wright is (likely Jason L Wright) at Idaho National Laboratory. Angelos Keromytis is now a professor at Department of Computer Science Columbia University, must be him with such an obscure name.

    Interesting, I wonder how they feel about their little part in the Stasiverse?

    Perhaps they're students should ask them? I mean if you want to learn from these academics, it's important to know what the f*** were they thinking when they put backdoors into secure systems???

    And what exactly did the University do when it read these allegations?

  90. Re:Obama Fellatio HQ by Anonymous Coward · · Score: 0

    We do not agree on things but from your post I can see you are someone who has a brain, uses it and is capable of having a discussion. Usually around here all I get is name calling and down modding to the tune of 'shut up you are an evil Republican and therefore wrong'. FWIW I am not a Republican and I am not wrong. If you care the only reason I post around here is that it's fun to rattle the cages as it were, posting on conservative blogs gets boring as there one is either facing an echo chamber or you just end in some social club where you get to see people engage in virtual pissing contests, neither of which interest me.

    But having an actual discussion is something different; I do not think you are evil for being wrong about things, you are just wrong. And on top of that you get a lot of things right, I assure you you would be surprised to find how much we agree about. Do you care to discuss some of this?

    Let's start with a few of your points. Comments inline.

    ----

    Being one of those liberal hippies you seem to be attempting to blame for "Republican Military-Industrial Complex Elitism As Usual" let me speak on our behalf:

    -- Republican Military-Industrial Complex Elitism As Usual

    Let's take that one first.

    John F. Kennedy - D
    Lyndon B. Johnson - D
    Richard Nixon - R
    Gerald Ford - R
    Jimmy Carter - D
    Ronald Reagan - R
    George H. W. Bush - R
    Bill Clinton - D
    George W. Bush - R
    Barack Obama - D

    Going back to 1963 the House and Senate had the following make up;

    Senate -
    1963 to 1981 - D - 18 years
    1981 - 1987 - R - 6 years
    1987 - 1995 - D - - 8 years
    1995 - 2001 - R - - 16 years
    2001 - Half the year R then Jun 2001 to Jan 2003 D .5/2 years
    2003 - 2007 - R - 4 years
    2007 - - D - 6 years

    Totals: D 34 years R 27 years

    House -
    1963 - 1995 - D - 32 years
    1995 - 2007 - R - 12 years
    2007 - 2011 - D - 4 years
    2011 - 2013 - R - 2 years

    Totals: D 36 years R 14 years

    So just going by party majority back to 1963 what do you see? I see a clear Democrat dominance there. Don't you? So I am at a loss to what you mean by "Republican Military-Industrial Complex Elitism". Honestly. Democrats start plenty of wars in this list, you see this right? In fact Barky seems dead set on starting a new one any day now in Syria that frankly I do not see the strategic importance of. Ok that's putting it nicely but let's not go off topic. You think Republicans are running this show? The math doesn't add up. Let's continue;

    No. Mr. O does not speak for me. Mr. O is just another "Republican Moderate" in allegedly liberal clothing [if he had been a *real* liberal he would have gotten us the "Single Provider" [aka Socialist} version of healthcare like all reasonable western countries have rather than the Capitalist "bend over, here's the bill" Romney-care.

    --------------------

    Do you really think Obama is a stealth Republican? You can't possibly be serious. Look at this honestly gishzida, tell me what Obama has done that strays from his socialist idealogy. Let's start with Obamacare.

    Passing socialized healthcare on the US has been a dream of the progressive - the socialist - for literally generations. It goes back to Medicare and Social Security, all of these things pushed by the Democrats and for the most part these things are based in FDRs new deal; you know this right? The far left, the true hard core socialists, dream of single payer and this has clearly been the goal of the Democrats of Obama. As it is they had to twist arms and make deals and pushed Obamacare through by the skin of their teeth. They wanted single payer but knew they couldn't get it, and Obamacare is the compromise. The plan however is to leverage Obamacare into single payer down the road. The point here is that it wasn't Obama's fault that we didn't get single payer this time around, the truth is that the citizens do not want it and that congress knows that, and they did not have the

  91. Strategy in Silicon by Anonymous Coward · · Score: 0

    Problem is even worse than this modern processors since pentium 4 and above architectures have whats known as a microcode patch area an area where the instructions themselves can be patched/corrected after manufacture and where test programs have indeed managed to update(work was done a couple years ago by a now deceased friend of moi).. the manufacturers are of course aware of this area as they designed it in and its NOT designed for access even by determined assembly language programmers.. BUT grabbing an microcode update program for the processor in question and then careful disassembly by programs such as IDA will reveal the proper bits to twiddle to gain access.. except in very late model processors where such updates hopefully have to be signed with a key know to the TPM(yeah right).

        SPARC and older Apple hardware have their firmware boot code written in a dialect/language similar to Charles Moore Forth(ie threaded interpretive language) its called OpenFirmware when I was in Sunsoft.(many years ago)...

                                                    A former penetration engineer for Sunsoft :)

  92. Let it go!!! by Puppet+Master · · Score: 1

    If you have any type of social networking account (Facebook, Twitter, Reddit, Pinterest, etc...) then you gave up on your privacy long before the NSA had access to anything. Hell 60% of the FB accounts are fake government accounts anyway. I myself have nothing to hide and the government can read my email, text messages, instant messages, snail mail, all they want. Let them knock themselves out as I don't care. They have been reading your personal data for over a decade (Patriot Act saw to that). This is all old news and there's nothing to see here.

    --
    The day Microsoft creates a product that doesn't suck, it will be known as the Microsoft Vaccuum Cleaner!
  93. Re:Not much worry a CPU... by SuricouRaven · · Score: 1

    I disagree with 1, because with an exploit like that any software can become your backdoor.
    eg: You want to hack a mail server. You take a look at it with a quick profile and determine it's (hypothetically) a Windows 2003 server running Exchange. It's a big company, so you can be confident this is a 64-bit OS. So you craft your attack email: The trigger sequence, followed by a payload. You know this is running Windows 64-bit, so you can pick a payload accordingly. It'll run with the permissions of the first process to access the data: The network card driver. So all you need is a payload designed to run as Windows 64-bit 2003 kernel mode code, with the function of obtaining and executing the real malware that gives you control.

  94. by hand... by nobaloney · · Score: 1

    The good old days, when we hand-compiled our own cmpilers.

  95. DUH of the year award by marxmarv · · Score: 1

    Look, if you're reading this news site, and you didn't know that security can only be meaningfully assessed against a threat and that an accurate model of this threat is required in order to assess it and propose countermeasures, you're not going to bring much to this conversation except noob blather.

    The observation you appear to be missing is that *both* adversaries in a crypto war have cost-benefit tradeoffs to make. Backdooring a crypto product is cheap, and very valuable. Expect it. The NSA black-bagging your hardware is expensive. If you've never been to an environmental protest, you're not worth this to them. The NSA pwning your router, apparently, is a capability they hope to automatically acquire this year -- expect that.

    --
    /. -- the Free Republic of technology.
  96. Religious dogma, or propaganda? by marxmarv · · Score: 1

    Either way, that's kind of a strange thing to say about an organization that claims to have completed an awesome new cryptanalytic capability in 2011, after which (according to the black budget leaks) CCP's Microelectronics program shrunk by a factor of six over the next two years... and that slide with that little red box...

    --
    /. -- the Free Republic of technology.
  97. typeof targeting === 'object', not 'boolean'. by marxmarv · · Score: 1

    Apt Richelieu quote. They are collecting data on every person, but how much is a function of the person (or the data). Consistent sympathizers with incumbent power are uninteresting and not really worth the bandwidth. Sympathizers with any power other than the regime are interesting.

    --
    /. -- the Free Republic of technology.
  98. Re:Obama Fellatio HQ by steg0 · · Score: 1

    Being one of those liberal hippies you seem to be attempting to blame for "Republican Military-Industrial Complex Elitism As Usual" let me speak on our behalf:

    No. Mr. O does not speak for me. Mr. O is just another "Republican Moderate" in allegedly liberal clothing [if he had been a *real* liberal he would have gotten us the "Single Provider" [aka Socialist} version of healthcare like all reasonable western countries have rather than the Capitalist "bend over, here's the bill" Romney-care.

    I think that a government that is likely to give you socialist healthcare is also not likely one that is going to disband an agency like the NSA, mainly because it's not one to disband any agency. (If the situation here in Europe can be any indicator.) The "perfect" laissez-faire society would be the one without an NSA. Now granted there is no such thing in the real world and it would just mean going over that civil vs. economic liberty thing again. But still. Hiding away talented mathematicians and engineers like that is just a waste of taxpayer money.

  99. Is Anything Secured? online/offline? by removebeforeflight · · Score: 1

    Do you consider *nix be more secure than Win 7? Given the recent leaks about these data collection efforts... Which OS would you say has the most integrity from a privacy prospective? All these stories on /. lately are starting to make me wonder if I should... 1. Always disconnect system's, from the network, when not actively being used. This could lead to issues by not being connected to receive patches & etcetera. 2. Build virtual machines offline and maintaine offline and reverting back to my, somewhat trusted, offline maintained VM images (using snapshots or similar) Any other ideas, advice or opinion's would be greatly appericated.

    --
    /.
  100. security limit by Lonelyking · · Score: 1

    I would posit based on what we read in Ken Thompson's attack that the following can be traced back to Godel's problem: Can a secure system be build on systems that have tools that verify their own security? And for the practical minds, is it feasible / possible to trust any system as a starting base for a secure system and build over that? I have never thought about this this way, but I feel we might have hit security theory's rock bottom. Cheers!

  101. clarification by Burz · · Score: 1

    From Wikipedia:

    Popular choices for the group G in discrete logarithm cryptography are the cyclic groups (Zp)× (e.g. ElGamal encryption, Diffie–Hellman key exchange, and the Digital Signature Algorithm) and cyclic subgroups of elliptic curves over finite fields (see elliptic curve cryptography).

    I don't know if that covers all of the widely-available EC algorithms.

  102. Binary blobs are bad, IOMMUs are good. by raymorris · · Score: 1

    Binary blobs are bad, m'kay. No argument there. However, IO-MMUs like VT-d, which is used by Core i* processors, seem to be a pretty strong protection. The approach is simple and therefore should be robust, and it directly handles the root issue, rather than trying to band-aid the symptom as Microsoft Security Essentials and similar do.

    It is my understanding that DMA address space is assigned at runtime, but it's allocated at boot time, meaning a device can't gain access to memory not allocated for DMA at boot time. Memory management isn't "my thing", though, the storage stack is, and to some extent early boot is my thing. What you're talking about is handled by the memory management people.

     

  103. Good point, not the best example by raymorris · · Score: 1

    You have a point, Red Hat does a LOT more development than Canonical, so maybe that's not the best example.
    Offhand, I don't know what the BEST example is. I think you get the point, though. I've just been reading about the different options for caching disk devices on Flash and I noticed the three developers of different implementations, and the fans of the three implementations, assisted in pointing out weaknesses in competing implementations.

  104. Re:nothing's safe, but there are obvious things to by Anonymous Coward · · Score: 0

    They get source code, but not all of it. It's not like they have access to M$'s private repos or whatever. But yeah, some vanishingly small proportion of people can audit Windows, after (presumably) forking over a ton of cash and signing an NDA in blood. I cannot imagine what their lawyers have put into that NDA, but they're not considered to be bad at their jobs, and this is likely to be one of the more important legal documents that M$ has generated.

    I could talk about how incredibly fucked you would be if you violated that NDA, but let's just say that anything like a backdoor is [a] probably not included in the source you get to see, and [b] unlikely to be disclosed if discovered.

    tl;dr The terms "auditable" and "publicly auditable" have great differences in definition, purpose, and relevance to this conversation. Frankly, you appear to be an idiot, and probably should avoid any further such demonstrations of your ability to expel nonsense from a text entry device.

  105. Re:we already do that for QC. All maintainers see by romons · · Score: 1

    Ah, so the NSA doesn't have root access to kernel.org's servers? If they've tweaked the compilers they use to generate the source in the way Thompson suggests, nobody except the tweakers would ever know. You could scan the source from top to bottom and never see anything wrong.

    --
    Go to Heaven for the climate, Hell for the company -- Mark Twain
  106. Re:Obama Fellatio HQ by Anonymous Coward · · Score: 0

    Ok, trying to unserstand this in whole so I can repond on topic. Not sure if your main language is English, but right or wrong it's what I got an I will do my best.

    "I think that a government that is likely to give you socialist healthcare is also not likely one that is going to disband an agency like the NSA"

    Oh a agree, a very good observation.

    "The "perfect" laissez-faire society would be the one without an NSA. Now granted there is no such thing in the real world and it would just mean going over that civil vs. economic liberty thing again."

    Yes and no, the US did restrict a lot of this big brother stuff for many many years while wars and many other factors came up to intervene in this and ... wel there we are. A good subject but it is a big subjects for another day.

    I find one things that usually makes the pont I am trying to make pretty clear ando do you it's not too hard to explain is this.

    Who do you trust to spend your money and make wise savings decions- for your own good, and that of our family?
    If you answer the state to the above query it stikes me as rather short sighted. Don't take my word for it,the state steals mah money at a truly alarming rate. Don't take my word for it, if I am wrong, please show me the evidence.

    I do wish you good luck.

    No to sign off, I hope you consider my words honestly, I meant them as such and with respect and tried to be honest and to present talk I hoped would ring true to you; I do hope you give thiese things thought, we must be able to discuss, not just fight. If we do not hang alone we will surely dis seperately.

  107. they'd need root on EVERYBODY'S system by raymorris · · Score: 1

    Issues originating from kernel.org can and have been seen and fixed because each of the thousands of developers has their own copy and sees all changes. An attacker would need root access to everybody's desktops, or at least they'd need to know who might be interested in that area of the kernel and root those developers machines.

  108. You want security? by Anonymous Coward · · Score: 0

    If you're worried about security go do OpenBSD. We know, it's not as well supported and it's under the BSD license. But if your main focus is security that's what works. Otherwise you can read up on the NSA articles for hardening Linux distributions, and don't forget to encrypt!

  109. Thanks to Dective Stu Pitt by Gigayear · · Score: 1

    Knock, knock, ... The clincher is at the end of the "Computer Forensics for Prosecutors" document. This is not quite the evidence for a Truecrypt back door! Guess who's coming to dinner for Part 2 and 3? From the Computer Forensics for Prosecutors pdf, page 17: "Detective Stu Pitt will take over for Part 2: and, "Tomorrow, Detective Laughlin Foo will conduct Part 3"

  110. Re:If it is off - it might get stolen by someSnarkyBastard · · Score: 1

    No, encryption won't get your data back, that's what backups are for. Encryption does mean that the thief cannot skim your passwords and whatnot before fencing your computer at the local pawnshop. You might not have the data anymore but no one else should be able to get it either.