Public values combine with private inputs

In a common finite-field form, parties agree on suitable p and generator g, choose secret a and b, and exchange g^a mod p and g^b mod p. Each applies its private exponent to the other value, obtaining g^(ab) mod p.

Agreement follows from the group operation rather than directly sending a common password. Parameters and exchanged values can be public; suitable choices and assumptions must make reconstructing the shared secret infeasible to an observer.

References: [1] [2]

Suitable groups and derivation matter

Different groups can support the agreement pattern; ECDH uses elliptic-curve group operations. It shares the goal with finite-field DH but has different parameters, encodings and input handling, so changing one formula symbol does not establish interoperability.

The raw result need not be an application key directly. A protocol specifies derivation, context binding and invalid-input handling. RFC 7748 gives separate X25519 and X448 forms and discusses special inputs and shared-result qualifications.

References: [2] [3]

Agreement does not authenticate the peer

Unauthenticated exchange does not prevent a middle party from establishing separate secrets with each endpoint. The protocol must authenticate the exchanged values and intended parties; possession of some shared secret alone does not establish who participated.

Fresh ephemeral material and appropriate erasure can support forward secrecy against later long-term-key compromise, unlike assuming every static-DH use has it. TLS 1.3 combines exchange, handshake authentication and derivation, with guarantees depending on the actual mode.

References: [2] [4]