0

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?

dbush
  • 205,898
  • 23
  • 218
  • 273
Lolita Gherp
  • 49
  • 4
  • 2
    The public key is *generated* from the private key, but getting the private key from the public key is the hard problem that makes the scheme a useful cryptographic primitive. You are confusing terms here. The private key(s) is unique to a side and known only to them. They exchange public keys and arrive at a common *shared secret key*, not a private key. – President James K. Polk Oct 04 '18 at 15:15

3 Answers3

5

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.

dbush
  • 205,898
  • 23
  • 218
  • 273
  • The only key exchange for ECDH is exchange of public keys. Once each side computes the same private key it is used as key to a totally different algorithm. The private ECDH key is never exchanged because there is no need to exchange it - after all both sides already have it – Lolita Gherp Oct 04 '18 at 13:49
  • @LolitaGherp Exactly. Each side obtains the other's public key and uses it together with their own private key to calculate the shared secret. – dbush Oct 04 '18 at 13:52
  • So the question remains. Where is the security when a third party can intercept both public keys? – Lolita Gherp Oct 04 '18 at 13:54
  • 1
    @LolitaGherp See my edit. It seems you're confused about what ECDH actually does. – dbush Oct 04 '18 at 13:55
  • I am missing your explanation, e.g. "Alice uses her private key and Bob's public key to compute ...." is incorrect, It should be "Alice uses her public key and Bob's public key to compute private key". – Lolita Gherp Oct 04 '18 at 14:07
  • @LolitaGherp No, that is **not** correct. Each user's uses their own private key and the other's public key to compute the shared secret. The second paragraph in the answer explains in more detail. – dbush Oct 04 '18 at 14:09
  • I use the code at https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.ecdiffiehellmancng?redirectedfrom=MSDN&view=netframework-4.7.2 it shows clearly that each side generates its own public key, here I mean private key is the same as shared secret key, private key is not used to generate secret key because both are the same thing, only two public keys are used as input – Lolita Gherp Oct 04 '18 at 14:19
  • @LolitaGherp That API is glossing over details of ECDH. See [this](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman) for more details. – dbush Oct 04 '18 at 14:22
  • I do not have luxury of analyzing dry math because of lack of time I need actual code samples to get me through very quickly. – Lolita Gherp Oct 04 '18 at 15:08
  • @LolitaGherp The point is that both sides generate an EC public/private key pair, and each uses their private EC key and the other's EC public key to perform an ECDH key exchange. The code you linked does that, even though it doesn't explicitly state it. – dbush Oct 04 '18 at 15:11
  • The code does not do any such thing! Each side allocates its own algm of type ECDiffieHellmanKeyDerivationFunction which automatically provides public key. Then they send the public key to each other. Once each side receives other_public_key it calls CngKey.Import(other_public_key) which returns CngKey_object used as input to algm.DeriveKeyMaterial(CngKey_object) which returns private key, a.k.a. shared secret. There is no key exchange except for exchange of public keys. Private key is not used to compute anything. Private key is the final result used as input to a different algm – Lolita Gherp Oct 04 '18 at 15:21
  • 1
    @LolitaGherp The first thing the code does is `ECDiffieHellmanCng alice = new ECDiffieHellmanCng())`. If you click the link for this constructor, it states "Initializes a new instance of the ECDiffieHellmanCng class **with a random key pair**." So it **is** in fact creating an EC public/private key pair. It's just not obvious that is what is happening. Don't confuse the EC private key with the ECDH shared secret. – dbush Oct 04 '18 at 15:28
  • 1
    As for `ECDiffieHellmanKeyDerivationFunction`, what it does is take raw shared secret from ECDH and performs a hash on it to generate the actual shared secret that is used. This is done because the raw shared secret doesn't have sufficient entropy in all of its bits, and applying a hash generates that entropy. – dbush Oct 04 '18 at 15:29
  • The main issue here is that ECDiffieHellmanCng does not provide the parms to re-generate PublicKey - apparently this is the crucial point, meaning it is not possible to get another object of ECDiffieHellmanCng and get the same PublicKey. That is why a third party can intercept two public keys exchanged by two sides and still be unable to emulate either side to compute private/secret key. Whatever random key pair is generated internally, the important thing is what's available externally, i.e. single public key and single private/secret key generated from both public keys – Lolita Gherp Oct 04 '18 at 16:08
  • @LolitaGherp `ECDiffieHellmanCng` does allow you to extract the key as a `CngKey` object via the `Key` property and to set the key for a new object via a different constructor call. What makes the algorithm secure is that, given the proper curve, it's computationally infeasible to calculate the private EC key from the public EC key. – dbush Oct 04 '18 at 16:32
4

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.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • My main question here is how is it possible for side S1 with its own public key PK1 to receive a public key PK2 from side S2 and use both keys to arrive at secret key that no other side S3 can generate by having the same keys PK1 and PK2. Let's assume, side S3 acts as side S1. The only problem is to generate PK1 so that it can input PK2. The question is what's so secure about ECDH that side S3 cannot come up with parameters to generate PK1 and trivially input PK2. PK1 is only 140 bytes, ECDH algorithm is public, all input parameters are defined publicly even the actual values are not known. – Lolita Gherp Oct 05 '18 at 13:50
  • 1
    You don't use both public keys to arrive at the secret key. You use your DH private key and the DH public key of the other party. The private key is unknown to the third party (S3). Only the DH parameters (the curve) must be identical on both sides. And the shared secret, of course. – Maarten Bodewes Oct 05 '18 at 13:53
0

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.

GraphicalDot
  • 2,644
  • 2
  • 28
  • 43
  • ECDH private key can be generated only from two ECDH public keys, not the other way around. Once you have ECDH private key you can use it as input to a totally different algm like a symmetric algm – Lolita Gherp Oct 04 '18 at 13:46
  • No idea what you are explaining here, I never have said anything about generation of EC public/private key pairs. – GraphicalDot Oct 04 '18 at 13:48