1
$\begingroup$

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

Improve this question
$\endgroup$
1
  • $\begingroup$ No, AES is only a block cipher. You need to provide it with a symmetrical key, it does not do key agreement on its own. You can of course run DHE first and get a session key which you then use for AES. (keep in mind it’s probably not a good idea to invent protocols yourself). For TLS (with and without DHE) the process to derive Session keys for the AES cipher is more involved. $\endgroup$
    – eckes
    Commented Mar 24, 2018 at 1:05

2 Answers 2

Reset to default
3
$\begingroup$

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.

Improve this answer
$\endgroup$
2
  • $\begingroup$ A few small fixes proposed; I tried to avoid going too far into the weeds, but feel free to revise if you disagree. $\endgroup$
    – dave_thompson_085
    Commented Mar 25, 2018 at 6:40
  • $\begingroup$ @dave_thompson_085 OK, it does make it a bit harder to read but I guess any simplified answer should not divert from the actual facts, so fine :) $\endgroup$
    – Maarten Bodewes ♦
    Commented Mar 25, 2018 at 14:11
2
$\begingroup$

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

No, Diffie-Hellman establishes the shared secret used by AES.

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

This is not accurate.

Some have also said that the key from DH is the key that AES uses for it's encryption.

This is accurate.

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?

Diffie-Hellman is a key agreement algorithm. It allows two parties to establish a shared secret over an insecure communications channel. The public and private keys can be used to generate a mutual shared secret.

AES is a block cipher that requires a source of secret material to use as the key. It additionally requires a mode of operation and initialization vector to use as a cipher to encrypt more than a single block of data, but this is beyond the scope of the question.

Conclusion

Diffie-Hellman is used to establish a shared secret that is typically hashed to create a key that can be used with a symmetric cipher such as AES.

Improve this answer
$\endgroup$
3
  • $\begingroup$ So what sized key would AES be using to encrypt the data if 1024 bit DH pub/pri key is used? The shared key that both DH peers come to generate is a 1024 bit key is it not? So if AES 128 bit is being used and it uses the key from DH what key size is AES using if it encrypts everything using that DH key on one peer for it to be then decrypted on the opposite peer using the same key? Sorry if i'm missing the point, it's still slightly confusing $\endgroup$
    – Michael
    Commented Mar 24, 2018 at 1:46
  • 2
    $\begingroup$ @Michael Typically you would hash the resultant shared secret that is produced by DH. This accomplishes a few things: It makes the key smaller while ensuring that the output bits are uniformly random, and it provides some protection for the private key against compromise if the shared secret key is compromised somehow. For a simple example, you could stick the shared secret established by DH into sha256 to produce a 256-bit key for use with AES-256. Alternatively, you could just truncate the shared secret down to the required size, but I wouldn't be surprised if there were problems with that. $\endgroup$
    – Ella Rose
    Commented Mar 24, 2018 at 2:29
  • $\begingroup$ Just to make it clear in almost all safe constructs the DH shared secret is not directly used for AES key (so the quoted statement is not correct either). But it’s one of the major sources contributing to a key derivation (see the master secret definition in TLS for example). And some protocols also have a key transport step in between (encrypt a random AES key with the AES key derived from the DH key). So the bulk encryption key would be totally independent of the DH calculation. $\endgroup$
    – eckes
    Commented Mar 24, 2018 at 3:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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