Client-server encryption technique explanation (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys)

Asymmetric Cryptography

There are two different parts to creating a TLS session. There is the asymmetric cryptography, portion which is an exchange of public keys between two points. Which is what you saw in your Alice and Bob example. This only allows the exchange of asymmetric keys for asymmetric encryption/decryption. This is the ECDHE portion. The RSA portion describes the signing algorithm used to authenticate the key exchange. This is also performed with asymmetric cryptography. The idea is that you sign the data with your private key, and then the other party can verify with your public key.

Symmetric Cryptography

You encrypt symmetric encryption/decryption keys with your asymmetric key. Asymmetric encryption is very slow (relatively speaking). You don't want to have to encrypt with it constantly. This is what Symmetric Cryptography is for. So now we're at AES_128_GCM.

• AES is the symmetric algorithm
• 128 refers to key size in bits
• GCM is the mode of operation

So what exactly does our asymmetric key encrypt? Well we want to essentially encrypt the symmetric key (in this case 128 bits, 16 bytes). If anyone knew the symmetric key then they could decrypt all of our data. For TLS the symmetric key isn't sent directly. Something called the pre-master secret is encrypted and sent across. From this value the client and server can generate all the keys and IVs needed for encryption and data integrity. Detailed look at the TLS Key Exchange

Data Integrity

Data integrity is needed throughout this process, as well as with the encrypted channel. As you saw when looking up GCM, the encryption mode of operation itself provides for the integrity of the data being encrypted. However, the public key handshake itself must also be confirmed. If someone in the middle changed data while being transmitted then how could we know nothing was tampered with? This is what instance where the negotiated hash function is used, SHA256. Every piece of the handshake is hashed together, and the final hash is transmitted along with the encrypted pre-master secret. The other side verifies this hash to ensure all data that was meant to be sent was received.

SHA256, as mentioned by another poster, is also used for the Pseudo-Random Function (PRF). This is what expands the pre-master secret sent between the two parties into the session keys we need for encryption.

For other modes of operation, each message would be hashed with this integrity algorithm as well. When the data is decrypted the hash is verified before using the plaintext.

Here is a great explanation for how these derivations happen for different TLS versions.

Put all these pieces together and you have yourself a secure mode of communication!

---

You can list all possible ciphers that OpenSSL supports with openssl ciphers. You can go further and print the details of any of these cipher suites with the -V

For example:

$ openssl ciphers -V ECDHE-RSA-AES256-GCM-SHA384
          0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD

• 0xC0,0x30 represents the two byte identifier for the cipher suite
• Kx=ECDH represents the key exchange algorithm
• Au=RSA represents the authentication algorithm
• Enc=AESGCM(256) represents the symmetric encryption algorithm
• Mac=AEAD represents the message authentication check algorithm used

You're right that ECDHE is being used for the key exchange and RSA is being used for verifying the server's identity. However, what are you going to do with the exchanged key? You'll need to use a certain algorithm to encrypt/decrypt communication with use of that exchanged key.

128-bits AES is used in this case, in GCM mode.

Normally the hashing algorithm, SHA256 in this case, is used for the hash-based message authentication code (HMAC). This is to provide authenticated encryption. However, as you mentioned, AES-GCM already provides authenticated encryption, so it is not used here.

Since TLS1.2, the hashing algorithm mentioned at the end of a cipher suite is also used for the pseudorandom function (PRF) in TLS.