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:
- It makes confidentiality compromise by passive eavesdropping impossible even for an adversary that knows the shared secret, including if that knowledge comes after interception.
- 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.
