I am dealing with a situation where a cipher option, such as ECDHE-ECDSA-AES128-SHA, is chosen for establishing a TLS connection. In this case, a server, when sending the ServerKeyExchange message to the client, is required to sign the ephemeral (EC) diffie hellman key using its ECDSA private key (associated with the public key certificate). The public key is first hashed before an ECDSA sign operation can be performance.

My question: how is the hashing algorithm determined during the handshake?

RFC 4492 which describes the application of ECC to TLS 1.2 has the following text to indicate how this algorithm is determined:

"“All ECDSA computations MUST be performed according to ANSI X9.62 [7] or its successors. Data to be signed/verified is hashed, and the
result run directly through the ECDSA algorithm with no additional
hashing. The default hash function is SHA-1 [10], and sha_size (see Sections 5.4 and 5.8) is 20. However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-2 [10], may be used instead if the certificate containing the EC public key explicitly requires use of another hash function. (The mechanism for specifying the required hash function has not been standardized, but this provision anticipates such standardization and obviates the need to update this document in response. Future PKIX RFCs may choose, for example, to specify the hash function to be used with a public key in the parameters field of subjectPublicKeyInfo.)”

However, if one refers to NIST Suite-B requirements for TLS 1.2 (RFC 5430), it is clear on the use of SHA256 and SHA384 for desired security level (since SHA1 is deprecated by NIST).

So, in TLS handshake, how does one specify the use SHA256 in the above signing procedure ?


Hari Tadepalli