2
$\begingroup$

From my understanding of the basic Diffie Hellman scheme, the final result is 1 key that is known to both sides and now can be used for symmetric encryption.

From my understanding of ECDHE-RSA scheme which provides PFS, a pair of ephemeral DH keys are created instead of another RSA pair because of computational considerations.

I can't seem to understand how does the process of ECDHE-RSA which creates a DH public + private key pair is similar to the basic Diffie Hellman scheme which results on 1 key, and not 2.

Is the actual basic Diffie Hellman scheme as described with simply with colors in wikipedia is being used in SSL/TLS?

I'm confused by the issue as it seems that the ECDHE-RSA process is actually an "RSA-RSA" process, only that the generation of keys is by DH (?)?

$\endgroup$
  • $\begingroup$ TL;DR: Both parties agree on a shared secret using (EC)DH usually and at the same time they assure each other that they are who they claim to be by using RSA signatures. $\endgroup$ – SEJPM Oct 26 '16 at 19:05
3
$\begingroup$

All Diffie-Hellman (including EC) uses two keypairs and produces one shared secret. The colors in the wikipedia article are only a metaphor; the actual process for original DH, now retronymed 'integer' or 'finite-field' DH if necessary to distinguish, uses a sufficiently large generated subgroup of the multiplicative group of integers modulo a prime (in current practice, a 2048-bit prime), while Elliptic-Curve DH (ECDH) uses an elliptic curve satisfying certain criteria, or to be precise the group generated on the curve by a base point.

Ephemeral is only(!) about timing. DH requires the parties each have a keypair (private and public key) at the time of the key agreement operation (for TLS, the handshake that creates a session). It cares nothing about how long before the operation these keys were created, or how long after the operation they are retained. You can create one DH keypair and use it all your life assuming it is strong enough and you keep it secure, or you can create a new keypair every millisecond, and the DH algorithms (integer or EC) work exactly the same either way.

However, in practice to use a keypair longer than a few minutes or hours at most you normally need to store it somewhere, because computers occasionally fail or must be shutdown for various reasons. There is always some risk a stored keypair can be compromised, although a wide variety of methods can be and are used to try to prevent compromise.

Ephemeral mode of (EC)DH does not store the keypairs and thus avoids this risk. They are created (at each end) immediately before doing the key agreement and discarded (securely!) immediately after. This provides Perfect Forward Secrecy, or just Forward Secrecy. Unless you have a bug like Heartbleed, or other side channel such as shared-VM interaction, that allows an adversary to get that information during the brief period it is in memory.

Yes ephemeral DH and ECDH are used in TLS, including but not limited to DHE-RSA and ECDSA-RSA which are authenticated (signed) with RSA as @SEJPM noted, instead of ephemeral RSA, mostly because generating RSA keys is more costly and in particular usually too costly to do at session initiation, while it is very practical to generate RSA keys used on a long-term basis (typically a year or more) for authentication.

$\endgroup$
0
$\begingroup$

Just to elaborate on the 1 key, 2 key, 1 shared secret issue:

In DH both users start with an integer $x_A, x_B$ (secret keys).

Then $g^{x_A}, g^{x_B}$ (public keys) are exchanged and the shared secret is computed as $g^{x_Ax_B}$.

The reason these can be viewed as private/public keys is because you could also keep $x$ and $g^x$. Then somebody can encrypt messages to you by picking a new secret $y$ and sending you both $g^y$ and the message encrypted with some key derived from $g^{xy}$.

Which is just the usual DH but one party keeps the same value and it is already know to the other party.

$\endgroup$

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.