8
$\begingroup$

If we read the Google line information about how the cypher the https communication, it reads:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

I understand it's using ECDHE to exchange keys, using ECDSA as digital signature and making the symmetric encryption with AES algorithm, using 128 bit keys. I don't know though what the GCM_SHA256 means. What is that?

$\endgroup$
17
$\begingroup$

I'll quickly decompose this cipher suite.

  1. TLS - standard starting point
  2. ECDHE - elliptic curve version of the Diffie-Hellman key-exchange using ephemeral keys (/exponents), other values for this position include RSA, DH and DHE
  3. ECDSA - signature algorithm, used to sign the key-exchange parameters, omitted for RSA, other values include RSA
  4. AES_128 - AES with a 128-bit key, AES_256 would denote a 256-bit key, with GCM, only AES, CAMELLIA and ARIA are possible, with AES being clearly the most popular and widely deployed choice.
  5. GCM - Galois/Counter Mode, a modern authenticated encryption with associated data (AEAD) mode of operation for blockciphers with 128-bit blocks.
  6. SHA256 - Secure Hash Algorithm (SHA)-256, the hash-function used as a basis for key-derivation from the master secret in the TLS protocol, as well as for authentication of the finished message. See Maarten's answer for more details.
$\endgroup$
  • 3
    $\begingroup$ actually, there are camellia and ARIA GCM cipher suites. AES is not the only cipher that works in GCM mode. gnutls supports camellia GCM cipher suites, and its not too difficult to add camellia GCM support to openssl (mostly copy+paste from the AES GCM code). $\endgroup$ – lily wilson Jun 19 '15 at 19:56
  • 1
    $\begingroup$ @lilywilson, thank you. I'll update the answer and emphasize that AES is the most common choice. $\endgroup$ – SEJPM Jun 19 '15 at 19:58
  • $\begingroup$ I'm sure that 6. is incorrect. Although the same hash function may also be used for the signature, I'm pretty sure that the acceptable hash algorithms are communicated differently (i.e. using extensions). $\endgroup$ – Maarten Bodewes Jun 21 '15 at 9:46
  • $\begingroup$ The kex and cert hash functions the client can use are communicated using extension. Tls 1.2 says symmetric keys are generated using prf which can be sha256 or sha384 or something else, as defined in the cipher suite. $\endgroup$ – Z.T. Jun 21 '15 at 10:49
  • 1
    $\begingroup$ @Z.T., Indeed the ciphersuite is not used for the signature stuff. An extension is used for signature. I've updated my answer to be more appropriate now. $\endgroup$ – SEJPM Jun 21 '15 at 12:51
7
$\begingroup$

In TLS 1.2 the GCM and SHA-256 in GCM_SHA256 should be seen separately.

GCM is the authenticated mode of operation used for confidentiality and integrity/authenticity of the messages (including the messages containing the data that TLS has been designed to protect).

SHA-256 is a parameter for the HMAC function which is used as PRF (pseudo random function) throughout the protocol.

5. HMAC and the Pseudorandom Function

The TLS record layer uses a keyed Message Authentication Code (MAC) to protect message integrity. The cipher suites defined in this document use a construction known as HMAC, described in [HMAC], which is based on a hash function. Other cipher suites MAY define their own MAC constructions, if needed.

In addition, a construction is required to do expansion of secrets into blocks of data for the purposes of key generation or validation. This pseudorandom function (PRF) takes as input a secret, a seed, and an identifying label and produces an output of arbitrary length.

In this section, we define one PRF, based on HMAC. This PRF with the SHA-256 hash function is used for all cipher suites defined in this document and in TLS documents published prior to this document when TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a stronger standard hash function.

Now because GCM already provides message integrity the HMAC / PRF construction is not needed for that purpose in the ciphersuite.


The HMAC based PRF is however used at other locations:

7.4.9 Finished

...

The Finished message is the first one protected with the just negotiated algorithms, keys, and secrets. Recipients of Finished messages MUST verify that the contents are correct. Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection.

...

verify_data
     PRF(master_secret, finished_label, Hash(handshake_messages))
        [0..verify_data_length-1];

... and ...

8.1. Computing the Master Secret

For all key exchange methods, the same algorithm is used to convert the pre_master_secret into the master_secret. The pre_master_secret should be deleted from memory once the master_secret has been computed.

 master_secret = PRF(pre_master_secret, "master secret",
                      ClientHello.random + ServerHello.random)
                      [0..47];

Note that TLS 1.2 deviates from the previous versions with regards to this:

1.2. Major Differences from TLS 1.1

  • The MD5/SHA-1 combination in the pseudorandom function (PRF) has been replaced with cipher-suite-specified PRFs. All cipher suites in this document use P_SHA256.
  • The MD5/SHA-1 combination in the digitally-signed element has been replaced with a single hash. Signed elements now include a field that explicitly specifies the hash algorithm used.

I've slanted the last sentence because it shows that the hash algorithm used for digital signatures used for authentication may very well differ from the once specified for the PRF in the ciphersuite.

$\endgroup$

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.