Yeah... that might actually qualify as "all-star"
What happens to all those billion dollar wiretapping facilities all over the country once they find out they can't just siphon internet traffic into their facilities anymore?
Are you talking about IPSec? This is still optional in IPv6 and available using IPv4.
I think the reason adoption is slow is that it's not easy to convince managers to allocate people and time to it... "So, it's not yet broken but you want to fix it?"
What matters is who writes the software, how experienced they are and what the validation process is.
I can give any number of examples of bad medicine, which even if their ingredients are well publicized, documented and reviewed, they still performed badly. In what way would that prove that secret sauce medicine is equal or even more safe to use? I would never trust any medicine claiming secret sauce.
Any security can fail, but if you can't review it, the security is never trustworthy. Never. Not once! You might trust the company/producers of it, but the same goes for medicine. I might trust a doctor to give me a pill without telling me what's in it, but somehow I would not trust the same doctor if he refused to tell me what's in it.
Medicine requires a very high trust level because they can cause bodily harm. We don't trust secret sauce medicine. If you need to put the same, or even higher trust in a piece of software, why would you trust secret sauce software?
Sure, that oil which was created from snakes might cure cancer, fix your infected wound, and solve any other ills you got. It might also do nothing and thus you die.
Sure, that software might protect you from an oppressive state, hide you from mobsters with hitmen, or protect the witness. It might also do nothing and thus you die.
Sure, you personally might not be able to review medicine or software, but knowing that someone can review it will make you feel safer. It also helps to know that as soon someone does find a bug in medicine or open software, everyone can identify what things are affected by it. With secret sauce, who knows whatever else might include a copy of it if they refuse to disclose it.
it reserves the right to shut off that person’s service and will do so "in seven seconds."
This is where I feel you might be a little bit dogmatic.
You don't need the source code to audit software. Software that are heavily used are audited.
Microsoft software is probably more scrutinized that any other open source one (I'm not implying it's more secure, just that it's more analyzed).
Security is a question of trust, not a question of source code. Even if you do the audit yourself, it's a question of trust: it means you trust your own abilities to evaluate the security.
I'll go a little bit further.
Did you check that the computer you bought isn't rigged? Maybe someone can remotely control your webcam or eavesdrop your keyboard.
Did you check that the operating system you have hasn't been compromised? Maybe someone intercepted your download and patched it on the fly to insert a backdoor.
Is your home physically secure? Maybe someone is copying your hard disk every day.
You're right when you say Silent Circle should be scrutinized and criticized.
Nevertheless, I disagree when you imply that the unavailability of its source code is a show stopper. Source code only makes one small part of the security audit a little bit easier.
Security is a process, not a feature.
Without sourcecode no crypto routines can be trusted - period. Anything else might work in the fake industries, where producing marketing lies is part of a standardized way to make money, but not in the real crypto world.
Actually the right hand side is much more difficult to defeat because it involves more than one person.
Knowing that medicine is openly reviewable create a trust level that secret sauce never can achieve.
Knowing that airplane/train/building architect plans are openly accessible creates a trust level that secret sauce never can achieve.
scrutinized security can sometimes help, but, again, would you trust secret sauce medicine just because 100 000 other people has done so and to your knowledge, no one died?
Unavailability of source code is a show stopper if you need to bet your life on the chance that it will perform correctly. Everything else is blind faith, and while its true that some people will accept blind faith over "real trustworthyness", those same people also form sects who refuse medicine and trust that a miracle will magically wand cancer away.
Security might be a process, but it require an process that gives the person on the receiving end a mean to assess trust. Secret sauce is inherit impossible to do so. Historical information (like the windows example) helps, but in the end, it is just a black box with oil in it that says "made from snakes - cures everything". So far, it has in some cases worked, and in other not, and several times the sauce has been announced as "improved" with new versions. Still, would you prefer to bet your life on it, or on a open disclosed medicine which might actually have been reviewed by a third-party? Which one is more trustworthy?
So, yes, Windows does have its source code audited by customers who are willing to pay the price.
That doesn't mean that the "trusted-by-me" source has the means or the ability to give it the OK, but more that I don't have to trust you at all.
Security can only be guaranteed by the people you trust, rather than the people everyone else trusts.
They're free to use, all the source code is GPLv3 on GitHub, and RedPhone already has global calling coverage. The apps have been translated into 15 languages, and in my experience they're really dead simple to use.
This will only going defeat the "dragnet" type stuff that combs through millions of conversations looking for keywords. I guess that's something, but if you've managed to attract the all-seeing eye you shouldn't be lulled into a false sense of security because the link between your mobile and someone else's is secure.
On the other hand, mass-scale surveillance enables you to actually find targets of interest out of sea of people irrelevant to the case. Because the usual problem is, you know there are Bad Guys out there, but you don't know where. Mass-surveillance makes the search much, much less expensive. So they really care about it.
And there's also an issue of Big Data, aka. whatever data they collect on people can in the future be used in a ways we can't even imagine now but won't like when it happens. So the data itself is also a danger. Also humans make mistakes, and algorithms are not always good, and no one would like to have their home raided because some long-forgotten bayesian filter buried deep in the system didn't use logarithms properly and introduced serious errors to probability computations. That's why people care.
 - relative to what govt. sees as bad at the moment.
But I guess that governments expect large-scale surveillance to be the primary way to attract the all-seeing eye.
National security was done a certain way during the cold war, when facing highly organized intelligence services. The swarms of nutjobs, loosely herd by amorphous terrorist organizations, are much harder to detect; many people probably have high hopes about big data and statistical methods to find them.
As long as this service is commercial (which apparently it is) it will have a payment gateway, and that point can be easily blocked by a local government.
Both callers then read the two words to each-other, and if they're the same, they know there couldn't have been a MITM attack. In the case where there's a MITM attack, each caller would have different key material, resulting in a different SAS. The protocol uses hash commitment and other tricks to make this really work in practice.
They haven't published the protocol for their chat app's encryption yet, but it sounds similar to OTR. While OTR has some nice tricks for verifying authenticity by using zero-knowledge proofs, it doesn't sound as if they have support for that sort of thing, and parties would have to make a call and read a SAS to each-other over the phone.
This is one more shot at it.
At some point "good enough" has to be enough. Okay, you built the APK, how do you know I don't control the VM and just swap out that JIT'd method with one that I've altered? (Repeat this until you get all the way back to the initial power-up)
Edit: Somehow didn't see the giant "subscribe now and receive a free 30-day subscription" on the homepage.
The secure chat protocol they're using is something they developed and haven't yet published. It sounds as if it's similar to OTR, though. TextSecure (an encrypted SMS app I work on) uses a version of OTR adapted to the mobile environment, which is documented here:
Check out this video which attempts to explain this type of encryption: http://www.wimp.com/howencryption/.
The SaaS part of it is pretty necessary. In order for your phone/pad to traverse a NAT firewall there needs to be a common device that acts as a matchmaker between callers. This also solves the problem of "What if the person I'm calling is at some random coffee shop, and not at home?", where they can't set up a firewall rule.
But really, their initial audience is business people who won't blink an eye at $20+ a month to secure their communications for a multi-million dollar deal. Not cheapskates like me. :)
These applications have more emphasis on confidentiality than on anonymity.
The type of "onion routing" that Tor employs for anonymity is very difficult/impossible to pull off for applications which require extremely low latency connections, such as a realtime voice application.
In this case, they know each other and communicate encrypted. In Tor's onion routing, the server and user don't "know" each other and they communicate via an encrypted channel. Thus, if someone listens to your tor connection, they still can't see your data [and/or guess at your identity].
Or as the Tor project says, plaintext over Tor is still plaintext:
Having it as nice to have in a free country is one thing, having your life or career depend on eavesdropping free communication is another.
Surely this is not correct.
We know NSA has gargantuan parallel processing capabilities.