[Back]With Ephemeral Diffie-Hellman (DHE) a different key is used for each connection, and a leakage of the public key would still mean that all of the communications were secure.
Ephemeral Diffie-Hellman with RSA (DHE-RSA)
The problem with DH is that if Bob and Alice generate the same values, they will always end up with the same secret key. With Ephemeral Diffie-Hellman (DHE) a different key is used for each connection, and a leakage of the public key would still mean that all of the communications were secure. Within DHE-RSA, the server signs the Diffie-Hellman parameter (using a private key from an RSA key pair) to create a pre-master secret, and where a master is created which is then used to generate a shared symmetric encryption key.
Normally when we create a shared key we created a tunneled connected between a client and a server. This is normally defined through an SSL (Secure Sockey Layer) or TLS (Transport Layer Security), and where a client connects to a server. Normally we define the tunnel type (such as TLS or SSL), the key exchange method (such as DHE-RSA), a symmetric key method to be used for the encryption process (such as 256-bit AES with CBC) and a hashing method (such as SHA). This can be defined as a string as:
and is contained in a ClientHello message that goes from the client to the server. A ServerHello is then returned with the digital certificate of the server and which contains the public key of the server. A simplified handshake is defined in Figure 1 where the client sends the definition for a TLS cipher suite.
In this case we are using a handshaking methods of DHE-RSA, a 256-bit AES-CBC shared key, and with a SHA hash signature. The server will then generate a random value (x) and create a value for G (the generator) and N (the prime number). Along with this the server will then generate G^x and take the G, N and G^x parameters and encrypt them with the private key of the server. This created a signature for the server.
Next the server will create a message with G, N, G^x and the signature of nonces (a random value) and the Diffie-Hellman parameters (G, N, and G^x). The server then sends this message with a digital certificate containing its public key.
When the client receives it, it will check the certificate for its validity, and then extract the public key. The client then checks the signature by decrypting the signed value and check it against the parameters already contained in the message (G, N, and G^x). If the values are the same, then the server has been validated. Now, as with DH, the client will create a random value of y, and send the value of G^y back to the server. The G^(xy) value will then be the pre-master secret. In this way the client knows that it has received a valid value of the DH parameters, and can trust that the connection does not have a man-in-the-middle.
Figure 1: DHE-RSA
We now have a pre-master secret, as illustrated in Figure 2, which is shared by the client and server, and which can then be used to create a master key by using a PRF (Pseudorandom Function). In TLS 1.2 this is created using an HMCA-SHA256 hashed value (and which will generate a 256-bit key). To create the actual key used we feed the master key and the nonce into the PRF and generate the shared key for the session.
Figure 2: Generating the shared key
Forward Secrecy and Ephemeral
An important concept within key exchange the usage of forward secrecy (FS), which means that a comprise of the long-term keys will not compromise any previous session keys. For example if we send the public key of the server to the client, and then the client sends back a session key for the connection which is encrypted with the public key of the server, then the server will then decrypt this and determine the session. A leakage of the public key of the server would cause all the sessions which used this specific public key to be compromised. FS thus aims to overcome this by making sure that all the sessions keys could not be compromised, even though the long-term key was compromised. The problem with using the RSA method to pass keys is that a breach of the long keys would breach the keys previously used for secure communications.
Another important concept is where is key is ephemeral. With some key exchange methods, the same key will be generated if the same parameters are used on either side. This can cause problems as an intruder could guess the key, or even where the key was static and never changed. With ephemeral methods a different key is used for each connection, and, again, the leakage of any long-term would not cause all the associated session keys to be breached. The problem with the Diffie-Hellman method is that the keys are not ephemeral, so we should avoid it in generating keys.
import random import sys p=67 G=34 #Safe generators for selecting G for a prime of 67: #2 7 11 12 13 18 20 28 31 32 34 41 44 46 48 50 51 57 61 63 if (len(sys.argv)>1): G=int(sys.argv) x= random.randint(3, p) y= random.randint(3, p) G_x = (G**x) % p G_y = (G**y) % p print('Server selects:') print('G=',G, ', N=',p) print('Server creates:') print('x=',x,', G^x=',G_x) print('Server passes: G, N and G^x') print() print() print('Client creates:') print('y=',y,', G^y=',G_y) print() shared = (G_x**y) % p print('Shared key: ',shared) shared = (G_y**x) % p print('Shared key: ',shared)