After this lesson, you will be able to: Explain how Diffie-Hellman and ECDH let two parties agree on a shared secret over an insecure channel, and how digital signatures prove authenticity and integrity.
Two foundational uses of asymmetric math: agreeing on a shared secret without sending it, and signing data so anyone can verify who created it and that it is unchanged. This lesson covers Diffie-Hellman and ECDH key exchange and digital signatures (RSA and ECDSA).
Symmetric encryption needs both sides to share a key, but how do you share a key over a channel an attacker is watching? Diffie-Hellman solves this: both parties exchange public values, each combines the other's public value with their own private value, and they arrive at the same shared secret, which an eavesdropper cannot compute from the public values alone. The secret is never transmitted; it is independently derived on both ends.
Classic Diffie-Hellman works over large prime fields; ECDH (Elliptic Curve Diffie-Hellman) does the same over elliptic curves with smaller keys and better performance, so it dominates modern protocols. Ephemeral variants (DHE, ECDHE) generate fresh keys per session, providing forward secrecy: even if the server's long-term private key is later stolen, past sessions cannot be decrypted because their ephemeral keys are gone. TLS 1.3 mandates this.
A digital signature proves two things: authenticity (who created this) and integrity (it has not changed). The signer hashes the data and encrypts the hash with their private key; anyone can verify by decrypting the signature with the signer's public key and comparing it to their own hash of the data. RSA and ECDSA (and Ed25519) are the common signing algorithms. Signatures are how software updates, certificates, and signed commits prove their origin.
The pattern: hash, sign with private key, verify with public key.
// Signerconst hash = sha256(document);const signature = signWithPrivateKey(hash, signerPrivateKey);// distribute: document + signature + signerPublicKey (or a cert chain)// Verifierconst expected = sha256(document);const ok = verifyWithPublicKey(signature, expected, signerPublicKey);// ok === true -> authentic AND unmodified// ok === false -> wrong signer OR the document was tampered with
Pick one.
Confusing key exchange (agree on a secret) with encryption (use it). Using static (non-ephemeral) keys and losing forward secrecy. Signing the raw data without hashing first for large inputs. Verifying a signature but not checking the signer's certificate chain (a valid signature from the wrong key is worthless). Reusing nonces in ECDSA, which can leak the private key (the PlayStation 3 break). Assuming a signature provides confidentiality (it does not encrypt).
Sign in and purchase access to unlock this lesson.