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

migrated from crypto.stackexchange.com Feb 2 '15 at 0:52

This question came from our site for software developers, mathematicians and others interested in cryptography.


RFC 4492 specifies ECC for TLS1.0 and TLS1.1. It does not cover TLS1.2 because it was written before TLS1.2; notice that 4492 is less than 5246. RFC 5246 TLS1.2 changes the signature structure for all signing algorithms including ECDSA, and also adds a Hello extension to negotiate supported signing algorithms (including hash) more flexibly.

RFC 5246 A.7 Changes to RFC 4492

RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This
document changes some of the structures used in that document. This
section details the required changes for implementors of both RFC
4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing
RFC 4492 do not need to read this section.

This document adds a "signature_algorithm" field to the digitally-
signed element in order to identify the signature and digest
algorithms used to create a signature. This change applies to
digital signatures formed using ECDSA as well, thus allowing ECDSA
signatures to be used with digest algorithms other than SHA-1,
provided such use is compatible with the certificate and any
restrictions imposed by future revisions of [PKIX].

As described in Sections 7.4.2 and 7.4.6, the restrictions on the
signature algorithms used to sign certificates are no longer tied to
the cipher suite (when used by the server) or the
ClientCertificateType (when used by the client). Thus, the
restrictions on the algorithm used to sign certificates specified in
Sections 2 and 3 of RFC 4492 are also relaxed. As in this document,
the restrictions on the keys in the end-entity certificate remain.

In particular RFC 5246 4.7 Cryptographic Attributes

A digitally-signed element is encoded as a struct DigitallySigned:

  struct {
     SignatureAndHashAlgorithm algorithm;
     opaque signature<0..2^16-1>;
  } DigitallySigned;

The algorithm field specifies the algorithm used (see Section for the definition of this field). Note that the
introduction of the algorithm field is a change from previous
versions. .... RSA .... DSA ....

Additional points:

  • the server signs its ECDHE public key and the curve (which in practice, especially for Suite B, is named form rather than explicit, thus quite small) (edit, thanks David) as well as the nonces, with at least the client nonce proving freshness

  • Suite B requirements are set by NSA not NIST. IIRC Suite B required SHA256 and SHA384 before NIST "deprecated" SHA1.

  • RFC 5430 was obsoleted by RFC 6460 which requires TLS1.2 and GCM as well as ECDHE-ECDSA.

  • Suite B requirements are set by NSA not NIST. IIRC Suite B required SHA256 and SHA384 before NIST "deprecated" SHA1: This also seems to imply that NIST specified the need to use alternative hash functions even before TLS 1.2 (with the provision to select a hash function other than SHA1) RFC was in place (?) – user13311 Jan 27 '15 at 23:31
  • to add to your additional point number 1: the server signs: (ClientHello.random | ServerHello.random | ServerKeyExchange.params ) where params are the ecdhe pubkey (and its length) and the name of the curve. – David 天宇 Wong May 13 '15 at 20:54
  • @user13311 NIST established the SHA-2 hashes as optional (not required) in 2002, and defined RSA and expanded DSA signatures using them (or rather their sizes) in 186-3 proposed in 2006 but not finalized until 2009. It also stated a policy in 2006 that SHA1 should not be used for (new) signatures after 2010, but had to relax that to 2013. RFC 5246 came out in 2008, so it was before NIST's attempted deadline and well before their actual deadline. And the industry didn't really get it done until this year. – dave_thompson_085 May 23 '15 at 20:01
  • 1
    @David edited. Note ECDHE params are usually a standard curve "name" (encoded as a number), but can be "explicit" with all the parameters of a Weierstrauss prime or binary curve: prime or size and polynomial, coefficients a and b, base point, order and cofactor. – dave_thompson_085 May 23 '15 at 20:03

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.