# Where are the seeds for the initial key exchange phase taken from?

I know that the standard DH and ECDH key exchange algorithms require the client and server to agree on a large prime number and a generator (in the DH algorithm) or a curve and a point (in the ECDH algorithm), but if I inspect the SSH packets there is no sign of these shared seeds. How do they get them then?

I checked the packets and the only messages, after the "Key Exchange Init" and before the "New Keys" messages, are:

• "Client: Elliptic Curve Diffie-Hellman Key Exchange Init"

In which there is only the ephemeral public key of the client (i.e. the one generated thanks to the chosen curve)

• "Server: Elliptic Curve Diffie-Hellman Key Exchange Replay"

In which there is the public host key of the server, the ephemeral public key of the server (always the one generated with the curve) and the exchange hash (as it is called in rfc4253).

I think that which curve to use is explicit in the name of the algorithm (e.g. nistp256). But how do they agree on the point of order n?

And if I force the use of the DH algorithm (by typing ssh -oKexAlgorithms=diffie-hellman-group14-sha256) there is no trace of the module and generator exchange.

Thank you

• Reply not Replay. In a cryptographic or security protocol context, replay is usually hostile and bad. Jun 25, 2021 at 23:29

The order for ECDH and the modulus and generator for DH are all part of the domain parameters used for (EC)DH, so they are indicated by the group that is agreed on.

For instance, for P-256 you will find the specification in D.1.2.3 of FIPS 186-4 (or Sec v2 which specifies the same parameters but with the name secp256r1) and in the future in NIST SP 800-186-5. Group 14 for 2048 bit DH is defined in RFC 3526.

To perform ephemeral-static or ephemeral-ephemeral ECDH you only need to agree on the group (i.e. the domain parameters) and exchange the public keys of both parties. The public keys are already generated from the ephemeral private key, which provides the randomness.

Only if you perform static-static DH (i.e. you use to authenticate both sides using trusted DH public keys and use the static private keys) then you will need an additional random value, otherwise each session will use the same derived master / session keys.

• And rfc5656 and rfc4253 (updated by rfc8268) respectively point to those group+point definitions. Jun 25, 2021 at 23:29