What makes ECDH rely on two public keys alone?

Question

I have a basic question about ECDH (Elliptic Curve Diffie-Hellman).

The whole idea is that both sides exchange their own public keys and arrive at the same private key. However, you can trivially intercept both keys. Inputting the other public key is trivial.

So the main issue is generating your own public key. Does it mean that it is not trivial to re-generate a given public key, i.e. it is not possible to recover the original parameters used to generate a given public key before you can input another public key and arrive at the same private key?

Answer 1

I am pretty sure, that ECDH keys are generated between private key of one party and public key of other party.

lets say two parties are bob and alice, then according to ECDH scheme this holds True.

ECDH(bob_private_key, alice_public_key) == ECDH(bob_public_key, alice_private_key)

because of which nobody other then alice and bob can generate the same key.

check here for the implementation in python, https://stackoverflow.com/a/52506717/1619003

@Maarten has explained what might have confused you, difference between secret key and private key.

Answer 2

An ECDH key exchange is not used to create a private key but to calculate a shared secret. This is performed by each party first creating their own EC public/private key pair, then using their own EC private key and the other's EC public key to perform the ECDH computation, which results in both sides calculating the same value.

The first step is for each user to generate an EC public/private key pair. Supose Alice and Bob each generate a key pair. In this example, Alice's EC private key is x and her EC public key is xC, and Bob's EC private key is y and his EC public key is yC. These are then used to perform ECDH key derivation.

Next, Alice uses her EC private key and Bob's EC public key to compute x * yC == xyC. Similarly, Bob uses his EC private key and Alice's EC public key to compute y * xC == xyC. Then xyC is the shared secret created by the ECDH algorithm.

Answer 3

ECDH doesn't rely on the public keys alone; those are just the only components that are required to be send. Instead, it depends on two public / private key pairs, generated by both parties. The trick in Diffie-Hellman key agreement (DH) is that a calculates the shared-secret given the private key and the public key of the other party. This shared secret is identical on both sides if and only if the correct private and public keys are used.

The public and private keys of a pair are linked during key pair generation; the DH public key is calculated from the base point of the curve and the private key. This specific bond between the keys is required to calculate the same shared secret. For this calculation to succeed it is also required that both keys use the same domain parameters; in other words, the public keys need to be on the same curve.

A third party / adversary can of course copy the public key of either party. That will however not help the adversary as it doesn't have access to either of the accompanying private keys. So no other party than the ones involved in the key agreement will be able to calculate the same shared secret; you need one of the private keys to do that.

---

Taking it further, it is possible for an adversary to create a different key pair. If the public key of that key pair is accepted by the other parties then it is possible to create one or two different shared secrets.

SSL / TLS for instance mainly uses ephemeral (temporary) keys; any public ECDH key is accepted. That means that such a form of DH does not offer authentication of the parties involved. So a man-in-the-middle (MitM) attack is possible unless other authentication measures are used. The TLS for used in browsers uses server certificates / server signing for that.

But this part is giving an answer to a question that you didn't ask (yet).

---

Sometimes the word "secret key" is incorrectly replaced with "private key", even in books on crypto. This is very confusing, as it is obviously impossible to have a shared private key: "shared" and "private" are two opposites. Diffie-Hellman doesn't calculate a shared private key, it produces a shared secret, which is then used to calculate one or more session keys.