1

Context

We need to generate a key pair in order to perform DH key exchange with the other party. Some suggest to use a KMI solution (think: AWS KMS or like) in order to generate the key pair.

Questions

  1. What would be the benefits of using a separate KMI solution to generate key pair for DH key exchange?
  2. Are there any benefits over on-the-fly generation using a proper library (in this context)?
  3. Would there be any generic reason to keep key pair used solely for key exchange, after the key exchange has been completed?

1 Answers1

1

Using a Diffie-Hellman key exchange is best using keys generated on-the-fly. The reason comes down to a historical issue...

Let's say we contact a web server. The server uses the key pair $S_{pub},S_{pri}$, and out client uses key pair $C_{pub},C_{pri}$. If the web server never changes its key pair, and we don't either, the handshake will always yield the same result. Let's hypothesize, the server could possibly have a hard-coded key pair (web servers and browsers used to have a vulnerability where the DH key pair was literally hard-coded. This has since changed but we don't wanna revert to old mistakes). Now, if I contact 2 web servers with the same keys I will always get the same private key. Thus, now each server can read my communications with the other, assuming they get the ciphertext.

Even if only one side has an unchanging DH key, a compromise of that key would result in the compromise of every message between the parties. However, if the key is generated randomly each time, by both sides, you get a system with perfect forward-secrecy.

However if we want to use an IPS with DPI on our communication, it would allow the IPS to make sure the data isn't loaded with exploits and malware and all sorts of nasties. That's the only reason I can think of to use an unchanging key pair.

Serpent27
  • 1,461
  • 5
  • 11
  • I wouldn't go that far. After DH both parties do key derivation using shared secret as IKM because this is what you should do, as long as both parties do that with different nonce/salt they exchanged every time they did key exchange, even if the key pair was the same, in result they get different derived symmetric keys. But still, I can't really see a good reason to use KMI and not generate key pair on-the-fly. –  Sep 08 '20 at 18:37
  • True, but a salt won't fix the issue of forward secrecy; and if the nonce is public (an nonce is literally defined to be non-secret) an attacker can just use the old key with the new nonce; making the distinction purely superficial. – Serpent27 Sep 08 '20 at 18:40