In Finite Field DHE, the server sends the following parameters in the server key exchange message: $p$: prime $g$: group $g^b$: the server's public DH key

In DHE_RSA (non anonymous DHE), the server signs the parameters. The full parameters according to the specs are:

ServerKeyExchnage($p$, $g$, $g^b$, sign(hash($\mathit{server\_nonce}$, $\mathit{client\_nonce}$,$p$,$g$,$g^b$))

The client sends it ClientKeyExchange which contains the client's public DH key:


ECDHE uses Elliptic-Curve and this entails different methods in selecting the key parameters.

1) In terms of TLS message, if the key exchange is Elliptic-Curve not Finit-Field, precisely how this affects the parameters and messages above? What does it changes in terms of the exact parameters the client and server send?

2) In terms of key parameters, does Elliptic-Curve changes the method used by both parties to compute the pre-master-secret? In Finit-Field, the client's pre-master-secret is computed by:

$pms = g^{ab}$

The same for the server:

$pms = g^{ab}$

Since EC does not use $g$, is the pre-master-secret still computed by multiplying the other peer's public ECDHE parametrs in its private ECDHE parameter? I.e:

$pre\_master\_secret_{Server} = ECDHE\_pk _{Client} \times ECDHE\_sk _{Server}$


Generally a pre-selected set of parameters are used: a named curve such as brainpoolP256r1. Here the parameters have been pre-selected. It is computationally inefficient to choose the EC domain parameters on the fly, and preferably the other party should be able to make sure that the parameters are generated securely. So the $p$ and $g$ used for Finite Field DH are commonly replaced by a single identifier (e.g. in text or an OID, depending on the implementation) that represent the domain parameters.

The the curve parameters can also be communicated using the actual values. For a curve over a prime field the parameters are:

  • the prime field $p$;
  • the coefficients $A$ and $B$;
  • the base point $G$ consisting of coordinates $x$ and $y$;
  • the prime order $q$;
  • the cofactor $h$, commonly set to 1.

sometimes a seed - to generate the parameters - is communicated as well.

The base point G here takes the same role as the $g$ in Diffie-Hellman over a finite field. Instead of repeating the answer, you can find a complete description here.

In general ECDH is described using point multiplication instead of exponentiation.

Lets describe it using:

  • $P$ for the public key (so $P_A$ is the public key of $A$)
  • $S$ for the private key (so $S_A$ is the private key of $A$ called $a$ in the question)
  • $X$ is the shared secret as we're running out of variable names
  • ${}\times{}$ is point multiplication

Calculation of the public key:

  • FFDH: $P_A = g^{S_A}$
  • ECDH: $P_A = S_A \times G$

And the key agreement itself:

  • FFDH: $X_B = P_A^{S_B} \to X_B = (g^{S_A})^{S_B} \to X_B = g^{S_AS_B}$
  • ECDH: $X_B = S_B \times P_A \to X_B = S_B \times (S_A \times G) \to X_B = S_A \times S_B \times G$

and for both you can see that they rely on the commutative properties of modular exponentiation and point multiplication. It is easy to see that $X_A = X_B$ using both methods.

It is simply possible to write $g^a$ and say that the normal exponentiation function is representing multiplication in a cyclic group. So in that case $g^a$ would be seen as $g \times a$ for Elliptic curves. $g$ is however generally written in uppercase as $G$ (not to be confused with cyclic group $G$) because it is a point, not just a single number.

Although EC operations are often described using multiplication and (point) addition it is important to keep reminding yourself in which model you're operating. There are a lot of ways and a lot of ways to map variables in ECC, making a hard to understand field even more difficult to grasp.

In the end your CPU will still have to perform modular exponentiation to implement point multiplication. The modular exponentiation is however over smaller numbers, making it more efficient.

  • $\begingroup$ So if I want to abstract from how exactly the pre-master-key is computed by the following: pre_master_secret_server = KDF(ECDHE_pk_client, ECDHE_sk_server), is this right? the obscure point is: is the KDF in ECDHE still takes the same parameters as the FF DHE? i.e. does it still requires the private ECDHE key of the party that is computing the pre master secret in addition to the public part of the ECDHE key of its peer? $\endgroup$ – user9371654 Oct 16 '18 at 15:43
  • $\begingroup$ Plz ignore my edit request for your answer. I got it now. Just my question above still not answered. $\endgroup$ – user9371654 Oct 16 '18 at 16:19
  • $\begingroup$ @user9371654 I'm presuming you're talking about TLS now (this is not in the question!). In that case the pre master secret is $\text{DH}(Priv_{server}, Pub_{client})$. The KDF / PRF comes after the key agreement to create the pre-master secret. The DHE and ECDHE calculations are identical when it comes to handling the keys. As indicated in my answer, the establishment of domain parameters is slightly different due to the use of named curves. $\endgroup$ – Maarten Bodewes Oct 16 '18 at 21:16
  • $\begingroup$ in FF the client's pk is $g^a$, the server's pk is $g^b$, and the shared DH key is $g^{ab}$. Can you sumarize what is the equivalent of these variables in EC? And yes, I am talking about TLS. $\endgroup$ – user9371654 Oct 17 '18 at 4:27
  • $\begingroup$ OK, rewrote my answer, hopefully it is more clear now $\endgroup$ – Maarten Bodewes Oct 17 '18 at 12:56

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.