Security of ciphersuite and key

Question

Is anyone able to cite resources that can be based on choosing a cipher suite?

In my case, for a VPN server (OpenVPN) I chose a set of ciphers:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

It provides 128 bits of security. I have a dilemma regarding the length of the RSA private key. The 2048-bit key provides 112 security bits. If it is necessary to provide 128 bits, I would have to create a key with a length of 3072 bits - but this will have a significant effect on performance. If anyone could be able to direct me how to choose the right solution so that I could reasonably justify the choice would be great.

Do you really need to use TLS 1.2? Why don't you use TLS 1.3 cipher suites? — kelalaka, Jul 18 '19 at 22:04
Most (all?) browsers still default to TLS 1.2 so supporting TLS 1.2 ciphersuites seems totally reasonable. — puzzlepalace, Jul 18 '19 at 23:34
Due to Bleichenbacher's attack, you should not use RSA at all if you have the choice. — tylo, Jul 19 '19 at 10:22

score 1 · Accepted Answer · answered Jul 19 '19 at 07:25

The difference between “112 bits” and “128 bits” matters for compliance to certain standards, but not for security. Both are out of reach of current computing technology. Furthermore, 112 bits for RSA-2048 is an estimate based on current attack techniques. A disruption such as quantum computers that are useful at cryptanalysis would break both RSA and AES, but in different ways — RSA would be trivialised at any pratcical key size, while symmetric cryptography would only have its “bit strength” halved.

So either you have to comply to some strict standard, and then you need to do what the standard says; or you don't have to comply to some strict standard, and then RSA-2048 is fine for authentication (which is what it's used for here). This is true even if you're exchanging long-term secrets: to break the security of your VPN by attacking the RSA part, the attacker has to breach it live, to cause the client to accept a fake server. The use of ECDHE provides forward secrecy, so there's no way to reconstruct the plaintext from the ciphertext and the server's RSA key later (if the attacker managed to break RSA, or more realistically to obtain the key). If you are concerned about very long-term secrecy, switching to AES-256 is actually more useful than moving away from RSA-2048 (and then you should also check that you're using a stronger curve, at least P384R1).

However there's little reason to use RSA these days. Elliptic curve cryptography has generally better performance for the same security. Your default choice should be TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (or AES_256 instead of AES_128, or SHA384 instead of SHA256, or CCM instead of GCM), sticking to widely-supported ciphersuites. EdDSA and ChaCha20_Poly1305 are also good choices if supported. RSA as used in TLS_(EC)DHE_RSA_xxx ciphersuites has better performance than elliptic curve methods on the client side (at the cost of worse server-side performance) if you're only authenticating the server, which is often the case on the web. But if the two sides authenticate each other, as is normally the case on a VPN, elliptic curves have better performance.

Note OpenVPN uses the TLS connection only to establish IPsec keys, so for postquantum you need AES-256 or comparable both on the TLS (control) connection to protect the keying material and also on the data connection to protect the data. — dave_thompson_085, Jul 20 '19 at 03:31

Security of ciphersuite and key

1 Answers1