0
$\begingroup$

Is all random private key that generating a unique session key is both forward secrecy and key freshness?

$\endgroup$
  • 1
    $\begingroup$ I'm afraid that there is a bit of a language barrier that blocks you from asking the question in a way that everybody can understand. I've edited the title, but I'm unsure about the "random private key" part. Could you try and edit to explain? $\endgroup$ – Maarten Bodewes May 5 at 23:18
  • $\begingroup$ Forward secrecy involves random fresh keys every session AND that you delete those keys afterwards $\endgroup$ – Natanael May 5 at 23:19
2
$\begingroup$

The term ‘perfect forward secrecy’ is bad. Rather than talking about whether a protocol has perfect forward secrecy, you should talk about when in the protocol you erase keys. Then, although ‘key freshness’ isn't a common technical term in cryptography, this suggests a clear answer:

  1. Key freshness is presumably about when you generate new keys so that future interactions can't be broken even if the old keys are compromised.
  2. Key erasure is when you erase old keys so that past interactions can't be broken even if your current memory is compromised.
$\endgroup$
0
$\begingroup$

Forward secrecy is about protecting previous sessions if long-term secrets are later compromised.

A random session key does not necessarily provide forward secrecy. An example of this is the "traditional RSA" ciphersuites in SSL/TLS. The client generates a random shared secret for the session, encrypts it with the server's long-term RSA public key and sends it to the server which decrypts it with the corresponding private key. Someone in possession of a packet dump of the session and the server's long term private key can decrypt the session secret and hence decrypt the session.

On the other hand with the DHE and ECDHE ciphersuites the shared secret is agreed through ephemeral DH or ECDH. The server's long term RSA (or ECDSA) is only used to authenticate the exchange. So someone in possession of a packet dump of the session and the server's long term private key cannot decrypt the session without cracking the underlying crypto.

$\endgroup$
  • $\begingroup$ This view of things is a little unsatisfying: future compromise of the server's memory may enable decryption of past sessions even with the so-called (P)FS cipher suites, if the server is using the misbegotten session resumption protocol of TLS<1.3. This is why I recommend discarding the confusing term ‘forward secrecy’ (and its even worse value-loaded cousin ‘perfect forward secrecy’) in favor of specifying when keys are erased. $\endgroup$ – Squeamish Ossifrage May 9 at 18:32
  • $\begingroup$ But that also means defining "erased", it does you no good to erase your copy of a short-term key if the attacker has a copy of it encrypted with a long-term key that you did not erase. $\endgroup$ – Peter Green May 9 at 23:17
  • $\begingroup$ Sure, then you haven't erased the key. $\endgroup$ – Squeamish Ossifrage May 9 at 23:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.