2
$\begingroup$

In RSA key exchange, the client picks a premaster secret and encrypts it with the RSA public key in the server certificate, and sends it to the server. This offers no forward secrecy.

In ECDHE key exchange, the client and server both generate ephemeral EC key pairs, and use DH key exchange to negotiate the premaster secret. The server public ephemeral public key is signed using the server authentication certificate. This gives forward secrecy.

In the latter, two ephemeral key pairs have to be generated, by the server and the client. How about the following mix of both key exchange methods that does not need the client to generate an EC key pair:

  1. Server generates ephemeral EC key pair, signs the public key using the server authentication certificate.
  2. Server sends the ephemeral EC key pair public key to the client.
  3. Client picks a premaster secret, encrypts it using the server ephemeral EC public key and sends it back.

What are the inevitable downsides that make ECDHE superior? I don't see a glaring security hole. Maybe difficulties to use an EC keypair for encryption?

Improve this question
$\endgroup$
3
  • 3
    $\begingroup$ "encrypts it using the server ephemeral EC" - How do you encrypt the secret, using ECIES? This results basically in the same thing. $\endgroup$
    – shumy
    Feb 18 '20 at 18:01
  • $\begingroup$ Most / All ECC encryption schemes we use are based on doing ECDH key agreement and then using the shared secret for some form of encryption, do this would be needlessly more complicated. $\endgroup$
    – SEJPM ♦
    Feb 18 '20 at 18:27
  • $\begingroup$ In TLS 1.3 it is obligatory Why Static RSA and Diffie-Hellman cipher suites have been removed in TLS 1.3? $\endgroup$
    – kelalaka
    Feb 18 '20 at 20:14
3
$\begingroup$

"Maybe difficulties to use an EC keypair for encryption?"; yes exactly, as there are no direct EC encryption primitives that can be used. ElGamal EC encryption is possible, but it requires all kinds of tricks to get it working. There is the mapping of the message to an EC point, for instance. There is ECIES, but that really comes down to performing ECDHE in the first place, with the additional disadvantage of needing a cipher.

Besides that, for RSA, key pair generation is one of the slowest algorithms that you may see. Not only is it slow, but it is also very unpredictable as it is unknown when the two required primes are found. With EC, it is very easy:

  1. create a random number between 1 and N (exclusive);
  2. perform point multiplication of that number with the base point G to get to the public point.

So basically it is as fast as the DH operation itself. There is no long waiting time for primes to be generated at all. So because the key generation itself does not pose much of a problem, there is no pressing need to change either.

One important idea of TLS 1.3 was bringing down the number of round trips. It even guesses the algorithms present at the other end for the initial key agreement. It can then immediately send the ephemeral public key of the client to the server, which responds with the server's ephemeral public key to setup the channel. That way the encrypted channel can (and will) be setup after only two messages. With encryption the client (who has to initiate the connection) first asks for the public key, receives it and then encrypts with it.

That is, ECDH speeds things up if the client doesn't use session resumption, a separate trick to speed things up.

Another smaller difference is that the random key in ECDH is now dependent on the random data of two parties. The various clients may have different strengths of random number generator, and encryption of a secret has the disadvantage that the secret itself is not fully random, e.g. when a RNG is used that is not cryptographically secure. However, with ECDH is does mean that a completely failing RNG will completely show the established shared secret as the ephemeral private key may become known.

Note too that simply bringing the number of options down was an important initiative in TLS 1.3. Having options just for the sake of it only makes a protocol less secure, not more secure. IMHO it doesn't even make sense to have different security levels for the various algorithms used for a specific ciphersuite (not including the difference with the security level of the certificates used for authentication).

Improve this answer
$\endgroup$
2
  • $\begingroup$ Good point regarding the reliance on both pRNGs in ECDHE. I think however that this does not reduce its fault tolerance, since if any one of the two pRNGs fail and one of the private keys becomes known, then the exchanged secret will be revealed. $\endgroup$
    – heinzelotto
    Feb 19 '20 at 9:51
  • 1
    $\begingroup$ Another benefit of ECDHE is that it does not require a roundtrip to share the secret. In contrast, in the proposed key exchange the server sends their ephemeral public key first and the client then returns the encrypted secret. In TLS1.3 the server would have to wait for another client response containing the secret instead of sending encrypted data right away, which is bad! $\endgroup$
    – heinzelotto
    Feb 19 '20 at 10:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.