Network security: Diffie-Hellman, certificates and TLS
Goals of security, symmetric cryptography, Diffie-Hellman exchange with proof and example, the man in the middle, hashes, signatures and certificates, TLS 1.3 and forward secrecy, firewalls, VPNs and DDoS.
The Internet was designed by researchers who trusted one another: no original protocol encrypted data or verified who sent it. Today security is part of every layer. In this lesson we look at the goals of security, symmetric and public-key cryptography, Diffie-Hellman key exchange with the proof and a numerical example, the man-in-the-middle attack and certificates, hash functions and signatures, the TLS protocol, and network defences: firewalls, VPNs and protection against denial-of-service attacks.
The goals
- Confidentiality: only the recipient can read the message.
- Integrity: the message has not been modified.
- Authentication: it is known who sent it.
- Availability: the service stays reachable even under attack.
The typical attacker can read, modify, delete and insert packets along the path: anyone controlling a public Wi-Fi network, a router or a link can do it.
Symmetric cryptography
Sender and recipient share a secret key
, used both to encrypt and to decrypt. The standard algorithm is AES, with 128- or 256-bit keys: trying all
keys would take all the computers in the world vastly longer than the age of the universe. It is fast (processors have dedicated instructions and encrypt tens of gigabits per second) but it has a fundamental problem: how do two parties agree on the key if they have never met, communicating over a network the attacker is listening to?
Diffie-Hellman key exchange
In 1976 Whitfield Diffie and Martin Hellman showed that it is possible. A large prime
and a number
are chosen publicly. A chooses a secret
and sends
; B chooses a secret
and sends
.

Theorem. A and B obtain the same key:
.
Proof. Arithmetic modulo
preserves products and powers: if
then
. So
and
, and the two quantities coincide. ∎
Example with small numbers. With
,
,
,
: A sends
, B sends
. A computes
, B computes
: the common key is 2. The attacker sees
,
, 8 and 19, but to obtain the key would have to find
from
: the discrete logarithm, which for 2048-bit primes (or, with elliptic curves, at 256 bits) nobody knows how to solve in reasonable time.
The man in the middle and certificates
Diffie-Hellman alone does not say with whom one is talking. An attacker on the path can do one exchange with A pretending to be B and another with B pretending to be A, and then read and relay everything: the man-in-the-middle attack. Authentication is needed.
Public-key cryptography (RSA, elliptic curves) uses key pairs: the public key is known to everyone, the private key only to its owner. What is signed with the private key is verified with the public one. A digital signature is computed on the digest of the message produced by a cryptographic hash function (SHA-256): a function that produces 256 bits from any message, such that it is impractical to find two messages with the same digest. Changing a single bit of the message changes the digest completely, and the signature no longer checks out.
But how does one know that a public key really belongs to the bank’s site? A certificate guarantees it: a document binding the site’s name to its public key, signed by a certification authority, whose public key is already installed in the browser and the operating system. This is the chain of trust of the PKI (public key infrastructure).
TLS
The TLS protocol (the “S” in HTTPS) puts all the pieces together. In version 1.3, in a single round trip: client and server perform an elliptic-curve Diffie-Hellman exchange, the server sends its certificate and signs the exchange with its private key (so the client knows it is talking to the right site and not to a man in the middle), and from the common key the symmetric AES keys are derived, with which all subsequent data is encrypted and authenticated. Because the session keys come from an ephemeral exchange, even someone who stole the server’s private key in the future could not decrypt traffic recorded today: this is forward secrecy.
Network defences
- Firewalls: filter traffic by addresses, ports and connection state, for instance allowing in from outside only replies to connections opened from inside. Next-generation ones also inspect application content.
- VPNs: create an encrypted tunnel (IPsec, WireGuard) between two networks or between an employee and the company, across the Internet.
- Intrusion detection (IDS): looks in the traffic for the signatures of known attacks or for anomalous behaviour.
- Distributed denial of service (DDoS): millions of compromised devices, often cameras and home routers, flood a target with traffic, up to terabits per second. Defences are very large distribution networks that absorb the traffic, filters at the operators, and per-source rate limiting with the token buckets of the lesson on quality of service.





