Talk:Forward secrecy

Inherently client/server?

Why does the first sentence mention a server? Especially given the Alice/Bob example later, there doesn't seem to be anything inherently client/server-related about the concept, at least nothing that deserves mention in the opening sentence.

I'm hesitant to reword it myself as I'm not an expert, so don't have a confident suggestion of what to reword to.

Gfredericks756 (talk) 12:03, 13 August 2018 (UTC)

I agree with that sentiment, forward secrecy is not inherently client/server. Markulf (talk) 10:49, 23 July 2020 (UTC)

Inaccuracies in definition of forward secrecy, long-term vs session key compromise

As pointed out earlier, the requirement for independent session keys is important, but is different from the requirement for forward secrecy.

"By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key."

This property can also be achieved by RSA key transfer, which encrypts a unique session key with a long-term RSA public key. Compromise of the session key only affects the specific session, but compromise of the RSA secret key affects past sessions and thus compromises forward secrecy.

See also point 4 of Ross Fraser above:

'4) the sentence "In this way, compromise of a single key permits access only to data protected by that single key" applies even to plain (non-FS) RSA: compromise of my private RSA key permits access only to data protected by that single key". This text may confuse readers who will miss the subtleties of symmetric session keys and their use with long-term public/private keys.'

I suggest a rewrite that distinguishes forward secrecy from session key compromise. Forward secrecy is about long-term key compromise. Markulf (talk) 10:49, 23 July 2020 (UTC)

Value of forward secrecy

'The value of forward secrecy depends on the assumed capabilities of an adversary. Forward secrecy has value if an adversary is assumed to be able to obtain secret keys from a device (READ access) but not modify the way keys are generated in a device (WRITE access). In some cases an adversary who can read keys from a device may also be able to modify the functioning of the session key generator. In these cases forward secrecy has no value.'

There is a connection between the discussion above and forward secrecy, but this feature might be better captured by the notion of post-compromise security. https://eprint.iacr.org/2016/221.pdf. I suggest a reference to this related concept once a page is created.

Even if an attacker gains WRITE access to a device, there is still value in forward secrecy, as past sessions are still protected.

Markulf (talk) 11:36, 23 July 2020 (UTC)

I believe example provided and definition are conflicting each other

I might be misunderstanding something, but to me it sounds like the definition of forward secrecy and provided example are contradicting each other.

In the definition it is stated:

> perfect forward secrecy (PFS), is a feature of specific key-agreement protocols that gives assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised.

But in the example:

> Forward secrecy (achieved by generating new session keys for each message) ensures that past communications cannot be decrypted if one of the keys generated in an iteration of step 2 is compromised

To my understanding, keys generated in step 2 are short-lived session keys, and the long term keys are the ones verified during step 1. So according to the definition the scenario should consider the leakage of private key of the recipient verified in step 1. Instead of ephemeral keys derived in step 2.

What is more, to the best of my understanding - Forward Secrecy is not protecting against session/short-term key compromise, it attempts to prevent attackers, who have recorded some messages in an encrypted form in the past from decrypting them in the event of long-term key leakage, which in the example case would be recipients private key verified at step 1. Jauler (talk) 15:22, 24 February 2026 (UTC)