In a TLS 1.2 cipher suite name such as TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, what does each element select?
answer
- four choices packed into one token
- the order is fixed; read positionally
- WITH separates agreement from protection
- last element is a hash, not a cipher
- AEAD suites carry no MAC element
basics
~20 sA TLS 1.2 suite name lists four choices in fixed order: the key exchange, the algorithm that authenticates the server, the bulk cipher with its key size and mode, and the hash used for the record MAC or the pseudorandom function.
solid answer
~40 sRead the token left to right. After the `TLS_` prefix, the elements before `WITH_` name how the connection agrees a secret and how the server proves who it is: in `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` that is an ephemeral elliptic-curve exchange authenticated by an RSA signature. After `WITH_` comes the protection of application data: `AES_128_CBC` is the algorithm, the symmetric key length in bits, and the mode. The trailing `SHA256` is a hash, not a cipher — in a CBC suite it is the hash inside the per-record HMAC, while in an AEAD suite such as one ending `AES_128_GCM_SHA256` there is no separate MAC and the hash names the pseudorandom function instead. On the wire the whole token is just a two-octet registered code point; the name is the registry's label for that number.
code
pseudocode · 6 linessuite_name = "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
key_exchange = "ECDHE" # ephemeral, fresh per connection
authentication = "RSA" # signature proving the server
bulk_cipher = "AES_128_CBC" # algorithm, key bits, mode
hash = "SHA256" # record MAC here; PRF in an AEAD suitego deeper
Recall the four positions in order and that everything after WITH protects application data. Being able to say which element is the hash already separates you from candidates who read the token as one opaque blob.
Explain why the trailing hash means one thing beside a CBC bulk cipher and another beside an AEAD one, and why an ephemeral first element is a per-connection property rather than a property of the certificate.
Show you can audit a list someone else wrote: check every token's exchange, authentication element against the deployed certificate's key type, and whether the mode is authenticated — position by position, not by eye.
Frame suite naming as a governance surface. A fleet configured once and audited years later needs a rule for what a suite list may contain that survives staff turnover, not a one-time hand-picked list.
## What a cipher suite is A **cipher suite** is a named bundle of algorithm choices that both peers agree on once, during the handshake, and then use for the life of the connection. The client offers a list of them; the server picks one and echoes it back. On the wire a suite is a **two-octet code point** — the long underscore-separated token is only the human-readable label the registry gives that number, which is why the same suite looks like a word in a configuration file and like two bytes in a capture. In TLS 1.2 (`RFC 5246`) that label packs **four independent decisions** into one token, in a fixed order. Knowing the order is the whole skill: the token is positional, and an element read in the wrong position turns a hash into a cipher. ## Reading the token left to right For `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256`: 1. **`TLS_`** — the namespace prefix every registered suite carries. 2. **`ECDHE`** — the **key exchange**: how the two sides arrive at a shared secret. `E` for ephemeral, so a fresh value per connection. 3. **`RSA`** — the **authentication**: the signature algorithm, and therefore the kind of key in the server's end-entity certificate, that proves the exchange was run by the party named in that certificate. 4. **`WITH_`** — the separator. Everything before it is about *agreeing and proving*; everything after it is about *protecting bytes*. 5. **`AES_128_CBC`** — the **bulk cipher**: algorithm, symmetric key length in bits, and mode of operation. 6. **`SHA256`** — the trailing **hash**. | Element | In this suite | Selects | |---|---|---| | Key exchange | `ECDHE` | How the shared secret is agreed | | Authentication | `RSA` | The signature that binds the exchange to the certificate | | Bulk cipher | `AES_128_CBC` | Algorithm, key size, mode for application data | | Hash | `SHA256` | The record MAC hash, or the pseudorandom function hash | ## The trailing hash does two different jobs This is where candidates slip. In a **CBC** suite the record's integrity comes from a separate **HMAC**, and the trailing element names the hash inside it. In an **AEAD** suite — one whose bulk cipher element ends in `GCM` or `CCM` — there is **no separate MAC element at all**, because the mode produces the authentication tag itself; the trailing hash instead names the hash the key-derivation pseudorandom function uses. So `..._AES_128_CBC_SHA256` and `..._AES_128_GCM_SHA256` end in the same four characters that mean two different things. A suite whose first element stands alone, with no second algorithm before `WITH_`, names one algorithm doing both jobs: the same key both transports the secret and authenticates the server, so there is nothing ephemeral in the exchange. ## What the token does not tell you - **Not the named group or curve.** `ECDHE` says the exchange is ephemeral elliptic-curve; *which* group is negotiated separately, in `supported_groups(10)`. - **Not which certificate will be presented.** `RSA` constrains the key type; the signature scheme actually used is negotiated in `signature_algorithms(13)`. - **Not the protocol version.** A suite is only valid for the versions it was registered for, and the negotiated version is decided before the suite is. - **Not how each record's nonce is built**, nor how many records one key may protect. ## Reading one off a commissioning record A fleet of fixed-function hospital pharmacy dispensing cabinets has its suite list written once at commissioning and read years later by someone auditing it who did not choose it. That reader's whole job is this decomposition: for every token on the list, is the exchange ephemeral, is the authentication element the key type the deployed certificate actually has, is the bulk cipher an authenticated mode, and is the trailing hash a MAC hash or a derivation hash? A list that looks uniform at a glance often is not — two entries can share a bulk cipher and differ in whether anything ephemeral happens at all, and that difference is invisible unless you read position by position. The practical habit: never quote a suite by its middle. Quote the whole token, because the token is only meaningful whole.
- Why do two suites that both end in SHA256 not necessarily use that hash for the same purpose?Because the trailing element's role depends on the bulk cipher beside it. With a CBC bulk cipher the records carry a separate HMAC and the hash names the hash inside it. With a GCM or CCM bulk cipher the mode produces its own authentication tag, there is no MAC element, and the trailing hash names the hash used by the key-derivation pseudorandom function instead.
- A suite name mentions AES_128. Does that pin down everything about the key material used on the connection?No. It pins the symmetric algorithm, the key length in bits and the mode used to protect application data. It does not say which ephemeral group produced the shared secret, which signature scheme was actually used, or how record keys and nonces are derived from that secret — those are negotiated or derived separately.
- What is actually carried on the wire when a suite is offered and selected?A two-octet registered code point, never the text name. The client sends a list of code points in its ClientHello and the server echoes exactly one back in its ServerHello. The underscore-separated token is the registry label used by humans, configuration files and audit reports.
A suite name is like a tyre's sidewall code: one fixed-order string encoding width, construction and rating. It tells you everything, and nothing, until you know which position means what.
saying these in an interview costs you the question
- Calling the trailing SHA256 a cipher rather than a hash
- Reading the suite name as free-form text rather than positionally
- Claiming the suite name pins down which curve or group is used
- Assuming a GCM suite still applies a separate record MAC
- Believing the full text token travels on the wire