# Why is DH key exchange still useful, if a public key certificate is used?

EDIT:

According to Gilles's comments and fgrieu's answer below, I would like to summarize what I have learned, and what's still needs explanation:

1. DHKE is necessary for forward secrecy even when PKI is in use.
2. Public key may not be used for encryption, which is only possible/guaranteed for RSA cipher. For other systems like elliptic curve, public key may be designed only for signature verification, in such case, DHKE is required to generate session key.
3. In the case of defending against MitM attack, the shared secret (or private key) must kept private.

This brings another question: What exactly is forward secrecy? It is easy to find out by simple google search. If I understand correctly, it means, if a key is compromised in the future, the confidentiality of past communication is not compromised.

If an adversary can record complete (encrypted) communication history, and later find out the shared secret, he can alwasy deduct the session key used at at time, can he?

In another word, what is the premise/assumption to say that a cipher scheme provide forward secrecy? Like I know that to judge the secruity of a cipher protocol, people must not rely on the algorithm to be kept secret, but only the key.

In my question: Method to mitigate MitM attack for DH key exchange, the accepted answer pointed out flaws in my proposed plan, but I still have a question that worth a new discussion. My new question is: with pre-shared knowledge DH key exchange seems not neccessary?

Here, the phrase pre-shared knowledge may refer to a shared password, or a publicly distributed certificate (public-key). Of course, public key has may benifits over shared password, and let's omit the possiblity of leaking secret key etc. But it is still "pre-shared" knowledge. With a public key/certificate, why do we still needs DHKE?

For example, client may encrypt a session key using server's public key, since only server can decode it, they can then use the session key only known to the server and this client to communicate. And of course, they can change session key for each message, or periodically.

If, without any pre-shared knowledge, how to mitigate MitM attack in DH scenario?

• Does this answer your question? Why is a Diffie-Hellman key exchange required when RSA is already being used for key exchange in TLS? Jun 4 at 8:58
• So, does that mean, forward secrecy is the only purpose of DHKE in case of TLS, or an public-key system is already in use? Jun 4 at 9:41
• @xrfang No, it's not the only purpose. How do you establish a session key if the pre-shared knowledge is a public key that can only be used for signature verification, not for encryption? Jun 4 at 11:00
• @Gilles: It is simple: since client has server's public key, it just generate a random string, encrypt using server's public key, then send it to server, only server can decrypt the message and get the session key. i.e. without the need for forward secrecy, just let the client generate session key... Jun 5 at 23:51
• @xrfang This property that it's possible to encrypt data directly is specific to RSA (and minor variants). Other public-key cryptosystems, in particular elliptic curve cryptography, don't work like this. Even with RSA, encryption is problematic because it's hard to decrypt without side channels, whereas signature is a lot easier to do right. Jun 7 at 7:54

with pre-shared knowledge DH key exchange seems not neccessary?
Here, the phrase pre-shared knowledge may refer to a shared password

I'll restrict to this and thus assume a pre-shared secret, rather than dive into the more complex question of pre-shared public keys.

The reasons to still use DHKE when there is a pre-shared secret are that, with proper symmetric cryptography:

1. It makes confidentiality compromise by passive eavesdropping impossible even for an adversary that knows the shared secret, including if that knowledge comes after interception.
2. It makes confidentiality compromise by more general (active) attacks impossible without knowledge of the shared secret at time of the attack.

Property 2 implies forward secrecy, even though the pre-shared secret does not change.

Symmetric crypto can't give property 1 or 2 (but it can give forward secrecy, by carefully making the pre-shared secret irreversibly evolve at each session).

Recall that in passive eavesdropping, the adversary intercepts ciphertext but does not modify it. These attacks are by far the easiest to mount.

Recall that forward secrecy is the desirable property that future compromise of a user's non-ephemeral secrets can't compromise confidentiality of past sessions.

As an example of protocol giving properties 1&2, two parties agree on a pre-shared secret $$S$$ (all the rest is public), a finite group (noted with law $$+$$ and corresponding scalar multiplication $$\times$$) of order $$q$$ and generator $$G$$ suitable for DHKE (e.g. Ed448-Goldilocks), a symmetric authenticated encryption mode (e.g. AES-256-GCM), a hash function $$H$$ much wider than the key of the authenticated encryption mode (e.g. SHA-512), which party will use even-numbered indexes, and the following protocol where each communication session goes:

• Each party generates random secret $$x\in[1,q]$$, computes $$X\gets x\times G$$, sends $$X$$, forgets $$X$$, then receives $$Y$$.
• Each party secretly compute $$Z\gets x\times Y$$, and forgets $$x$$. Notice that their respective $$Z$$ (the ephemeral shared secret) are equal and secret in the absence of active attack.
• Each party secretly computes $$H(Z\mathbin\|S\mathbin)$$, splits it into 3 cryptograms $$U$$, $$V_0$$, $$V_1$$ with $$U$$ of size suitable as key of the authenticated encryption and the rest evenly split into $$V_0$$ and $$V_1$$, forgets $$Z$$, sends $$V_0$$ or $$V_1$$ according to it's assigned role, then receives $$W$$ and compare it to the other $$V_i$$.
• Only in case of match for that comparison does communication proceed for this session, with $$U$$ used as key for the authenticated encryption, and numbered packets starting from $$0$$ (with that incremental number included in what the encryption authenticates, and it's parity matching the sending party per the established convention).
• Otherwise, as well as at the end of the session, $$U$$, $$V_0$$, $$V_1$$, $$W$$ are forgotten.

The first two bullets are DHKE. The rest is purely symmetric cryptography.

in case the shared secret is compromised, how can confidentiality still (be) possible?

With respect to passive eavesdropping (point 1 in the first part), the protocol gives confidentiality and integrity without needing the confidentiality of the pre-shared secret $$S$$ (it can be public, e.g. empty). The protocol still gives confidentiality and integrity, because the passive eavesdropper can't find the ephemeral secret $$Z$$ or the $$V_i$$ from what can be passively observed.

With respect to active attacks (point 2 in the first part), if the confidentiality of the pre-shared secret $$S$$ in the above protocol gets compromised, the confidentiality and integrity of communications in later uses of the protocol is compromised, because now an active eavesdropper can make a Man in the Middle attack, and pass the test of $$W$$ in the protocol.

But communications made in earlier uses of the protocol are not compromised, because they remain protected by the confidentiality of the $$U$$ then generated, used as key for the symmetric authenticated encryption, and forgotten. It's not possible to reconstruct $$U$$ retrospectively by computing $$H(Z\mathbin\|S\mathbin)$$, because the ephemeral shared secret $$Z$$ then used was forgotten, and can't be reconstructed retrospectively by computing $$x\times Y$$, because the $$x$$ then used was forgotten.

If an adversary can record complete (encrypted) communication history, and later find out the shared secret, he can always deduct the session key used at thattime, can he?

To answer this, we must distinguish between two kinds of secret, independently of if they are shared or not:

• Those secrets that can and should be forgotten at end of session, and thus are qualified ephemeral. In the above above example $$Z$$ and $$U$$ are ephemeral shared secrets, $$x$$ is an ephemeral non-shared secret.
• Those secrets that must be retained from session to session, thus are non-ephemeral. They can further subdivide into static secrets, that remains identical over time, and non-static secrets (that evolve over time). In the above protocol $$S$$ is a non-ephemeral static shared secret. In authenticated Diffie-Hellman, a users' private key is a non-ephemeral static non-shared secret.

An adversary that can record complete (encrypted) communication history, and could later find out the appropriate ephemeral shared secret(s), can always deduct the session key used (itself an ephemeral shared secret) and decipher.

However, using DHKE, things can be organized so that the session key (and the plaintext) can't be found if the adversary gets hold of all non-ephemeral secrets after the session is complete, and the session's ephemeral secrets are forgotten. This gives forward secrecy as defined in the (updated) definition at the end of the first section of this answer.

Note: the statement "DHKE is necessary for forward secrecy even when PKI is in use" is incorrect. It's true that PKI is not sufficient for forward secrecy. But there are other ways than DHKE to get forward secrecy, with other asymmetric crypto, or even with symmetric crypto. In that later case, it's used non-ephemeral non-static shared secret. Non-static secrets must evolve, and non-static shared secrets must evolve in a way that keeps them synchronized between parties, which is a pain to organize, and one reason symmetric crypto is seldom used for forward secrecy.

• could you please give me an example of how passive eavesdropping is not possible, given the adversary already knows the shared secret? -- what is the difference between "the secret is known to the adversary", and "there is no shared secret at all"? [refers to answer v5]. Jun 4 at 9:47
• your example just added more technical detail about the process, but didn't explain my comments above: in case the shared secret is compromised, how can confidentiality still possible? (which is your first point in the original answer) [refers to answer v10]. Jun 6 at 0:37
• as in part 3, you said the shared secret could be empty, or just compromized, then how do you prevent MitM attack? Both Alice and Eve, Eve and Bob and use the procedure you describe to comunicate, without Alice or Bob knowing that Eve is eavesdropping? Jun 7 at 0:20
• I now understand what you mean. Please refer to the comments by Gilles 'SO- stop being evil' above, to see what's my concern: I don't know what is the purpose of DH in case public key encryption is already in use. As for forward secrecy, I think I'd better ask in another question. Jun 7 at 7:01
• @xrfang: I see. I jumped on your "pre-shared knowledge may refer to a shared password" because it simplifies the explanation, and is pedagogical. If hope you now understand the dual interest of DH even when there is a pre-shared secret (1) against passive eavesdropper and (2) in case the pre-shared secret leaks. If so, but something remains unclear, then you can modify the question accordingly. I'll then try to further extend the answer to make pre-shared secret a first step towards pre-shared public key, explain how that can be safe, and why DHKE is still useful for forward secrecy.
– fgrieu
Jun 7 at 8:21