# Key exchange if forward secrecy is not an issue

Let's say that we have a cryptosystem where Forward Secrecy and Man-In-The-Middle attacks are not an issue, purely hypothetically.

Would it be correct for a key exchange with any given public-key algorithm to simply work as follows?

1. Alice calculates public & private key
2. Alice sends the public key to Bob (and Eve intercepts it)
3. Bob encrypts a random session key with the public key
4. Bob sends the encrypted session key back to Alice (and Eve intercepts it)
5. Alice decrypts the session key using the private key, Eve cannot decrypt in any reasonable amount of time

And all future communications would be encrypted with the session key. Are there any glaring vulnerabilities in this, besides forward secrecy and man in the middle attacks?

• – Maarten Bodewes May 11 '14 at 0:25
• Even if "Man-In-The-Middle attacks are not an issue," impersonation might still be an issue. $\hspace{.88 in}$ – user991 May 11 '14 at 0:28

No, because Bob cannot know for sure who send the public key in the first place. So impersonation may still be an issue, even if man-in-the-middle attacks are not possible.

If the communication is over a channel that can only be eavesdropped by Eve (i.e. Even cannot send anything to Bob within Bob knowing it is not from Alice), then this is secure. But that's a rather strong requirement.

In general, this is solved by a Public Key Infrastructure (PKI). The most well known one is the PKI based on X509 certificates used by internet browsers, which uses certificate authorities and browser organizations as trusted third parties as well as DNS to establish trust.