How does perfect forward secrecy (PFS) work

user_2082259 0
Viewed 10814

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.

public-key-encryption cryptography https
3 Answers

You generate a new public key for every message, and use the real permanent public key only for authentication

This was mentioned in other answers, but I just want to give a more brain parseable and contextual version of it.

There are two things you can do with someone's public key:

In many ways, authentication is the more critical/costly step, because to know that a given public key belongs to someone while avoiding a man in the middle attack, you need to take steps such as:

  • meet them in real life and share the public key (leave your home???)
  • talk to them over video (deepfakes???)
  • trusted signature providers (centralization!!!)

Generating new keys is however comparatively cheap.

So once you have done this costly initial key validation step, you can now just:

  • ask the receiver to generate a new temporary public key for every message you want to send them
  • the receiver sends you the temporary public key back to you, signed by their permanent public key. Nothing ever gets encrypted by the permanent key, only signed. No need to encrypt public keys being sent!
  • you verify the message signature with the permanent public key to avoid MITM, and you then use that temporary key encrypt your message

After the message is received and read, they then immediately delete that temporary private key and the decrypted message.

So now if their computer gets hacked and the permanent private key leaks, none of the old encrypted messages that the attacker captured over the wire can be decrypted, because the temporary key was used to encrypt them, and that has been long since deleted.

Future messages would be susceptible to MITM however if they don't notice and change their permanent key after the leak.

user_8952450
Related