1

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:

ClientKeyExchange($g^a$)

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}$

user9371654
  • 457
  • 1
  • 6
  • 12

1 Answers1

2

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.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323