In TLS 1.2, section 7.4.3 in the standard documentation on Server Key Exchange Message, it says that the parameters covered by the digital signature are as follows:

dh_p The prime modulus used for the Diffie-Hellman operation.

dh_g The generator used for the Diffie-Hellman operation.

dh_Ys The server's Diffie-Hellman public value (g^X mod p).

These parameters are hashed first. My question is: when the hash of these parameters is computed, is it computed over a concatenation of these parameters? or are they combined in any other way?


Section 7.4.3 specifies this:

  struct {
      select (KeyExchangeAlgorithm) {
          case dh_anon:
              ServerDHParams params;
          case dhe_dss:
          case dhe_rsa:
              ServerDHParams params;
              digitally-signed struct {
                  opaque client_random[32];
                  opaque server_random[32];
                  ServerDHParams params;
              } signed_params;
          case rsa:
          case dh_dss:
          case dh_rsa:
              struct {} ;
             /* message is omitted for rsa, dh_dss, and dh_rsa */
          /* may be extended, e.g., for ECDH -- see [TLSECC] */
  } ServerKeyExchange;

The meaning of digitally-signed is explained in section 4.7. In this case, the above means that the input to the signature algorithm (i.e., that which is hashed) is the concatenation, in that order, of:

  • the client random (32 bytes), as sent by the client in the ClientHello;
  • the server random (32 bytes), as sent by the server in the ServerHello;
  • the encoding of the ServerDHParams structure. This is the complete encoding, including length bytes.

The ServerDHParams structure is itself defined as:

  struct {
      opaque dh_p<1..2^16-1>;
      opaque dh_g<1..2^16-1>;
      opaque dh_Ys<1..2^16-1>;
  } ServerDHParams;     /* Ephemeral DH parameters */

Thus, what goes in the hash function, immediately after the 64 bytes for the client and server randoms, are the two bytes that encode the length of dh_p, followed by dh_p; then the two bytes for the length of dh_g, then dh_g; finally, the two bytes for the length of dh_Ys, then dh_Ys.

Since the ServerDHParams structure is itself sent over the wire as part of the ServerKeyExchange, it is simpler to think of it as follows: what is signed is exactly the concatenation of the client random, server random, and the bytes encoding the ServerDHParams, as sent and received.


Your Answer

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

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