Elliptic curve Diffie–Hellman

Key establishment protocol

The following example will illustrate how a key establishment is made. Suppose Alice wants to establish a shared key with Bob, but the only channel available for them may be eavesdropped by a third party. Initially, the domain parameters (that is, ( p , a , b , G , n , h ) in the prime case or ( m , f ( x ) , a , b , G , n , h ) in the binary case) must be agreed upon. Also, each party must have a key pair suitable for elliptic curve cryptography, consisting of a private key d (a randomly selected integer in the interval [ 1 , n − 1 ] ) and a public key Q (where Q = d G , that is, the result of adding G together d times). Let Alice's key pair be ( d A , Q A ) and Bob's key pair be ( d B , Q B ) . Each party must know the other party's public key prior to execution of the protocol.

Alice computes ( x k , y k ) = d A Q B . Bob computes ( x k , y k ) = d B Q A . The shared secret is x k (the x coordinate of the point). Most standardized protocols based on ECDH derived a symmetric key from x k using some hash-based key derivation function.

The shared secret calculated by both parties is equal, because d A Q B = d A d B G = d B d A G = d B Q A .

The only information about her private key that Alice initially exposes is her public key. So, no party other than Alice can determine Alice's private key, unless that party can solve the elliptic curve discrete logarithm problem. Bob's private key is similarly secure. No party other than Alice or Bob can compute the shared secret, unless that party can solve the elliptic curve Diffie–Hellman problem.

The public keys are either static (and trusted, say via a certificate) or ephemeral (shortcut ECDHE). Ephemeral keys are temporary and not necessarily authenticated, so if authentication is desired, authenticity assurances must be obtained by other means. Authentication is necessary to avoid man-in-the-middle attacks. If one of Alice or Bob's public key is static then man-in-the-middle attacks are thwarted. Static public keys provide neither forward secrecy nor key-compromise impersonation resilience, among other advanced security properties. Holders of static private keys should validate the other public key, and should apply a secure key derivation function to the raw Diffie–Hellman shared secret to avoid leaking information about the static private key. For schemes with other security properties, see MQV.

While the shared secret may be used directly as a key, it is often desirable to hash the secret to remove weak bits due to the Diffie–Hellman exchange.

Software