In TLS 1.2 when using ECDHE_RSA, the ServerKeyExchange message contains a signature over the server's ECDHE public parameters. My question is: Is the signature over a hash of the parameters or over a plain text of the parameters?

The specs does not clarify:

  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 server's key exchange parameters.

     For non-anonymous key exchanges, a signature over the server's
     key exchange parameters.

As you see, it says on the signed_params:

a signature over the server's key exchange parameters


Signature generation includes hashing. So there is no need to perform hashing separately. This is why the signature schemes that are used will always indicate the hash to be used - either directly or indirectly using parameters.

Without the hash the signature would be vulnerable to key-only existential forgery attacks. I don't see how that would influence the security of TLS, but TLS in general tries to use standardized primitives within the protocol

Note that TLS up to 1.2 contains rather a lot of legacy constructions that would be considered non-standard by now, TLS 1.3 tries to resolve this by using RSA-PSS and SHA-2 (in the 256, 384 and 512 bit versions) which is provably secure if RSA and SHA-2 are secure.

So yes, hashing is used, but only as part of signature generation.

  • $\begingroup$ First answer edited and posted using my Ultimate Hacking Keyboard :) I'm not sure if I will ever get used to it, but geeky it is... $\endgroup$ – Maarten Bodewes Oct 18 '18 at 20:55
  • $\begingroup$ Divide & Conquer it! $\endgroup$ – kelalaka Oct 18 '18 at 21:24

As to the specs, note that 4.7 says

In RSA signing, the opaque vector contains the signature generated
using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. ...

referencing (then-current) RFC3447 which unambiguously defines the whole signature process: hash, then encode, then pad, then the RSA modular exponentiation.

Note that TLS DSA and ECDSA signatures are just the standard notSchnorr(hash(M)) but TLS1.2 (protocol) RSA signatures are PKCS1v1_5 which is in brief

$$\operatorname{modexp}(n,d) (\operatorname{add01FF...00} (\operatorname{DERSEQ} (\operatorname{hash}(M)))))$$

while in TLS1.1 and earlier they were a variant of PKCS 'type 1' or even 'type 0' $$\operatorname{modexp}(n,d) (\operatorname{maybe\_add01FF...00} (\operatorname{SHA1concatMD5}(M)))$$ -- as noted in that same paragraph. And TLS1.3 changes to PSS instead.

Meta: Mathjax somewhat better, thanks SEJPM.

  • $\begingroup$ you may want to wrap your operators into \operatorname{operatorname here}(arguments here) $\endgroup$ – SEJPM Oct 19 '18 at 8:46
  • $\begingroup$ You can find a lot of formatting hints here. Just linking to PKCS#1 would do the trick as well though. $\endgroup$ – Maarten Bodewes Oct 19 '18 at 22:53
  • $\begingroup$ @MaartenBodewes: PKCS1 takes about a page in total to lay out each signature scheme in detail; I wanted to emphasize the differences by ignoring the parts not important here. $\endgroup$ – dave_thompson_085 Oct 22 '18 at 9:24

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.