How is Diffie-Hellman linked to AES?

I have just learnt about Diffie-Hellman and AES. However, I cannot seem to understand how they link.

My initial idea was that Diffie-hellman is used to transfer a key for AES decryption. After further research, I understand that AES uses the key that is produced by the Diffie-Hellman.

I don't understand how it uses it and where the information exchange relates to all of this. The whole purpose of AES is to transfer information by encrypting it. How can it do that using the code generated by the Diffie-Hellman?

Where do KDF's tie into all of this?

• First, DHKE, or ECDH doesn't produce output equal to \AES key size. A good way is to use KDF to preserve the entropy. 2. The encoding of the point on ECs are not uniform, so a KDF helps ECDH to mitigate any future problem. 3. remember we have DLIES and ECIES that combines these. Commented Aug 14, 2022 at 20:58

My initial idea was that Diffie-Hellman is used to transfer a key for AES decryption, but come to do further research, AES uses the key that is produced by the Diffie-Hellman

Diffie-Hellman is a key agreement algorithm that allows two parties to exchange public keys to be able to calculate a shared secret.

Here's a simple example:

1. The sender has the recipient's public key. They use their private key and the recipient's public key to compute a shared secret. They use the shared secret to derive an encryption key. They encrypt the message, which can be sent to the recipient.

2. The recipient has the sender's public key. They use their private key and the sender's public key to compute the same shared secret. They use the shared secret to derive the same encryption key. They decrypt the received message.

By contrast, just sharing an AES key (a symmetric key) means the channel of communication needs to be secure (e.g. encrypted). That's because symmetric keys are meant to remain secret, unlike public keys. Setting up a secure channel is often not possible, so a key exchange is used instead.

where do KDFs tie into all this?

Shared secrets shouldn't be used as keys directly because they're not uniformly random (aka they're weaker than you'd like). So, you use a KDF to derive a (strong) uniformly random key to use with your encryption algorithm.

A KDF can also allow you to personalise the key with context information (e.g. the name of your application) and/or randomise the derived key using a salt.

It is also possible to derive multiple keys from the same shared secret using one or more iterations of a KDF, using different context information. For instance, a KDF can be used to derive an AES key and an HMAC key for message authentication.

• Just to summarise: DH is used (in my case this was elliptic curve DH, so the x coordinate is utilized as the shared secret), now both parties have a "shared secret" after the full process of DH is done, this shared secret that both parties now have, is turned into a symmetric key for AES after being put through a KDF and because both people had the same value for the "shared secret" they now have the same key they can use to encrypt messages and send them? Hopefully I understood correctly Commented Aug 11, 2022 at 15:30
• In a nutshell, yes. Commented Aug 11, 2022 at 15:59
• Note that the above description doesn't contain any way of trusting the exchange. Without trust in the exchange and/or the public keys the scheme is vulnerable against man-in-the middle. Commonly the messages of the exchange are themselves authenticated using a signing key. Commented Aug 12, 2022 at 0:29
• I should've mentioned that yeah. My example assumes the public keys are exchanged non-interactively and out-of-band (e.g. in person, via personal websites, via social media, etc). It's more complicated in an interactive protocol. Commented Aug 13, 2022 at 8:21