I have heard that with forward secrecy that the ECDSA ciphers generate different keys for "each session" because they are not dependent on the private key of the server. My question is how is "each session" defined? Does this different key approach mean it happens with each consecutive/different SSL connection to say the same server or does it happen within the existing SSL connection as server side SSL re-negotiation request happen?

  • did you mean ECDHE? Aug 20, 2014 at 12:52
  • Forward Secrecy or Perfect Forwards Secrecy, there's a subtle difference.
    – RoraΖ
    Aug 20, 2014 at 12:59
  • Yes ECDHE-ECDSA* or ECDHE-RSA*..sorry
    – user53029
    Aug 20, 2014 at 13:00
  • Forward Secrecy
    – user53029
    Aug 20, 2014 at 13:01

2 Answers 2


Forward Secrecy

The key used to protect transmission of data must not be used to derive any additional keys, and if the key used to protect transmission of data is derived from some other keying material, then that material must not be used to derive any more keys. In this way, compromise of a single key permits access only to data protected by that single key.

Perfect Forward Secrecy (PFS)

PFS holds true above, but satisfies the two properties below:

  • Generates random public keys per session for the purposes of key agreement
  • Does not use any sort of deterministic algorithm in doing so

Addressing your questions in SSL/TLS

How is "each session" defined?

Ephemeral Diffie Hellman is used for PFS. Using Ephemeral Diffie Hellman (DHE/ECDHE) forces each session to renegotiate its DH parameter every time a single SSL session closes. So "each session" quite literally means as soon as the session ends the keys are destroyed. No session IDs are stored by the server, so new keys are forced each time.

Does this different key approach mean it happens with each consecutive/different SSL connection to say the same server or does it happen within the existing SSL connection as server side SSL re-negotiation request happen?

Doesn't matter if its the same server, or a server side re-negotiation the server shouldn't have cached session keys. So new DH parameters are needed with *DHE cipher suites. Now this is how the theory works. Configuration is kind of a different story. Some servers might have to disable session resumption to ensure this occurs.

RFC5246: TLS 1.2 Standard

Implementations SHOULD generate a new X for each handshake when using DHE cipher suites.

A related question and answer.

  • Am I correct that RSA can create only the same symmetrical key each session because of the static public and private keys?
    – ipeacocks
    Feb 20, 2017 at 23:07
  • @ipeacocks RSA doesn't generate symmetric keys. Symmetric keys are generated separately and then encrypted with RSA. Since the keys are unique the RSA encryptions are as well.
    – RoraΖ
    Feb 21, 2017 at 0:48
  • @RoraZ but technically (by design) RSA can generate symmetric keys and sign them? Thanks to Diffie-Hellman exchange keys are counted on hosts. Per my understanding DH process is enough for symmetric key generation and RSA only signs each stage (for understanding who is who) of its generation. Am I correct?
    – ipeacocks
    Feb 21, 2017 at 6:45
  • 1
    @ipeacocks RSA does not generate symmetric keys. It generates asymmetric keys where the encryption key is public and the decryption key is private. It is not symmetric encryption/decryption. DH negotiates asymmetric keys that are unique to each session, and is used as the pre-master secret in TLS. This along with several other pieces of information is used to generate the master secret which then produces symmetric keys. All of this is authenticated with RSA. This answer might help clarify things.
    – RoraΖ
    Feb 21, 2017 at 13:21

Each session means each SSL session. An SSL session can be reused over multiple TCP connections (that is SSL connections) if both client and server implement session reuse and each of the SSL connections gets closed in a clean way.

A SSL connection might also consist of multiple SSL sessions if you do multiple full SSL handshakes within the same connection.

  • What about an existing SSL connection where the server request renegotiation where each party stops exchanging data in order to renegotiate how the communication is secured?
    – user53029
    Aug 20, 2014 at 13:08
  • Renegotiations are secured by the already established session. Aug 20, 2014 at 13:41
  • @SteffenUllrich For PFS new DH parameters should be generated for each handshake using DHE cipher suites. Unless I'm missing understanding how PFS is supposed to work.
    – RoraΖ
    Aug 20, 2014 at 14:34
  • Yes, with each full handshake a new session with a new session key is created. But a full handshake is not done when you resume a session. Aug 20, 2014 at 16:51
  • @SteffenUllrich true, but if the server is not keeping session IDs (as should be done with PFS) then it will force a full handshake.
    – RoraΖ
    Aug 25, 2014 at 12:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .