All good points if you're stopping run of the mill hackers or snoops. Some people are worried about Five Eyes, China, Russia, and other High Strength Attackers. Author misses that the only proven approach to surviving them are high assurance security engineering and/or obfuscation + diversity + battle-hardened software. There's no H.A. FOSS for this so gotta do the latter. GPG is specifically mentioned in leaked slides as a pain in the ass for NSA: true going back to Zimmerman's PGP. GPG also runs on many hardware architectures and buying old hardware (esp RISC) is a good way to dodge any subversion programs that are going on. So, the best route to high security email is GPG + FOSS OS + diverse, old hardware behind a guard for interface level protection and preventing them hitting the lowest (weak) layers of the old system. Easy to use, cheap, and pretty? No, but high security setups rarely* were.

This, with contractor developed implementations, is one of the ways the NSA's own black programs protect their information from their opponents. Same is true for Five Eye's. So, it has both stopped them and they rely on similar approaches. That's best endorsement an encryption product can get. That so few people use it has more correlations to NSA SIGINT effectiveness than GPG's. ;) So, per INFOSEC history's lessons, we let people develop (and PROVE!) better solutions that don't have GPG's problems. Meanwhile, we use GPG, improve its interface, and make solid workarounds to any issues with it that don't violate security arguments. Only new scheme I've seen with strong security properties is Tinfoil Chat. Everything else usually has a weak TCB allowing bypass or an unproven design/implementation they might covertly beat. I'll stick with what works until situation changes.

*Note: Capability, tagged, and language-based methods can be nearly identical to insecure product in functionality with better, easily-done security. They're the exception, though.

Nick P, Security Engineer/Researcher (high assurance focus)

PL/I is what many mainframe applications were written in. MULTIC's was written in a similar language because it prevented errors you see in others. IBM's mainframe OS IIRC was written in a runtime-less version called PL/S. They considered it a secret weapon for a combination of productivity, performance, safety, and safety/speed tradeoffs. There are two papers you can find with Google on it. Interesting part is how you can put identifiers in each function to control how compiler will transform it to machine code. That both allows and documents tradeoffs you make on a per module/function basis. Mainframes set the gold standard in reliability with often 30+ year uptimes so I think it's unwise to laugh at their design and implementation choices. Unlike my UNIX/Windows boxes, those PL/S and PL/I apps virtually never fail. Language design probably contributes a little bit. -Nick P

http://www.throwww.com/a/7bn
Also has implications for society. Many of his predictions have been solid for years after writing the essay.
- Nick P

Certain industry members are already doing it so you're wrong in the micro sense. In the macro sense, I totally agree and I've stayed out of the market specifically because of their power over U.S. citizens. I already know the parallel construction strategy they'd use against me. Good news is some people overseas have a chance of building something and I can at least teach people how to do it right in my various essays. More people learn from it every year although single digits lol.

A familiar name. :) You talking about a message that the best opportunity is to ally with NSA to subvert things because otherwise won't get hired? I agree. Further, I still promote my mantra of judging what a person produces rather than the person themself. Anyone can be had in security of all types. Trust but verify: more than one person working on stuff with controls and review activities to ensure stuff is being done right. No guarantees but much better than guilt by association. Besides, most malicious insiders I've seen looked great on the surface. -Nick P

I agree on the public competition. The good news is that we learned much of what we need back in Orange Book days when everyone was sharing stuff publicly. Dozens of papers on high assurance security. Academia and commercial sector has only added to this. The thing that trips people up is it's scattered everywhere. That's why I've been making integrated frameworks like I referenced in the link. Contrary to your belief, the NSA *does* tell us how to build something secure although they skirt on the requirements a bit. Just apply Common Criteria EAL6-7 to a system like SAFE or CHERI at every layer and integration point. Add EMSEC and physical security. Done. It will take time and cost you plenty, but it's doable. They'll even certify it because they can then export restrict it and kill your ROI. ;) I'd have it evaluated privately by top security engineers against their criteria and NSA's. Then, they post a signed message on their web site with the evaluation, optionally password protected. (Or email it.) Such methods were how I did things in private sector in the past.

Read the link I posted in my original post showing what a high assurance secure design takes. Now, look at all the designs you referenced and typical commercial development practices. You should see a *HUGE* gap between the two. For starters, the design must be as such that every state the system might be in is known, every error state is shown to fail safe, only the strongest configurations are used, an inspection happens for every known weakness, safe subsets are used for the coding, those are extensively tested, covert channel analysis, minimal TCB, and so on. Such methods would've prevented Heartbleed and AES timing attacks among others. Yet, companies time and time again do whatever maximizes profit. And then the software gets smashed.

Security against High Strength Attackers often takes at least 30% of the project budget. It also takes many compromises on features and hurts time to market. On the other hand, there's some companies doing at least medium assurance with good results. Example: Matasano's review of Secure64 DNS on SourceT OS says they couldn't begin to figure out how to do a code injection on such a design. Sentinel's HYDRA firewall got similar remarks from NSA evaluators a while back. Two high assurance designs still available are Boeing SNS and GHS INTEGRITY-178B. All are in use by defense contractors to protect high value assets. Such solutions aren't cheap or pretty, though. So most companies buy cheap, full-featured alternatives that are developed with commercial best practices (read: hackerbait). That's why *those* products keep getting hacked.

What does all that nonsense have to do with a VPN? Do you even know what they do? A VPN protects the secrecy, integrity and authenticity of communications between two points. This has been done to high assurance. Repeatedly. NSA still relies* on some of these to protect their communications from foreign nation-states. You can leverage strong end-to-end VPN tech to protect all kinds of other apps from eavesdropping if the parties on each side trust each other. The tech can also be leveraged in anonymity schemes that encrypt links or circuits. It's a building block along side other building blocks. I've gotten a ton of mileage out of mine in the past with zero evidence of compromise despite clever efforts.

Learn how it works, learn how it can go wrong, learn what it looks like done right, and start doing it right avoiding anything that's known to be wrong. It's not rocket science: just a very simple concept quite alien to most COTS and FOSS products. An exception is Micro-SINA VPN and Turaya VPN. They at least kept the TCB tiny and modular.

*They also largely stopped buying high assurance products minus a few for select critical sites and mostly killed off that market. A combination of that, poor organizational security practices, and the post-9/11 push to knock out obstacles to info sharing have led to most of their security breaches. It doesn't say anything about the quality of the good stuff.

One of the earliest secure (at the time) systems was a VPN: the BLACKER VPN. NSA couldn't hack it. There were numerous products with this capability under the banner "crypto seal" that were evaluated in 90's, including GEMSOS. The NSA's Type 1 HAIPE is a modified IPsec that passed their rigorous Type 1 development and evaluation process. Navy researchers also finished an EAL7 IPsec VPN that got canned just before certification because there was "no market for it" per management. Further, there's been many link encryptors and mail guards (which support crypto) that made it to the top level. The result is that you *can* build secure VPN's. Private companies, NSA, and academics have all done it. You must clearly understand where the risks are, mitigate them in the design, and do the software lifecycle with a EAL6-7 type process. A rare few companies are using high assurance methods, but almost zero FOSS projects are. They use insecure languages, libraries, OS's, firmware, and hardware. Guaranteed to be hacked. Want to know what it takes to build something secure? I included some of the requirements in the conversation below:

http://www.schneier.com/blog/a...

Examples of better approaches and some exemplar secure products:

https://www.schneier.com/blog/...

I noticed people fighting over FOSS vs proprietary philosophies a long time ago. They acted like these two are all there is. I posted this essay arguing there's a large variety of models with some combining proprietary and open source: https://www.schneier.com/blog/... One of the first mainframes, Burroughs B5000, was sold quite profitably with the customers getting the source code and able to extend it however they wanted. They could also submit changes back to Burroughs to include for everyone. The continued and significant funding ensured the system kept getting improved. The openness has many of the benefits of FOSS. They later closed the source like QNX did, but I could see a contract where the customers get the current and future source indefinitely so long as they pay. So, it's nice to see a new venture that challenges the false dichotomy of proprietary, FOSS, or nothing else. There's lots of mixes. I look forward to seeing how this scheme works out.

I've done an analysis based on what's in their paper and posted it to Schneier's blog. Link below.

https://www.schneier.com/blog/...

Spoiler: it's not trustworthy but it's good work in progress.

Nick P
Security Engineer
(High assurance security focus)

I posted my rebuttal to and analysis of this on Bruce Schneier's blog. Link below. https://www.schneier.com/blog/...

China and Russia are certainly involved in cyber espionage, especially for state secrets or intellectual property. I was simply pointing out that the US is the main country talking about how we have to be worried about cyberwar and is also the main country using a vast arsenal of cyberweapons against most developed nations, including allies & neutrals.

This is both a nice irony and a potential explanation for why we know neither specifics of cyber weapons nor how to stop good ones.