AES encryption using a Diffie-Hellman question this is something that has always nagged at me and I've wanted to know the answer to.

Does AES create it's own shared secret symmetrical key after the DH process has completed?

I'm not as familiar with it as i am with know the process of say SSL (RSA,AES) where the public key encrypts the AES symmetrical key and then sends it across and host 2 decrypts with the private key and now knows the shared secret key.

With DH, I've always had conflicting answers, some say if you create a 1024 bit DH key then AES creates the 128 bit symmetrical key and passes it across, i don't feel like this is the case (i'm happy to be corrected either way). Some have also said that the key from DH is the key that AES uses for it's encryption. My question would be then isn't it just using a 1024 bit pub/pri key exchange to encrypt and decrypt data, or is it something in the middle? 

Thanks for the help
Does AES create it's own shared secret symmetrical key after the DH process has completed?


No. AES uses the key that is produced by the Diffie-Hellman key agreement, possibly after key derivation using a KDF or PRF.


  With DH, I've always had conflicting answers, some say if you create a 1024 bit DH key then AES creates the 128 bit symmetrical key and passes it across, i don't feel like this is the case (i'm happy to be corrected either way). Some have also said that the key from DH is the key that AES uses for it's encryption. My question would be then isn't it just using a 1024 bit public/private key exchange to encrypt and decrypt data, or is it something in the middle?


Diffie-Hellman is an asymmetric key agreement protocol. It requires two Diffie-Hellman key pairs (generated using a secure random and the Diffie-Hellman key generation procedure). Either of these key pairs can be ephemeral (i.e. used once or just a few times) or static (persistent, part of a DH certificate). After the public keys are exchanged the Diffie-Hellman calculation is performed and a shared secret is produced - this is the base value from which the shared (AES) keys can be derived.

The shared secret is large and not fully random. So generally it is run through a key derivation function or KDF to calculate the keys from the shared secret. TLS/SSL calls this the pseudo random function or PRF - a more generic term. For older versions (1.0 and 1.1) the TLS PRF internally uses a combination of MD5 and SHA1 (doubled in the HMAC construction, which is further doubled); 1.2 uses SHA256 (in double HMAC) for the pre-existing cipher suites (which specify MD5 or SHA-meaning-SHA1 for HMAC on data records) but newly-defined suites can name a different hash for the PRF and some do use SHA384, in conjunction with AES-256 for encryption.

Besides the master secret the KDF also uses the identity of the client / server and a label to derive keys. In the end you should have a total of two or four keys: two if authenticated encryption such as GCM is used and four if the authentication (HMAC) is performed separately from encryption.
In 1.0 the KDF also derives two initial IVs for CBC suites (which was associated with a flaw, since fixed) and in 1.2 the KDF can also derive two partial IVs for GCM or CCM suites. 

One of these keys are used to encrypt and possibly authenticate the messages from the client to the server and one for the messages in the other direction. It depends on the cipher suite if AES is used for encryption or not.



For TLS 1.3 the use of ephemeral keys is required (DHE or ECDHE). Authenticated encryption (an AEAD cipher) is required as well, so only two keys need to be produced for regular data encryption, although 1.3 also derives several more keys used during the handshake and optionally for special purposes. If RSA or ECDSA is used then it is only to authenticate the client / server; neither RSA or ECDSA will directly be involved in the key agreement.