Generate shared cryptographic keys using ECDH protocols.
When you connect to your bank's website using HTTPS, your browser and the bank's server need to encrypt data using a fast symmetric cipher like AES. But AES requires both sides to possess the exact same secret key. How do they agree on a secret key over the open Internet without a hacker intercepting it?
The solution is a mathematical magic trick called Elliptic Curve Diffie-Hellman (ECDH). The process works like this:
Due to the algebraic properties of Elliptic Curves, both parties will independently arrive at the exact same number (the Shared Secret). Even if a hacker intercepts both public keys in transit, they cannot calculate the shared secret without possessing at least one of the private keys.
The shared secret generated by ECDH is mathematically secure, but it is not uniformly random (it has structural bias). You must never use the raw ECDH output directly as an AES key.
Instead, the raw shared secret is passed through a Key Derivation Function (specifically HKDF) to "extract and expand" it into perfectly uniform cryptographic keys suitable for AES encryption.
ECDH solves the problem of eavesdropping, but it does not authenticate the parties. A hacker could intercept Party A's public key, swap it with their own, and do the same to Party B. Now the hacker has established two separate secure channels and can read everything!
This is why ECDH is always paired with Digital Signatures (like ECDSA or RSA). During the TLS handshake, the server signs its ECDH public key using the private key associated with its SSL certificate, proving its identity and neutralizing MITM attacks.
If Eve intercepts the public keys sent by both Alice and Bob during an ECDH exchange, what can she do?
