I'm confused about cipher suites with regards to TLS/SSL.

For example, I see names like RSA AES 256 CBC and RSA AES 256 GCM. I understand that RSA and AES are algorithms used for encoding and decoding information, involving some sort of secret value to do so.

My problem is that I see these algorithms referred to with regards to general OpenSSL settings, which makes me think, "Oh, the public and private keys are just a lot of bits that are two variables used in potentially many algorithms, and not specific to any one algorithm". But then I see them appear when generating public and private keys, which makes me think, "The algorithm to use is encoded in the keys, and depending on which you use when generating them, determines which algorithm you must use."

Could someone please give me a high-level explanation of where these technologies are used and what they mean in their different contexts within SSL?


1 Answer 1


It's complicated. What I'll present below is a dramatically simplified version of the details. (Because the real details are contained in hundreds of pages of RFCs.) There are essentially 3 cryptographic steps to a TLS connection:

  1. Authentication
  2. Key Exchange
  3. Encrypted Communications for the application

Authentication usually involves the server identifying itself to a client by presenting a certificate. This certificate validates that you are talking to a legitimate server: it has the hostname of the server embedded in, the expiration date, and is signed by a legitimate certificate authority. Additionally, it contains a public key -- possession of the matching private key is evidence that the certificate "belongs to you." Most often, this is an RSA keypair, though it's also possible to use DSA or ECDSA, or even another Public Key system (but on the open Internet, it's almost always 2048 or 4096 bit RSA). This is what gives clients certificate warnings (wrong hostname, bad CA, expired, etc.). This is the part that you generate a key for, and it needs to match your cipher specification.

Secondly is key exchange. If you're not looking for perfect forward secrecy, this can be as simple as the client encrypting a piece of data using the server's public key from its certificate. The server then decrypts this, and both sides use it to generate the connection key. On the other hand, if you want perfect forward secrecy (i.e., stealing the RSA key isn't enough to decrypt every previous connection) you use some variant of Diffie-Hellman key exchange: basically, a technique for arriving at a shared secret securely. Without an active man in the middle, a 3rd party can't get the shared key, and the authentication step ensured you don't have an active man in the middle. This DH step can be Diffie Hellman over an integer group (DHE) or over an elliptic curve (ECDHE). Whether you use RSA, DHE, or ECDHE for the key exchange, you now have a secret key shared between the client and server that nobody else should have.

Finally, you get the actual encrypted communication. Asymmetric crypo like RSA and DH are too slow for ongoing communications of large volumes, so we use symmetric crypto systems (like AES) for this. This uses the shared key exchanged in the previous step to communicate. Each packet is signed as well, either with an HMAC (so you might see SHA256 as part of your cipher specification) or a tag like GMAC from GCM (for AES-GCM). Additionally, AES (and other ciphers) can be run in several modes: GCM, CTR, CBC, etc.

Some examples:

ECDHE-RSA-AES128-SHA256 means to use Elliptic Curve Diffie-Hellman for key exchange, RSA for authentication, and AES128 with SHA256 signing of messages. (CBC mode is used, though not explicitly included.)

ECDHE-ECDSA-AES128-GCM-SHA256 is Elliptic Curve Diffie-Hellman for key exchange, Elliptic Curve DSA for authentication, AES 128 for crypto (GCM for signing packets, SHA256 for signing other data.)

AECDH-RC4-SHA is Anonymous Elliptic Curve Diffie Hellman for key exchange, no authentication (hence anonymous), RC4 for encryption, and SHA-1 for packet authentication. (Please don't use this. All of it is broken by modern standards. It's an example.)

  • thank you so much. im curious about the authentication step. the key pair used for that step is generated with a single algorithm (for example, RSA) and can ONLY be used with RSA. it has no bearing on the subsequent key exchange or encrypted communication steps. ie, specifying AES anywhere in the authentication phase would be nonsensical (because it is symmetric). correct me if any of that is wrong. thanks again!
    – tau
    Commented Feb 24, 2018 at 2:58
  • im sorry, hate to add a second comment but couldnt figure out how to edit my first in time. are the key exchange and encrypted communication steps flexible? in other words, i understand how authentication is not flexible because you generate your certifications with a specific algorithm, but could the other two steps change connection-to-connection depending on server/client capabilities?
    – tau
    Commented Feb 24, 2018 at 3:10
  • 1
    Yes, symmetric algorithms are not used for key exchange, although you can specify PSK (PSK-AES256-CBC-SHA384) which requires both sides to already know the symmetric key. (Though I've never seen it used in practice.)
    – David
    Commented Feb 24, 2018 at 3:18
  • 1
    Also, to answer the 2nd comment: yes, this is why you can specify a list of used cipher combinations. You can see ssllabs reports to see the negotiation between different ciphers and browsers.
    – David
    Commented Feb 24, 2018 at 3:19
  • 1
    Note the RFC names follow the pattern {SSL,TLS}_{kx&auth}_WITH_{symmetric}_{hash} but OpenSSL has variant names that omit RSA from suites using 'plain' RSA, and makes some other smaller changes; see my answer at stackoverflow.com/questions/36463429/… Commented Feb 24, 2018 at 3:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .