Perfect Forward Secrecy

[Skm1091]

How does it work exactly again?

[MrBogosity]

It's based on public-private (asymmetric) key encryption:

If you have someone's public key, you can encrypt something that only they (or whoever has the private key) can decrypt.

Plus, only someone with the private key can digitally sign something, and if you have the public key, you can verify that signature, and confirm that it was signed by someone with that private key.

In a normal SSL/TLS key exchange, you have the server's certificate, which is signed by the CA (and browsers are hard-wired with the public keys of thousands of CAs) and includes the server's public key.

So your computer grabs a random number and encrypts it with the server's public key, and sends it to the server. The server decrypts it with the server's private key, and the handshake uses this securely-transmitted random number to generate the session key, which is the "secret" (symmetric) key that's actually used to encrypt the connection, and unlike asymmetric encryption is two-way.

The job of any good protocol is to make a hacker resort to brute-forcing the session key. And if any hacker successfully does so (which realistically would take centuries even with all the computers in the world working on the problem), all they get is the data from that one session, not from other users or from the next (or previous) times you connect.

BUT...

If someone (say, the NSA) records all of the traffic, and then somehow gets their hands on the server's private key, they can decrypt the entire conversation after-the-fact, because they'll be able to decrypt the initial handshake. So if they go after websites wanting their private keys, and the websites cave, they get ALL of the unencrypted traffic for as long as those keys were valid. A concern is that a website is more likely to cave and give the NSA an expired private key, since that doesn't compromise the integrity of the site, but with the NSA recording all of this traffic they'd have LOTS of past traffic to decrypt and spy on.

Enter Perfect Forward Secrecy.

"Forward" refers to "forward in time," meaning if someone records the traffic, they won't be able to decrypt it EVEN IF they later get their hands on the server's private key.

It works essentially as above, except:

Instead of using the server's public key for handshake, the server generates a temporary public/private key pair, known as "ephemeral" keys, and sends the ephemeral public key to the client, signed with the server's private key (the original one, not the ephemeral).

The client receives this ephemeral key, and verifies via the server's public key that yes, this new public key comes from the right server. It then works basically the same as before, using the ephemeral keys for the handshake instead of the server keys. Once the session key is generated, the ephemeral keys are discarded.

Now there is NO POSSIBLE WAY the NSA or anyone else can decrypt the traffic after the fact, even if they get the server's private key, since the ephemeral keys which were used to generate the session key no longer exist anywhere in the universe!

Now they have to resort to brute-forcing the session key. And good luck with that.

[Skm1091]

It's based on public-private (asymmetric) key encryption:

If you have someone's public key, you can encrypt something that only they (or whoever has the private key) can decrypt.

Plus, only someone with the private key can digitally sign something, and if you have the public key, you can verify that signature, and confirm that it was signed by someone with that private key.

In a normal SSL/TLS key exchange, you have the server's certificate, which is signed by the CA (and browsers are hard-wired with the public keys of thousands of CAs) and includes the server's public key.

So your computer grabs a random number and encrypts it with the server's public key, and sends it to the server. The server decrypts it with the server's private key, and the handshake uses this securely-transmitted random number to generate the session key, which is the "secret" (symmetric) key that's actually used to encrypt the connection, and unlike asymmetric encryption is two-way.

The job of any good protocol is to make a hacker resort to brute-forcing the session key. And if any hacker successfully does so (which realistically would take centuries even with all the computers in the world working on the problem), all they get is the data from that one session, not from other users or from the next (or previous) times you connect.

BUT...

If someone (say, the NSA) records all of the traffic, and then somehow gets their hands on the server's private key, they can decrypt the entire conversation after-the-fact, because they'll be able to decrypt the initial handshake. So if they go after websites wanting their private keys, and the websites cave, they get ALL of the unencrypted traffic for as long as those keys were valid. A concern is that a website is more likely to cave and give the NSA an expired private key, since that doesn't compromise the integrity of the site, but with the NSA recording all of this traffic they'd have LOTS of past traffic to decrypt and spy on.

Enter Perfect Forward Secrecy.

"Forward" refers to "forward in time," meaning if someone records the traffic, they won't be able to decrypt it EVEN IF they later get their hands on the server's private key.

It works essentially as above, except:

Instead of using the server's public key for handshake, the server generates a temporary public/private key pair, known as "ephemeral" keys, and sends the ephemeral public key to the client, signed with the server's private key (the original one, not the ephemeral).

The client receives this ephemeral key, and verifies via the server's public key that yes, this new public key comes from the right server. It then works basically the same as before, using the ephemeral keys for the handshake instead of the server keys. Once the session key is generated, the ephemeral keys are discarded.

Now there is NO POSSIBLE WAY the NSA or anyone else can decrypt the traffic after the fact, even if they get the server's private key, since the ephemeral keys which were used to generate the session key no longer exist anywhere in the universe!

Now they have to resort to brute-forcing the session key. And good luck with that.

You have to get the latest version/update of chrome or firefox right?

Also I read that you know you have it if you have it if you click on the lock icon and in conection it reads something like ECDHE_RSA etc the letter E being important.

I know someone who have the latest update of chrome but still has RSA and no E for some reason

[BogosityForumUser]

I wanted to clear up two misunderstandings.  The first is  the mix up between session keys and ephemeral keys.  They describe different things and in the case of ECDHE and DHE, there are three keys that are ephemeral, one that is the session key and two that aren't.  Basically, session keys are the keys used to encrypt the session and are contrasted against long-term keys (which are used for many sessions).  Ephemeral keys are keys that are generated and then discarded after use as opposed to static keys (which can be used multiple times).  It is important to note that all four combinations of the above are possible (but some are more rare than others).  In an ECDHE or DHE exchange (there are other systems that can do this too but they are not really used), they use some fancy math such that even if the handshake were not encrypted at all and you know exactly what the two ephemeral keys are, the session key, which is also ephemeral, is still a secret. 

As for support, both the client and server have to be able to use the same combination of parts, which are known as a cryptographic suite.  This means that even though different clients have supported DHE and ECDHE for over a decade, they could not use them because servers don't.  My guess is that if you are using any version Firefox, Chrome, or even Internet Explorer on Vista or later and not seeing a PFS capable key exchange, my guess is that the server in question doesn't support it.  You could check that here:  https://www.ssllabs.com/ssltest/

[Skm1091]

I wanted to clear up two misunderstandings.  The first is  the mix up between session keys and ephemeral keys.  They describe different things and in the case of ECDHE and DHE, there are three keys that are ephemeral, one that is the session key and two that aren't.  Basically, session keys are the keys used to encrypt the session and are contrasted against long-term keys (which are used for many sessions).  Ephemeral keys are keys that are generated and then discarded after use as opposed to static keys (which can be used multiple times).  It is important to note that all four combinations of the above are possible (but some are more rare than others).  In an ECDHE or DHE exchange (there are other systems that can do this too but they are not really used), they use some fancy math such that even if the handshake were not encrypted at all and you know exactly what the two ephemeral keys are, the session key, which is also ephemeral, is still a secret. 

As for support, both the client and server have to be able to use the same combination of parts, which are known as a cryptographic suite.  This means that even though different clients have supported DHE and ECDHE for over a decade, they could not use them because servers don't.  My guess is that if you are using any version Firefox, Chrome, or even Internet Explorer on Vista or later and not seeing a PFS capable key exchange, my guess is that the server in question doesn't support it.  You could check that here:  https://www.ssllabs.com/ssltest/

So it might not work because the computer and software is too old or not compatible?

How does not having PFS affect sight like duckduckgo?

[MrBogosity]

You have to get the latest version/update of chrome or firefox right?

I think all modern browsers support it.

You can make sure your browser supports it here: https://www.ssllabs.com/ssltest/viewMyClient.html

Scroll down to "Cipher Suites." The ones that use Forward Secrecy are market. It's best to have them at the top.

Also I read that you know you have it if you have it if you click on the lock icon and in conection it reads something like ECDHE_RSA etc the letter E being important.

There are a number of different ones; it'll either have DHE (Diffie-Hellman Ephemeral) or EDH (Ephemeral Diffie-Hellman) somewhere in the cipher name.

If you're using Firefox, the Calomel extension will tell you if the site's using PFS (and other useful info).

I know someone who have the latest update of chrome but still has RSA and no E for some reason

Chrome works fine for me on Windows 7 and Linux Mint 16. Have him check the above site.

[MrBogosity]

So it might not work because the computer and software is too old or not compatible?

If you go to the site I linked to, you'll see there are a bunch of them in order of the browser's preference. It'll keep going down that list until it finds one the server can use. Both sides have to agree.

How does not having PFS affect sight like duckduckgo?

DuckDuckGo has PFS, but hypothetically, if the NSA were collecting all of their traffic, then later on they could go to DuckDuckGo and demand the server's private key. If DDG acquiesced, then the NSA could go back over all their collected traffic and decrypt it, and see what you were searching for, what the results were, etc. PFS stops that from happening.

[MrBogosity]

Here are a couple of good intro videos on the Diffie-Hellman exchange that BogosityForumUser was talking about (doesn't cover PFS):

[yt]ko62sibi668[/yt]

[yt]dRUVG7YI1_k[/yt]

[Skm1091]

If you go to the site I linked to, you'll see there are a bunch of them in order of the browser's preference. It'll keep going down that list until it finds one the server can use. Both sides have to agree.

DuckDuckGo has PFS, but hypothetically, if the NSA were collecting all of their traffic, then later on they could go to DuckDuckGo and demand the server's private key. If DDG acquiesced, then the NSA could go back over all their collected traffic and decrypt it, and see what you were searching for, what the results were, etc. PFS stops that from happening.

sites like Duckduckgo don't  make any record of your searches, do they?

[MrBogosity]

sites like Duckduckgo don't  make any record of your searches, do they?

I know StartPage doesn't. Not sure about DDG. (Edit: and StartPage uses PFS.)

But yeah, that could be an issue: you do all the encryption and PFS and everything, but they record logs and the NSA just asks for the logs...

[Skm1091]

I know StartPage doesn't. Not sure about DDG. (Edit: and StartPage uses PFS.)

But yeah, that could be an issue: you do all the encryption and PFS and everything, but they record logs and the NSA just asks for the logs...

what about IXquick?

[MrBogosity]

what about IXquick?

Ixquick actually has a Green 100% shield from Calomel, which you can't get without PFS. They claim not to record IP addresses, but they don't say anything about not logging searches.

[Skm1091]

another question if you have laptop with PFS and a desktop that doesn't, what happens?

[MrBogosity]

another question if you have laptop with PFS and a desktop that doesn't, what happens?

I don't get what you're asking. PFS support is in the web browser, and it happens when you connect to a server using TLS.

[Skm1091]

I don't get what you're asking. PFS support is in the web browser, and it happens when you connect to a server using TLS.

I meant what happens if your laptop browser has it and your desktop doesn't