What's the purpose of ServerKeyExchange when using ephemeral Diffie-Hellman? In this case, the ClientHello advertised EDH and EECDH (and not anonymous protocols), and the server selected TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA in its ServerHello.

According to RFC 5246, Section 7.4.3:

  This message will be sent immediately after the server Certificate
  message (or the ServerHello message, if this is an anonymous

  The ServerKeyExchange message is sent by the server only when the
  server Certificate message (if sent) does not contain enough data
  to allow the client to exchange a premaster secret. This is true
  for the following key exchange methods:


I understand RSA is being used for authentication (and not key transport). But since Diffie-Hellman is being used, both sides contribute material to the final master_secret. So there's no need for a message that allows the client to contribute more material earlier for the premaster_secret.

What's the purpose of ServerKeyExchange when using ephemeral Diffie-Hellman?


In Diffie-Hellman, the client can't compute a premaster secret on its own; both sides contribute to computing it, so the client needs to get a Diffie-Hellman public key from the server. In ephemeral Diffie-Hellman, that public key isn't in the certificate (that's what ephemeral Diffie-Hellman means). So the server has to send the client its ephemeral DH public key in a separate message so that the client can compute the premaster secret (remember, both parties need to know the premaster secret, because that's how they derive the master secret). That message is the ServerKeyExchange.

I'm not sure what you mean by "a message that allows the client to contribute more material earlier" in regards to the ServerKeyExchange. The ServerKeyExchange doesn't let the client contribute more material; the client sends a ClientKeyExchange in all TLS suites. The point of the ServerKeyExchange is to let the server contribute more material to the key exchange, by letting it send additional information not in the certificate.

About "backtracking to premaster secret:" The premaster_secret is the immediate outcome of key exchange. Key exchange in TLS never produces a master_secret directly; this is because the TLS designers wanted the master secret to have a consistent length with entropy spread throughout, so that your key derivation code doesn't have to worry about how key exchange happened. Different key exchange methods produce differently formatted shared secrets, so you always have to convert the premaster secret to a master secret of 48 bytes. There's no real concept of "backtracking," as the master secret isn't derived until key exchange is finished.

|improve this answer|||||
  • "I'm not sure what you mean by "a message that allows the client to contribute more material earlier."" - More material refers to the client sending more random information (like a nonce) beyond its temporary public key. Earlier refers to the progression of premaster_secret to master_secret. RSA key transport allows only the client to contribute material to the premaster_secret. In the case of EDH, there's no need to backtrack to the premaster_secret since both sides will be contributing with their public keys. – user29925 Jan 19 '15 at 2:57
  • But the ServerKeyExchange doesn't have the client contribute more material. It has the server contribute more material. – cpast Jan 19 '15 at 3:04
  • Also, you don't seem to have the right relationship between premaster and master secret. The premaster secret is whatever the immediate outcome of key exchange is. The format depends on key exchange method; to make things more consistent, you then convert the premaster secret into a 48-byte master secret. There's no "backtracking;" conversion into a master secret happens after key exchange for all algorithms. You can't directly negotiate the master secret. – cpast Jan 19 '15 at 3:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy