Is a KDF needed when using X25519 for ECDH and XChaCha20-Poly1305 for AEAD?

Question

Is a KDF needed when using X25519 for ECDH and XChaCha20-Poly1305 or XSalsa20-Poly1305 for authenticated encryption?

My hypothesis is "no" because the key from X25519 is less than 256 bits long; therefore, it can be used in XChaCha20-Poly1305 directly, as ChaCha20 is considered immune to related-key attacks.

Answer 1

Generally speaking, there are (at least) three reasons to put a KDF in between an DH shared secret and the bulk encryption.

1. Improved re-usability. If you don't post-process the shared secret with a KDF there's no way to give the sender and the recipient different keys for each direction or to split up authentication and encryption keys. An additional bonus would be, that if you keep the shared secret, you could easily implement a session resumption feature by increasing some helper counter which is fed into the KDF.
2. Weaker security reduction assumptions. If you feed the shared secret into a KDF, then you only rely on the CDH problem holding (and model the KDF as a random oracle). If you feed the key directly into a cipher, you rely on the DDH assumption which is known to be broken for some groups where the CDH holds.
3. Better match with expected key properties. Symmetric ciphers are constructed, modeled and analyzed with only fully random keys in mind (or some computationally indistinguishable variant). However DH and ECDH shared secrets are integers and curve points which exhibit structure which violates the randomness assumption. A quick pass through a KDF doesn't cost much and fixes this.

---

_{Glossary: KDF: key derivation function; CDH: computational diffie-hellman problem; DDH: decisional diffie-hellman problem; DH: diffie-hellman; shared secret: result of a DH key agreement protocol execution; ECDH: elliptic curve variant of diffie-hellman}