Explain this client server encryption technique - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys

Below is the explanation of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 -

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 the 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