"Encrypt all data" is a vague term. For example, would that include encrypting it while a CPU is processing it? What about when the CPU is writing it to RAM? What if the RAM is on some other computer in the rack? What if it's in some computer on the other side of the world?

I'm not sure what Google's public statements on this have been, but if you want to research it, be sure to distinguish statements regarding user data at rest from those regarding user data in transit.

"the NSA/CIA could just have agents infiltrated at Google, to get access to a lot of that data" -- this would be really difficult, because no single person at Google can just sudo in some system and feast over sensitive data. Any access to user data or other highly sensitive data needs to go through a stack of authorizations, the granted access will be scoped, and we have obsessive amounts of logging in place even for trivial stuff let alone sensitive systems and data. One thing that surprised me with the Snowden leaks is that the NSA's "checks and balances" seems to be orders of magnitude inferior to what we have at Google; something like that is unimaginable here (esp. if you can believe the NSA in that they don't even know which documents were accessed). Even a conspiracy involving several infiltrated googlers at the right places couldn't do it without anyone noticing, because they'd need to sabotage code and configurations that live in repositories that thousands of engineers have access to (and have enforced code-review workflows); the internal openness of our systems is in fact among our best defenses against sabotage.

You're right. And he's right too.

Standalone IPsec is supposedly nearly non-existent, but there's a plenty of L2TP/IPsec traffic out there.

> IPSec didn't exactly take off > IPsec (s is in lowercase) is the standard to securing L2 connectivity and it has been ubiquitously used for site-to-site and client-to-site connectivity for ages

The question wasn't whether the standard exists but whether it's widely used. Your claims don't sound plausible to me as I've yet to work on a network (corporate, .edu, .gov) where IPSec is used – everyone focused on protocol level security like SSH or SSL instead.

SMTP-TLS should fix that, but then the problem is that many email providers don't support that.

What raidi and other said. But also, do not assume that we didn't encrypt any of the backend backbone transfers, or that some specific kind of information was exposed before -- for one thing, when we make inter-DC backups/replication of data that's already stored in encrypted form (you gmail folders and such), it's likely that we just ship this data around without bothering to decrypt and re-encrypt it, which would be wasteful and pointless. (I'm not a intimate with netops here, just making educated guesses like anybody could do.) Also there's some significant data that needs no encryption, e.g. the gobs of public youtube content that we have to mirror and cache in a thousand places.

We have tons of our own stuff moving through the same pipes (proprietary source code, all files in our corp network filesystems...), so it's our best interest to protect these. I suspect most of the unencrypted traffic is actually what the NSA would call "metadata" -- if valuable information can be mined from simple metadata like phone calls, I guess even better stuff can be derived from extremely rich RPCs/protobufs even if the core information was already in encrypted fields. Anyway the more comprehensive encryption support should turn our backbone into a wasteland for spooks.

In this context eavesdropping is probably far more likely than MITM.

Quite apart from MITM being an active attack only needed (ish) for manipulation of the transferred data, at the throughputs likely involved here and the fact that leased lines are used, MITM would probably provide far too much hassle for its worth.

These are private circuits between datacentres, and as such have always been in the "assumed secure" category.

Agreed, I first thought the title said that Google was decreasing the key size of the crypto to speed up the traffic, and that the story was a negative one.

I work for TeliaSonera and I can tell you that it's very standard for us to use VPN connections between worldwide datacenters.

Especially if you design everything about individual components being potentially either backdoored or just buggy, and make it hard for failures to lead to successful outside penetration or inside data exfiltration. It doesn't help if everything is compromised fully, but if some things are not, they can usually block or at least detect problems. Defense in depth, and all.

Yep, for better or worse it's a digital life now. Good luck opting out of the cloud for your bank transactions, your health insurance claims, Amazon orders, etc. Our emails, chats and cat videos are but a small part of sensitive data that we have stored in somebody else's data centers; cynicism and Luddite rejection of the few items we can "take back" like email servers will not help much. The only solution is to fix the system. At Google, and other conscious internet services, we're doing everything we can. But users and voters have to help too. For example, yesterday it was revealed that the NSA has been able to successfully MITM users connecting to SSL-protected Google services. Now I don't want to use this to plug Google Chrome, but if you're using any browser without all bleeding-edge security features like cert pinning and PFS, then you deserve to be 0wned by various high-profile hackers.

Lack of opportunistic encryption (in the style of Hugh Daniels Free S/WAN).

General complexity and baroqueness.

IKE and various implementations -- keying in general. True, keying is a hard problem, but I'd prefer a simple default which was secure against passive eavesdroppers, and then progressively better systems.

No?

No, since they don't fall under CALEA. It's possible Google Voice specific stuff would need CALEA access, but I'm sure they handle that at a higher level in the application.

Google needs this kind of stuff not to defend against just NSA but also every other intelligence agency out there. For 0.1% of the IC's annual budget, I could give a third-tier country (Belgium? Nigeria?) about 5% of NSA's capability. That, IMO, is the true risk here.

Damage control yes, but not necessarily external.

Google probably knows even though they're mostly in good terms, this may change.

I guess they got uncomfortable with people knowing too much already and don't trust too much

If you were to actually read the article, you'll note that the project began _before_ the Snowden revelations started coming out.

let's not pretend these emails are sitting in plaintext on google's servers though. they are "fragmented and obfuscated" at rest.

The PGP encrypted emails I sent were very secure - no one ever read them!

It's all about protecting the data from non-US interests, Google has probably already given the keys to the NSA.