Why use 256-bit symmetric encryption when the key is exchanged using asymmetric cryptography that only provides 112 bits of security?

Since a 2048-bit RSA key or a DH shared secret obtainet using a 2048-bit prime only provides the equivalent of 112-bits of security in symmetric encryption, what's the advantage of using AES-256 with a key derived from this level of asymmetric cryptography?

Why many protocols such as SSL use it? Is there any advantage?

• You don’t have to use a 2048-bit RSA key with TLS; it’s just common. (It’s also most common to use AES-128 instead of -256.)
– Ry-
Apr 10 '17 at 9:01
• This 1Password blog entry is tangentially related, and gives an argument by an application designer who chose AES-256 even though they don't believe it would be more secure in practice than AES-128. Apr 10 '17 at 22:21

As indicated with Ryan, the key size for RSA is not a configuration option of a TLS ciphersuite. The RSA key size is part of the authentication phase which is part of the TLS protocol, but it is not configured through the ciphersuite definitions. So the RSA_ ciphersuites and ECDHE_RSA ciphersuites do not specify any key size for RSA.

The AES key size is however a configuration option. This is because the AES keys are not static, they are session keys and session keys are ephemeral. They will be generated on each new TLS connection. To generate the right size AES key the size must be known beforehand, otherwise the key derivation cannot take place.

Usually you would link a 2048 bit RSA key with either AES-128 or 3 key triple-DES. However it's perfectly possible to derive AES-256 session keys using RSA-2048. It won't harm performance much either; AES-256 is only marginally slower than AES-128 using a software implementation (in hardware the difference may even be non-existent). So there is no penalty to using AES_256 in a ciphersuite. Allowing any AES ciphersuite - regardless of key size - may help (somewhat) with the establishment of a good ciphersuite - i.e. compatibility between client and server.

As indicated before, the RSA key may just be used to establish authentication. ECDHE or DHE may be used to establish the session keys to provide forward secrecy. So the strength of the keys used for confidentiality may be much higher then the key used for authentication.

As the authentication is required to happen in real time the strength of the authentication key may be significantly lower to the one used to provide confidentiality: it may be that an attacker can recover interesting information a long time after the connection as established (and eavesdropped). The authentication key may be revoked or be over the date of expiry a long time before that.

Then again, if you specify just AES_256 ciphersuites or put AES_256 above AES_128 ciphersuites you are basically lying to your users. You are offering a kind of protection that you cannot deliver due to the small key size used for RSA.

I would not feel comfortable doing so even when I would combine RSA with a ciphersuite offering forward secrecy.

I'm going to try and come up with some reasons but basically my answer is:

It's probably a mistake.

However, let's see why people might want to use it:

1. It sounds better and people are paranoid. This is almost always the reason for AES-256.

2. Post quantum security: Given a quantum computer you would need a 256 bit key to get 128 bits of security. (I guess you would need a weird argument about quantum computers with few qubits as well to keep RSA alive.)

3. Cipher suites fix one but not the other. Your cipher suite can state that it wants to use AES_256_GCM for the actual data but it can only state it wants to use RSA for the handshake. (I guess this is a version of 1.)