
Perfect Forward Secrecy can block the NSA, but almost no one uses it - LoganCale
http://blogs.computerworld.com/encryption/22366/can-nsa-see-through-encrypted-web-pages-maybe-so
======
paulsutter
Chrome should change the lock icon to something weaker for sessions that don't
use ephemeral keys.

This may be the most important article on HN related to the NSA leaks. Fact
is, most of us haven't paid enough attention to the details of https.

EDIT: "something weaker" \- didn't mention color. People dont need to
understand "forward secrecy", the browser just needs to raise the bar for
what's considered secure. The goal is to change server-side behavior, not
consumer behavior.

~~~
tptacek
People barely pay attention to the lock icon. Why would color-coding the lock
make a difference?

~~~
IvyMike
I don't think the goal would be getting everyone to pay attention, because if
it is, you're absolutely correct.

But if you look at it as a way to spread awareness to web admins, to be
confronted with the question "how come we don't have the bestest type of
icon", it's not so bad.

A related example: I have recently been wondering how widespread DNSSEC is.

I installed the DNSSEC validator chrome plugin, and now (almost) every website
on the planet shows me a sad "no DNSSEC" icon. I can't help but feel that part
of the low deployment of DNSSEC is because almost nobody, including web
admins, gets any feedback about DNSSEC. (I am aware that there are other costs
and risks to deployment.)

~~~
tptacek
DNSSEC provides minimal value and adds significant overhead. We're better off
the less it's deployed.

~~~
IvyMike
If you're like me, and wishing tptacek would elaborate, it turns out he has in
the past. For example, this entertaining thread from three years ago:

[https://news.ycombinator.com/item?id=1234567](https://news.ycombinator.com/item?id=1234567)

Also, despite my earlier google queries about DNSSEC, everything I was reading
was pretty dry. The magic phrase to google for is "DNSSEC sucks"\--that gets
you the interesting stuff.

I haven't digested it yet, but in those results, this looks pretty interesting
from D. J. Bernstein:
[http://cr.yp.to/talks/2010.12.28/slides.pdf](http://cr.yp.to/talks/2010.12.28/slides.pdf)

~~~
tptacek
More:

[https://news.ycombinator.com/item?id=5571937](https://news.ycombinator.com/item?id=5571937)

[https://news.ycombinator.com/item?id=4071178](https://news.ycombinator.com/item?id=4071178)

[https://news.ycombinator.com/item?id=2932378](https://news.ycombinator.com/item?id=2932378)

I _really_ don't like DNSSEC. I think it's a bad design that will harm the
Internet.

------
jgrahamc
I really hate the name "Perfect Forward Secrecy". There's no guarantee in
ECDHE that the connections cannot be decrypted at some future time. All that's
being implied is that the key changes per connection.

Sure, it's 'better' than RSA with a long lived private key, but there could be
advances that would breach ECDH and make none of this 'perfect'. Such as:
[http://www.wired.com/politics/security/commentary/securityma...](http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115)
If the NIST supplied curves used by the TLS standard had a backdoor none of
this would be perfect.

~~~
tptacek
What you hate is the word "perfect". "Forward secrecy", though, has a
technical meaning: a compromise in the long-lived key material for the
cryptosystem doesn't enable an adversary to go back and decrypt earlier saved
sessions.

The link you've provided doesn't implicate Diffie Hellman; it's in an obscure,
virtually unused NIST standard that uses elliptic curves to generate random
numbers.

There are other things not to like about the NIST curves, but the methodology
used to generate them is documented (I suppose you could generate your own
using the same method) and is based on the literature on ECC from the late
'90s.

~~~
jgrahamc
Yes, it's the word 'perfect' that really bothers me. I think it gives the
general public the wrong impression.

~~~
roc
Perhaps they should call it "pretty good"?

~~~
tptacek
I just call it "forward secrecy". I think "complete" would be a better word
than "perfect", but I think that neither are necessary.

------
Strilanc
I agree with the article. Perfect forward secrecy (given master private key,
still can't figure out derived session keys) is a wonderful property.

However, it's a bit over-reaching to say it can "block the NSA". It won't stop
them from backdoor-ing your hardware/software (keyloggers, compromised random
numbers, etc). It won't stop them from storing the encrypted communication
until (for example) quantum computers make it possible to decrypt it (assuming
RSA).

~~~
lambda
Sure, it won't "block the NSA" from discovering anything about you. But it
raises the stakes.

It is much easier for the NSA to backdoor/crack/make deals with a few
telecoms, collect all of the encrypted data, and then decrypt it at their
leisure (via stealing RSA keys, getting them via legal channels, cracking RSA,
taking advantage of compromised random numbers, or the like), than it is for
them to backdoor your hardware (much larger surface of possible discovery),
install keyloggers (need physical access, much more expensive to do so only
makes sense to do in a targeted fashion) etc.

The whole point of this brouhaha is that the NSA appears to be hoovering up
massive amounts of data, which it keeps and which even fairly junior employees
at government contractors have access to and could abuse. I don't think that
anyone (or most people, anyhow), object to specific, targeted wiretaps of
targets that you have appropriate warrants for. It's the incredibly broad
based collection of all records, without targeting, for later data mining,
coupled with the first-amendment destroying demands of secrecy about
discussion these practices, that have people up in arms.

The NSA has admitted that they retain encrypted data for longer than
unencrypted, as they cannot as easily discard it as irrelevant. If you use a
protocol with perfect forward secrecy, it substantially undermines the value
of that collection.

 _Edit to add:_

> It won't stop them from storing the encrypted communication until (for
> example) quantum computers make it possible to decrypt it (assuming RSA).

Actually, it will stop them from using quantum computers to crack RSA and thus
be able to read past communications. That's the who point of perfect forward
secrecy; even if you can crack the RSA layer (or obtain the private RSA keys),
which is used for bootstrapping the authenticated encrypted channel, perfect
forward secrecy generates the symmetric key in a way in which it is never
actually communicated over that channel.

Perfect forward secrecy protocols, such as Diffie-Hellman key exchange, work
by both sides coming up with two values, one of which is secret and one of
which is passed over the channel, such that both of them can compute the same
secret value by combining the private and public values. Even if the "public"
values are intercepted, for instance by cracking RSA, you cannot determine the
secret values, because you do not have the secret portions of the keys that
each side generated.

The reason to use RSA in addition to key exchange is that Diffie-Hellman key
exchange is not authenticated; someone could MITM you, doing both sides of the
Diffie-Hellman protocol, and intercept your communication that way. RSA allows
for signing of certificates which can be used to bootstrap the authentication
process.

So, if RSA gets cracked in the future, then the NSA could at that point MITM
all of your future connections. But they could not decrypt your prior
conversations, which had been encrypted using a private key generated via a
key-exchange protocol that provides perfect forward secrecy.

 _edit 2_ :

Hmm. After further investigation, it looks like quantum computers would be
able able to break the common "perfect forward secrecy" algorithms as well. So
yes, in the case of RSA being broken due to quantum computing taking off, it's
likely that DH and other discrete log based perfect forward secrecy algorithms
will be broken as well.

Sigh. Why can't we have any NP-complete problems that work cryptographically?
While even that isn't a guarantee of security against quantum algorithms
(after all, it may still be the case that P == NP), there's a fairly strong
belief that P!=NP and that NP-complete is a disjoint category than quantum
polynomial algorithms, and so would give us a better security margin against
quantum attacks.

~~~
ReidZB
Cryptography needs problems that are hard _on average_ , not in the worst
case. This doesn't fit well with P/NP/NP-complete, which are all about the
worst-case difficulty of a problem.

For example, see the Merkle-Hellman knapsack cryptosystem [1], which is based
on the subset sum problem --- a NP-complete problem! Nevertheless, it is
broken. As you can see, using a NP-complete problem as a computational basis
for a cryptosystem is not a silver bullet.

[1] [https://en.wikipedia.org/wiki/Merkle-
Hellman](https://en.wikipedia.org/wiki/Merkle-Hellman)

~~~
cantos
Apparently it is very hard to prove results in average case complexity theory.
We don't even know if computational problems that are hard on average assuming
P!=NP exist, let alone actually designing a cryptosystem out of one.

~~~
mjn
There actually are a few "average-case complete" problems. The field was
started with this 1986 paper:
[http://epubs.siam.org/doi/abs/10.1137/0215020](http://epubs.siam.org/doi/abs/10.1137/0215020)

It's true that we don't seem to know how to build a cryptosystem out of them.
Part of it is that a cryptosystem needs something stronger than average-case
complete, a property more like _every_ instance being hard (possibly excluding
trivially easy instances that can be detected and filtered out).

~~~
cantos
Average-case complexity is a not a topic I know a lot about, and I can't
easily get the paper itself, but what the abstract seems to say is that for
some particular NP complete problem, if an efficient average case algorithm
exists for that problem then efficient average case algorithms exist for all
NP complete problems. There is no mention of showing that such an algorithm
does not exist.

My reference is Impagliazzo's 1995 survey paper "A Personal View of Average-
Case Complexity" where he lays out five possible worlds based on open problems
in complexity theory. He calls the world where P!=NP but all NP problems are
easy on average "Heuristica." This is still an open problem as far as I know.

On your second point I can say a bit more. Cryptosystems in general do not
need all instances to be hard. With RSA for example, there are all kinds of
weird attacks, like the modulus n can easily be factored if phi(n) or
phi(phi(n)) are products of small primes. There is no need to filter out these
cases because the probability of them occurring is so small. There are
cryptosystems where an arbitrary instance of the problem is as hard as the
average case. This was a notable selling point for lattice cryptosystems when
they were first invented.

In the RSA case the probability of these corner case attacks decreases with
the size of the instance. So for current parameters the probability is near
zero. However, even if you only had a scheme where the probability didn't
diminish with the instance size and there are attacks that you _can 't_ check
for, you can still securely send messages. Say the probability that your key
generation algorithm gives you an instance that is hard is 50% (or any
constant). You can securely send messages with arbitrarily small probability
of having your message decrypted by using multiple keys and breaking up your
message with a secret sharing scheme (Shamir's for example) and encrypting
each message share with each of the keys. The attacker, able to only get a
constant number of decrypted message shares will not be able to get decrypt
your message.

------
gojomo
Two notes:

(1) While Google uses forward-security on their HTTPS connections, I've not
yet seen evidence either way as to whether the SMTP-TLS connections (relaying
email to other domains) use forward-security. (The report at checktls.com
mentions only the cipher "RC4-SHA", not the key-exchange mechanism.)

(2) If one side of the connection chooses to retain its session keys, or
chooses session keys in a poor/predictable manner, or leaks information about
session keys via a side-channel (either by mistake or intent), then the
forward-security could be destroyed, and in a very subtle/undetectable way.

(This could be a cheap and sly way to grant visibility to a third-party: adopt
forward-security outwardly, but ensure your session keys only look random to
people who don't know the bug/secret-seed-shared-with-the-third-party.)

~~~
e12e
Thanks for asking this -- apparently there is no really easy tool for this (I
was thinking openssl s_client could do this automagically -- apparently not)
-- however, see:

[http://superuser.com/questions/109213/is-there-a-tool-
that-c...](http://superuser.com/questions/109213/is-there-a-tool-that-can-
test-what-ssl-tls-cipher-suites-a-particular-website-of)

And now I realized I hadn't tuned the SSL ciphers on one of my servers to not
accept (among other thing NULL ciphers... at least if that bash-script works
-- I'll have to double check).

~~~
jervisfm
You should check out [https://ssllabs.com](https://ssllabs.com). They accept a
URL and do SSL checks to determine if your server is not configured in the
most secure manner possible.

It is already interesting to run the check against online banking sites to see
first hand how seriously they take security in practice. I was surprised to
see that some banks score pretty poorly in this regard.

~~~
gojomo
I don't find an option at ssllabs.com to check SMTP (the topic of this
thread). Am I overlooking it?

~~~
e12e
No, you're not. It would be nice if they had one, though.

------
tlb
FWIW, news.ycombinator.com provides perfect forward secrecy with ECDHE_RSA.
Thanks, Nick!

~~~
e12e
Of course, there is no way for us to know whether or not yc archives a copy of
the session keys... (Not that I think yc does that, but we're still talking a
shared secret -- you need to trust both parties, if you want to trust forward
secrecy...).

------
lucian1900
I don't see how this really helps, though. The NSA can still force a CA to
generate certs for any domain they wish to intercept and MITM everyone they
care about. They are likely to have the resources for that.

~~~
e12e
In the case where providers/servers are under NSA jurisdiction (or control, in
the case of them hacking servers) -- they could also keep a copy of session
keys.

But that would force them to intercept at _many_ more points than simply
various edge routers (which is what they may or may not be doing now, having
(or not having) equipment at ISPs/TelCos).

Essentially, if you use gmail or outlook.com -- you'll just have to trust that
no one has forced (or covertly) installed backdoored crypto libraries. I do
think it is very likely security agencies (both foreign and domestic) have
agents/assets working at large companies like Google and Microsoft -- I don't
think it is very likely that they have been able to covertly subvert their
infrastructure. But it certainly is _possible_.

~~~
lucian1900
They don't need to do that much. If they control a CA and a few ISPs
(especially networks to the outside of the US, since apparently us in the rest
of the world are fair game), they can MITM anyone reliably. The only defence
is checking fingerprints, but few will bother.

------
LoganCale
Note that despite this headline, the article does correctly state that Google
now uses Perfect Forward Secrecy.

~~~
y0ghur7_xxx
Who cares? The NSA gets it's data directly from google. You need to protect
yourself from all hops between you and the one you communicate with, not only
from the hops between you and google.

~~~
bobwaycott
I'm assuming you read the article, in which it offers an explanation of how
the NSA gets Google data. Are you disputing that very likely explanation for
the theory that a Powerpoint slide somehow communicates more technically
accurate and viable information?

Obviously, Google could be lying in their most recent denial that disputes
such a claim. They are, after all, required to lie _if_ they are directly and
materially involved in the program.

On the other hand, were I the business owner of a corporation that held
millions of people's information and the NSA approached me for access, I don't
think it is at all inconceivable and unlikely that I would attempt to
negotiate not having the NSA on my network, in my machines, so I could retain
the ability to truthfully tell my users that the company did not allow direct
access to company servers.

In the article, Mr. Horowitz suggests that, given other leaks and information
we've had in the prior years regarding NSA tapping the internet, the slurping
of company data is happening at the on/off ramps to the networks, where data
is coming in/out. This _is_ far more likely than Google shipping off deltas in
cron batches. Thus, Google et al. can appear on the PRISM Powerpoint, which
just says their data was added to the system. That can mean anything, you
know. The Powerpoint presentation is hardly a source of empirical data
presenting the technical architecture of the program.

This article is attempting to help educate and achieve protection at _all
hops_ , not just the hops between you and Google. Perfect Forward Secrecy is
just for that purpose--it removes the ability to find your encrypted data
crackable via single master key decryption by using temporary keys.

So, while Google can only do so much in resisting NSLs, perhaps there is a
little bit worth appreciating here. Google can't stop the NSA from slurping up
traffic. But they can prevent that data from being massively decrypted via a
single key.

~~~
y0ghur7_xxx
> Google can't stop the NSA from slurping up traffic. But they can prevent
> that data from being massively decrypted via a single key.

I don't want to sound snarky, but, so what? If you want privacy you still have
to encrypt data end-to-end, not end-to-[google|microsoft|yahoo|facebook]-to-
end.

And, anyway, [google|microsoft|yahoo|facebook] should not know about your
stuff just like the nsa or anyone else who is not the intended recipient.

~~~
mortehu
It's not up to Google to encrypt your e-mail end-to-end, though. That you have
to do yourself. This technology exists and is called PGP.

Obviously Gmail's HTML interface can't work with these e-mails, until you get
some way to sandbox part of the DOM on the client. Search won't work either.

------
rocky1138
It would have been a fantastic effect and win for computerworld.com if their
site supported what this article talked about.

------
casca
It's odd that there seems to be no definitive instructions for nginx or apache
for enabling PFS. Given that it's clearly not obvious how to set this up, how
many here are inadvertently running non-PFS without knowing it?

~~~
baudehlo
Funny, I think in part it's because few people care. Maybe I didn't have the
right keywords, but I _just_ wrote an article about this for nginx/stud, and
it got 2 upvotes on HN.

Here's the HN link:
[https://news.ycombinator.com/item?id=5935988](https://news.ycombinator.com/item?id=5935988)

------
IvyMike
I've had a question about PFS for a while now: How 'expensive' is it to
implement?

First up, let me state for the record that I don't have personal experience
with running SSL on a server. But back in the day, generating a public/private
key pair for PGP was a semi-expensive operation. Definitely not the kind of
thing I could imagine running on a per session basis.

Since PFS requires per-session public/private key pairs, how "costly" is it?

(I understand that the goog uses ECDHE, so I guess I'm asking for a general
feel for how quickly and efficient this compares to RSA key generation.)

~~~
agilebyte
The article mentions 23% reduction in speed for ECDHE-RSA vs RSA. Another
example states between 15% and 27% reduction.

~~~
IvyMike
Thanks! I knew I should have read the article more carefully.

(The same section of the article also references
[http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-
se...](http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html)
which answers some of my follow on questions.)

------
codereflection
Gmail uses Perfect Forward Secrecy, so what? If the NSA really does have
direct access to Google's servers, then PFS will not provide you any extra
protection from them. Sure, PFS will make it harder for others to snoop. But
the current context for the general population is PRISM and the NSA.

I'm not saying that PFS (ugh, what a name, perfect, really?) isn't valuable,
I'm just pointing out that no one should think this is going to make it any
harder for the NSA to read/access your gmail account.

~~~
AJ007
The NSA is getting all of the attention, but this applies to all of the
world's intelligence services.

Even if you absolutely believe and support what the NSA is doing, you probably
have good reason to want any number of governments, foreign competitors, and
individuals from knowing what you are doing or (at the least) your financial
status.

~~~
mafribe
Sure, but if Googles stores all session keys, as is likely (key phrase: meta-
data), then the session data store is a rich and likely target for all the
world's intelligence services, and one that is not invulnerable. After all,
Google is a big organisation with a large turnover of staff.

~~~
declan
I would say that storing session keys is vanishingly unlikely and eliminates
the benefit of PFS. Google probably spends millions of dollars a year in PFS
additional handshake costs. Google then storing the session keys would be a
little like the Dutch building an expensive dike and then knocking a big hole
in it.

If you want to store data like "user X searched for Porsche 911 GTS 0-60
statistics, so let's show him some 991 Cabriolet ads the next time we can,"
you don't need to store the session keys.

------
diminoten
The line has always been, "You can't stop a determined hacker with any single
solution."

The NSA may be a group of determined hackers.

One technology isn't going to suddenly cure the whole problem. It takes a
solid security policy set at and followed by the top levels of a company, and
_constant_ vigilance to respond to threats. You're not going to stop anyone
from getting in, but you can stop them from getting anything of value, and you
can kick them out quickly and quietly.

------
lazyjones
This article seems to start out with wrong assumptions and therefore ends up
presenting dangerously wrong conclusions:

 _" Suppose, for example, the NSA was recording all HTTPS encrypted traffic
to/from joeswebsite.com in January. Then, in February, they learned the
private key for joeswebsite.com. Almost always, that lets them decrypt
everything from January, February, March and beyond."_

We should instead suppose that the NSA has had the private keys all the time
(since it started recording encrypted communication), so every piece of
communication that has been recorded can be decrypted even with Perfect
Forward Secrecy. I.e. let's assume they got Google's private key immediately
when it was last changed, then all communication with Google's servers is
decryptable (correct me if I'm wrong).

The NSA doesn't have to brute-force private keys, they just use legal/strong-
arm techniques to obtain them, so it doesn't take a lot of computing power and
time.

~~~
peter487
Yes you are wrong :D If NSA is not actively man-in-the-middling you, Perfect
forward secrecy still works.

ECDHE has been in Openssl since version 1.0.0 so its out there just not used.

Btw. Is there any addon for Firefox that shows the “encrypted communication”
details like google does?

~~~
sliverstorm
They don't have to take an active role though if they just sniff all the
traffic, right?

~~~
tptacek
Yes, they do.

~~~
sliverstorm
Whoops. This wouldn't be the first time I got public/private key schemes
muddled in my head.

------
mattme
PGP complete lacks perfect forward secrecy. Suppose an eavesdropper is
recording your email, even though they can't understand it. If your private
key is ever compromised (say by torture or subpoena), then all your previous
messages can be immediately decrypted.

> You could say that Bob losing control of his private key was the problem.
> But with today’s easily-compromised personal computers, this is an all-too-
> likely occurence. We would really prefer to be able to handle such failures
> gracefully, and not simply give away the farm.

[http://www.cypherpunks.ca/otr/otr-
wpes.pdf](http://www.cypherpunks.ca/otr/otr-wpes.pdf)

------
lucasjans
It appears this very site is using Perfect Forward Security.
[http://cloud.lucasjans.com/image/081m1V3c3O1z](http://cloud.lucasjans.com/image/081m1V3c3O1z)

------
Nursie
Does it need to be DHE or will DH do just as well? What exactly is the
difference here?

It still uses a key per connection at the least, and it's still not on the
NIST/FIPS 140-2 standards because you can't decode it after the fact so it
breaks auditing (all AFAICT, and I have looked at this stuff a lot).

That said, we're best using AES_GCM, 2048-bit RSA and ECDHE as a matter of
course, because at the very least it requires a valid, active MITM to break
and can't just be logged and scanned later.

------
mtgx
If Google is offering perfect forward secrecy for e-mails, why don't they have
the same for Hangouts (OTR with perfect forward secrecy)?

------
Sprint
How important is the difference between ECDHE_RSA and DHE_RSA security-wise?

edit: I asked because Opera showed a site's free StartCom certificate as "TLS
v1.0 256 bit AES (1024 bit DHE_RSA/SHA)". I checked with Chromium and there it
is shown as ECDHE_RSA though. This is confusing...

~~~
JshWright
They both provide PFS, but ECDHE_RSA is _much_ faster.

Do you have TLS 1.1/1.2 enabled in Opera?

------
joepub
What about more use of one-time or ephemeral email addresses? The info we have
so far seems to suggest NSA likes to track email addresses. Compare tracking
an email address that was only used to send or receive one or a few messages
with one that has a long history of use.

------
flatfilefan
Suppose the data captured is not a dump of a database but rather a https log.
Doesn't it imply that NSA has to essentially rebuild the server functionality
to make sense of the data?

