0
$\begingroup$

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?

$\endgroup$
1

1 Answer 1

3
$\begingroup$

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.

$\endgroup$
4
  • 1
    $\begingroup$ 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 $\endgroup$
    – abzzer
    Aug 11 at 15:30
  • 1
    $\begingroup$ In a nutshell, yes. $\endgroup$ Aug 11 at 15:59
  • 2
    $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes
    Aug 12 at 0:29
  • 1
    $\begingroup$ 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. $\endgroup$ Aug 13 at 8:21

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.