First, most SMTP travels without encryption.

Second, it's unfathomable to me to imagine the NSA isn't doing their damnedest to obtain all private keys. I have no idea how many they do have, but it seems foolish to assume they don't have a specific private key.

Why do you think the NSA would regard private keys as some kind of sacred ground? For example, they could go after it the same way the Chinese do - phishing attacks against employees. They most certainly use those techniques outside the US, how can you be sure they don't within the US?

I could never pretend to be sure they -are- doing it, but it seems a lot more difficult to be sure they -are not-.

Most SMTP does, but does most SMTP that originates or terminates at Google Mail? I don't think so.

(Here it's worth noting that mail between Google Mail users doesn't ever hit the public Internet in plaintext SMTP).

I do not think it's unfathomable that NSA has Google Mail's public key. I do think it's unfathomable that, having illicitly obtained that key, their possession of it wouldn't be one of the most closely guarded secrets in the agency.

Thank you for acknowledging that it is fathomable that NSA has Google Mail's keymatter, and that if they do, it would be one of the most closely guarded secrets in the agency, something they would burn other programs, and make other cover stories, to obscure.

The term "direct access" may have been fuzzy speak, and indicative of an "impedance mismatch" between what different concentric layers of the NSA knows. The author of the PRISM deck understood it to be "direct access" based on what he'd been told, and the low-lag operation he'd seen. But perhaps that was still be FISA-order based, just really fast: an analyst flags a name at their terminal. The name is forwarded the Google and the FISA court. Google does its "review" but knows a request of exactly this specific form always wins -- they don't get to challenge the reasons for the request, which they don't even see. Now it's 'reviewed', the SFTP dumps begin... but they aren't one-time, but perhaps daily... or even hourly or faster... to keep up with the target's ongoing mail activity. (They didn't go through the trouble of using one of their thousands of requests just to get old activity, did they?) To the PRISM deck authors, that still feels like "direct access" – and colloquially, it is.

But given compartmentalization within the NSA, what if some of the data is arriving via another, deeper capability? The PRISM deck author, the average analyst may just think it's from the other process. It's not their business to know more; the rows/records appear in their tool, and they get on with their work, happy for the bounty of info from other 'acquisition' programs which sometimes (often!) work in mysterious ways.

Since there's already a program (Ambinder reported on it) called PRISM that pertains to dropboxes used to handle data from FISA requests, Occam's Razor tells me that it's more likely that the slide deck author was referring to direct access to these dropboxes than it is that NSA would somehow have allowed it to become common knowledge within NSA that they had a capability to unilaterally take data from Google Mail.

Occam's Razor? Really? No question of trust enters your mind?

What percentage of email stays within gmail?

Main point - I'd be willing to bet that the NSA collects as many private keys as it can. Can't prove it, don't need to. I'll conduct myself as if they have all the private keys. That's a loss of freedom, and that's not what the authors of the fourth amendment intended.

Some percentage. It's also been reported that one tactic used by terrorists or suspected terrorists was to share a login to an email account - editing unsent messages that live on the email provider's servers in draft mode. Email monitoring won't catch those.

The same technique used by former CIA Director David Petraeus and Paula Broadwell to communicate.

Plaintext mail is only encrypted in transit when both endpoints are using encryption. Google cannot transmit secure messages to an insecure endpoint because the endpoint wouldn't know what to do with them. I think nobody knows what percentage of Gmail gets sent to foreign servers without encryption, similarly for received messages, but I am surprised by the claim that most SMTP is unencrypted.

We agree that there is no magic that makes TLS work for SMTP servers that don't support TLS.

So is your logic basically that even if most SMTP is unencrypted, that doesn't affect most Gmail because most Gmail is sent between Gmail accounts? If that isn't your logic, and we discount internal mail, I cannot understand how the majority of mail originating or terminating at Google would be encrypted, provided the claim that most SMTP is unencrypted is also true. Further pedantry, SSL can be used instead of TLS.

SMTP between Google Mail and any server that supports TLS SMTP is encrypted. We seem to have identified one case --- inbound SMTP to a Yahoo MX --- where that TLS connection does't happen.

SSL and TLS are for the purposes of this discussion the same thing; the distinction between the two is actually less important in SMTP than it is with HTTP.

See my update: https://news.ycombinator.com/item?id=5886826

It'd also be vastly easier to do once, covertly, and then keep secret, versus a live connection that mirrors them the plaintext copies. I'm not so sure they wouldn't just do both.

You're saying that despite the fact that everyone who hits Google Mail with Chrome uses a ciphersuite for which Google's private RSA key only works if you actively man-in-the-middle the connection, no matter how many hard drives you have in Utah, that NSA stole Google's private key, and then (I repeat:) documented that fact in a slide deck for NSA analysts?

You could more easily and credibly argue that NSA has solved the conventional discrete log problem.

I think you may be forgetting that it's not all-or-nothing. Not everyone uses Chrome.

I can't speak to a slide deck; We've only seen some slides for one program (PRISM). I am quite sure that NSA has several different programs variously encompassing collection and decryption. Hopefully in the next few days or weeks we'll see details about more of them.

I don't think it's beyond the realm of possibility for a nation-state adversary with a ca. $10bn annual budget (that happens to be the same country where Google lives) to get a copy of Google's key, no.

Far more than enough people use Chrome (or a different browser with cert pinning) with GMail that such an activity by the NSA would already have been tripped.

This is how other hacked SSL certs have been caught in the wild, remember? Do you think Iran has more GMail users than the U.S.?

Even my own S/MIME private key the NSA wouldn't be able to get a hold of without actually having to take my smartcard, and I'd certainly notice that.

Either way, there's something that the NSA has actually screwed up so I'm honestly a bit surprised that people are still arguing so much about a FISA compliance API. That horse is already essentially dead and buried. So dead and buried that others are saying that tptacek is tearing down a strawman for still mentioning it...

I am talking about entirely passive, offline decryption attacks, not MITM. Think beam splitters.

I'm sure there are browsers out there that won't negotiate PFS DHE modes with Google (which were only enabled a year ago serverside anyway). NSA has had long-haul and undersea fibers tapped for many years.

Cert pinning won't help because it's not MITM.

Then we should definitely consider DDG, a much smaller company in the same country, sharing its keys with NSA. They too might be under some gag order that not only stops them from saying that they are compromised but also gagged to say that their users are anonymous so that all the terrorists, law breakers and cheating husbands use this service because of a false sense of security. It is not beyond the realm of possibility.

But everything that is plausible is not probable.

Again, just to keep stomping on this bit of urban legendry: while courts can issue gag orders for FISA directives, they cannot compel people to lie.

And I agree with it. I was addressing a different view altogether. There seems to be a very widespread paranoia that the worst possible event is the one that is occurring and that all entities but the user are collaborating willingly to make it happen. What is surprising is that most of the people here are US citizens who at least have some of their rights intact, enough for the companies to fight back as they have publicly acknowledged that they do to as much extent as possible. I am more worried about the legal requests from US government for data about non US citizens. Does there even exist a legal system to prevent mass unmonitored snooping on them?

> Then we should definitely consider DDG, a much smaller company in the same country, sharing its keys with NSA.

Do we not? The only reason to think that the situation for Google and DDG is different is that DDG may be insignificant enough to ignore.

You keep confidently asserting that, but many of the exact same compartmentalization and security procedures which protect the private keymatter also make a secret private key disclosure easier to keep hidden.

How would we know otherwise?

As you note, that "would be a more outrageous and damning discovery" - so there's more incentive to keep it closely held. It would help the NSA do what it feels it must, simply by using its other network taps. And, it would help minimize the risk of discovery without involving extra employees and ongoing connections, all while retaining the ability for Page/Drummond/etc to deny involvement.

Those add up to making a key compromise more attractive for NSA and Google than the alternatives.

TLS client authentication allows the server to detect when an active MITM attempts to get into the connection[1]. This means that if you hold the theory that the NSA is acting as a MITM with Google's private keys, you also have to assume that they know they'll be detected the second anyone tries to use a client certificate to connect.

[1] http://security.stackexchange.com/questions/26142/do-client-...

If you have the key from the server, and it's not using a cipher suite that supports forward secrecy, then you do not need to actively MITM to decrypt the traffic. All you need is the long term key and the intercepts. You can then decrypt the session key from the initial connection setup.

This is why the DHE/EDH modes exist. It uses DH to agree on a session key, then uses the long term key just to ensure the DH agreement hasn't been actively mitm'd. The session key is never transmitted or permanently stored, so once the connection cache expires, nobody can decrypt retroactively, not even the parties to the conversation.