How does perfect forward secrecy (PFS) work
I'm in an infosec class and I stumbled upon this concept online and it intrigued me. I've also looked at a few websites and wikipedia that explain the concept, as well as a few posts on stackoverflow, but I'm still getting confused. From what I understand is in a typical HTTPS public key exchange, a browser and a server come together with keys to create a session key...if someone ever obtained a private key that derived the session key, they could see all the data that was sent between this connection, even in the past.
My understanding is that with PFS, the 'session key' is never sent , even in encrypted form. It is kept secret so that even if someone found a private key, they wouldn't be able to access encrypted recorded information from the past. Is this correct?
I also was wondering, If I am partaking in a PFS exchange call me "A", with a server "B", PFS is supposed to work with the fact that if my key becomes compromised, A and B's conversation wont become compromised because they don't know the session key. But how does "B" authenticate me as "A", if my key has in fact became compromised...e.g. how would it know the difference between me (A) or another user (C) using my key attempting to access the data.
Answer
I really like the answer on Quora given by Robert Love: http://www.quora.com/What-is-perfect-forward-secrecy-PFS-as-used-in-SSL
Let's look at how key exchange works in the common non-ephemeral case. Instead of giving a practical example using, say, Diffie-Hellman, I'll give a generalized example where the math is simple:
Alice (client) wants to talk to Bob (server).
Bob has a private key X and a public key Y. X is secret, Y is public.
Alice generates a large, random integer M.
Alice encrypts M using Y and sends Y(M) to Bob.
Bob decrypts Y(M) using X, yielding M.
Both Alice and Bob now have M and use it as the key to whatever cipher they agreed to use for the SSL session—for example, AES.
Pretty simple, right? The problem, of course, is that if anyone ever finds out X, every single communication is compromised: X lets an attacker decrypt Y(M), yielding M. Let's look at the PFS version of this scenario:
Alice (client) wants to talk to Bob (server).
Bob generates a new set of public and private keys, Y' and X'.
Bob sends Y' to Alice.
Alice generates a large, random integer M.
Alice encrypts M using Y' and sends Y'(M) to Bob.
Bob decrypts Y'(M) using X', yielding M.
Both Alice and Bob now have M and use it as the key to whatever cipher they agreed to use for the SSL session—for example, AES.
(X and Y are still used to validate identity; I'm leaving that out.)
In this second example, X isn't used to create the shared secret, so even if X becomes compromised, M is undiscoverable. But you've just pushed the problem to X', you might say. What if X' becomes known? But that's the genius, I say. Assuming X' is never reused and never stored, the only way to obtain X' is if the adversary has access to the host's memory at the time of the communication. If your adversary has such physical access, then encryption of any sort isn't going to do you any good. Moreover, even if X' were somehow compromised, it would only reveal this particular communication.
That's PFS.