# Why is key exchange necessary at all?

Let's say "Alice" and "Bob" want to communicate with each other over an insecure network.

Using Diffie–Hellman key exchange, they can get the same symmetric key at last. However, as I understand, they do not have to get the same symmetric key at all, because they can just use asymmetric key without key exchange.

With RSA algorithm, Alice and Bob can just share their public keys (public_a, public_b) and keep their private keys (private_a, private_b). Alice can just send Bob the messages which are encrypted by public_b, and Bob can decrypted it by private_b. They can still communicate over an insecure network, without Diffie–Hellman key exchange at all.

I know I might be wrong, but I'm not sure where I was wrong. Does anyone have ideas about why and when Diffie–Hellman key exchange (or any key exchange) is necessary? Is it suitable for the situation I mentioned above?

• The most basic reason is that RSA is limited to a message length of 254 bytes for common key lengths. Symmetric encryption is not limited in any way. Further, asymmetric encryption is slow. If you just use RSA to exchange a symmetric key, a la plain TLS, then you have no Perfect Forward Secrecy - anyone gaining access to either private key can decrypt the symmetric key and therefore all content. Nov 17, 2015 at 8:48
• I think this video might be of interest: khanacademy.org/computing/computer-science/cryptography/… Nov 17, 2015 at 10:15
• Also reduces exposure of private key - the less a key is used the less information about it is leaked via known or guessed plaintext.
– Ben
Nov 17, 2015 at 10:40
• If the data could be decrypted with the public key, wouldn't that mean that anyone can decrypt the data? Nov 17, 2015 at 15:29
• @Kevin, yes, the message must be encrypted with the destination public key, and decrypted with the corresponding private key. The inverse is used for signing, not encryption. Nov 17, 2015 at 16:55

If the attacker is able to passively capture data and later gets access to the private key of the certificates (i.e. stealing, heartbleed attack or law enforcement), then the attacker could decode all previously captured data if the encryption key is only derived from the certificate itself.

DH key exchange makes it possible to create a key independent from the certificate. This way knowledge of the certificate alone is not enough to decode previously captured data. This is called forward secrecy. See Wikipedia for more information.

Apart from getting forward secrecy with DH there are other reasons to use symmetric cryptography instead of simply using the RSA private keys. Thus even if you don't use DH for key exchange TLS will create a symmetric key, which is then derived from the certificate. For more details why using the private key directly to encrypt is not a good idea see Why does PGP use symmetric encryption and RSA?.

• It seems to me that when you captured the data (with the including initial key exchange) and have both private keys there is nothing to stop you from decoding it, or is there? Nov 17, 2015 at 12:19
• @PlasmaHH: yes, if the private keys are no longer private than the full communication can be decrypted (unless DH is used for key exchange). Nov 17, 2015 at 12:24
• My security teacher said symmetric keys are also faster. Is this true? If so, that would be another reason to use them. Nov 17, 2015 at 14:43
• @trysis: I think crypto.se: Why is public-key encryption so much less efficient than secret-key encryption? will answer this question better than I can. Nov 17, 2015 at 15:16
• @trysis: Just to cite: "There is no proof that asymmetric encryption must really be harder, computationally-wise, than symmetric encryption, but the contrary would still be mildly surprising.". Thus at least with the current algorithms this is a yes. Nov 17, 2015 at 15:33

There are many steps needed to understand the reasons and I will try to guide you through each.

1) Use encryption correctly...

With RSA algorithm, Alice and Bob can just share their public keys (public_a, public_b) and keep their private keys (private_a, private_b). Alice can just send Bob the messages which are encrypted by private_a, and Bob can decrypted it by public_a. They can still communicate over an insecure network, without Diffie–Hellman key exchange at all.

That part is plain wrong. What you are doing in this part is signing, not encryption. Since public_key_a is public, your messages would not be encrypted at all. Instead of doing that, A should be encrypting the messages with public_key_b and then B can decrypt them with private_key_b. Since private_key_b is only know to B, A knows that only B can decrypt it.

Digital signature proves that a message come from a particular person. Encryption proves that only you, the key holder, and the person that encrypted the message, message sender, know the message. You need to have both encryption and signature when using asymmetric encryption. Encryption to protect the confidentiality of the message and signature to prove that you are the one that sent this message.

But, there is still more to it... For example, you still need to protect against replay attacks.

2) Bob usually doesn't have a public key

Let's say that Alice (A) is the server and Bob (B) is the client. Usually the client doesn't have a public key. For example, do you know a public key? The answer is most likely NO. Hence, Bob can receive message from Alice and verify that they really come from Alice but Alice cannot be sure anything it receives from Bob really come from Bob.

That problem is one of the root cause why we added key exchange protocol like Diffie-Hellman.

3) RSA is limited to one block.

There is a technique used to encrypt long message that is called cipher block chaining. Sadly, this technique cannot be used with RSA. It's not that it's totally impossible but rather that no one knows if it's really secure if we do it. Hence, it limits RSA encryption to one block. On the other hand, symmetric encryption algorithms like AES works like a charm with block chaining and is the reason we use them.

4) Diffie-Hellman is a key exchange protocol

Diffie-Hellman is just a way to "create and share" a key which can then be used for symmetric encryption. The strength of Diffie-Hellman is that all the conversation to create this key can happen in plain text and the key would still be private.

Note : Diffie-Hellman doesn't solve the problem of MitM attacks because it cannot authenticate the parties communicating with each other. This problem is instead solved with digital signature.

5) Ephemeral Diffie-Hellman provide Perfect Forward Secrecy

Ephemeral Diffie-Hellman is just a fancy name to say that you are generating new Diffie-Hellman key-pair every session and you don't store them. Since you never store them, an attacker can never retrieve them.

See this very good answer for more details : https://security.stackexchange.com/a/38142/50051

6) Ephemeral Diffie-Hellman protects you against replay attack

A very good side effect of using Ephemeral Diffie-Hellman is that it also protects you against replay attack. Since the server and the client is choosing a new random private DH key every session, you cannot replay the message from another session to impersonate the server or the client.

Conclusion

This is a very brief overview of how TLS works and all those parts are required to provide a secure connection. Without symmetric encryption you cannot encrypt long message and without asymmetric encryption you cannot share encryption key and provide perfect forward secrecy.

You're assuming that Alice and Bob can reliably exchange public keys over an unsecure network.

Without a key exchange protocol, Alice and Bob think this is happening: (A = Alice's public key, B = Bob's public key)

``````Alice  ---------- A --------------> Bob

Alice  <----------- B ------------- Bob
``````

when this is what really happens (M = Mallory's public key)

``````Alice  ----- A ------> Mallory --------- M ------> Bob

Alice  <---- M ------- Mallory <-------- B ------- Bob
``````

Bob and Alice now think they are encrypting messages for each other; they are really just encrypting messages for Mallory, who decrypts, reads, and re-encrypts messages using the intended recipients real

• But as @Gudradain points out, RSA with certificates doesn't have this problem (as long as the CA is trustworthy), while MitM is trivial in pure DH does (you can solve that by using again certificates and digital signatures). So, on the MitM metric, DH key exchange requires additional complexity to achieve the same result; the advantages are elsewhere. Nov 18, 2015 at 2:06

Using RSA for all messages is undesirable because the algorithm is computationally expensive. Using RSA to negotiate a symmetric key lets you send further messages much more cheaply in terms if CPU usage.

• Note that RSA and Diffie-Hellman are very different.
– user
Nov 18, 2015 at 8:53