# Man-in-the-middle attack on Diffie-Hellman with shared public keys?

Is it correct to say if the public key is known to all users beforehand, Diffie-Hellman key exchange is not vulnerable to man in the middle attack?

Sample key exchange ( assuming all users public key is known ) :

\begin{align} A \rightarrow B &: Y_b^{N_a} \\ B \rightarrow A &: Y_a^{N_b} \\ Shared Key &= g^{N_a+N_b} \end{align}

Where $N_a$ is random int generated by $A$ and $Y_a$ = $g^{S_a}$ where $S$ is the secret key generated by $A$.

• When does the 'generat[ion]' occur? If it is ((well) in advance you don't need to send it; if it is during each exchange, it can't be 'known ... beforehand'. – dave_thompson_085 Nov 20 '17 at 4:32
• Do you really mean $SharedKey = g^{N_a + N_b}$, or do you actually mean $SharedKey = g^{N_a \times N_b}$? The former is actually easily computed from the public values. – poncho Jan 21 '18 at 14:50
• @poncho I think you misread all three presented value for using the same generator. The public values are g^(s_i N_i) and g^(s_i) for i=a/b – Florian Bourse Jan 22 '18 at 9:01
• – SEJPM Jan 22 '18 at 17:25

Yes, for sure, you can perform what is called ephemeral-static Diffie-Hellman or static-static Diffie-Hellman where one or two parties are authenticated respectively.

Multiple schemes have been described in NIST SP 56A: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, sections 6.2 and 6.3.

You would of course need an additional (random) nonce if you use two static public/private key pairs. Otherwise there are no variable values in the equation and you would always generate the same session keys.

If you want to have a view of ephemeral-static Diffie Hellman then you don't have to look further than TLS 1.2, any ciphersuite that starts with DH or ECDH (without the E after it). They are not used much, generally ephemeral-ephemeral Diffie-Hellman is used with a separate authentication using RSA or ECDSA signatures. Certificates with a DH or ECDH public key are very rare indeed.

Key pair generation creates both the public and private keys and takes place on the machine of the owner of the key pair. Generally the private key should not leave this machine, except for backup purposes.

I'm not sure your sample algorithm complies with DH as specified in this standard document.

• In TLS, ephemeral integer DH can be authenticated by RSA or integer DSA only, and ephemeral ECDH by RSA or ECDSA only. There's no technical reason it couldn't be defined for DHE+ECDSA or ECHDE+DSA, but it isn't. There's no difference in the key for ECDH or ECDSA (or ECIES etc), only the KeyUsage bits in the certificate; e.g. en.wikipedia.org uses an EC P-256 cert from GlobalSign that has both DS and KA -- although according to SSLLabs the server won't negotiate any ECDH(static) suites. – dave_thompson_085 Jan 22 '18 at 3:13