Randomness, and how TLS combines everything

Every lesson in this module has quietly leaned on one assumption: that a "randomly generated" key, nonce, or salt is actually unpredictable. Lesson 3's salts, lesson 4's IVs, lesson 7's ephemeral DH private values — all of them are only as strong as whatever produced them. If an attacker can predict or narrow down that value, every guarantee built on top collapses, no matter how sound the surrounding math is. So before the capstone synthesis, the last primitive: what makes a number generator actually safe to use for security, and what happens when it isn't.

The frame: cryptographic security depends entirely on unpredictability, which only a CSPRNG seeded from real entropy can provide — an ordinary PRNG is deterministic and must never be used for anything security-relevant — and once you have that randomness, the full TLS handshake is just this module's primitives, assembled in order.

Two kinds of "random," and only one is safe here

An ordinary pseudorandom number generator — Math.random() in JavaScript, or a classic Mersenne Twister — is deterministic. Give it the same seed and it produces the exact same sequence of outputs, every time. That's not a bug; it's the design, and it's exactly what you want for a game's procedural level generation or a Monte Carlo simulation you'd like to be reproducible. But determinism has a sharp edge: for many such generators, observing a handful of consecutive outputs is enough to reconstruct the internal state and predict every future output, without ever seeing the seed itself. Math.random() was never designed to resist this kind of analysis, because it was never designed for security in the first place.

A CSPRNG — cryptographically secure pseudorandom number generator — is built to a different, much stricter standard: even an attacker who has seen a large number of past outputs, and who knows the exact algorithm (Kerckhoffs's principle, lesson 1), still cannot predict the next output or recover the internal state, short of brute-forcing a search space too large to be practical. It achieves this by seeding itself from entropy — genuinely unpredictable physical noise the operating system collects from sources like hardware timing jitter, interrupt timing, and dedicated hardware random-number generators — and then stretching that entropy through a construction designed specifically to resist prediction.

// Wrong for anything security-relevant — deterministic, predictable.
const weakToken = Math.random().toString(36).slice(2);

// Right — backed by the OS CSPRNG, seeded from real entropy.
const strongToken = crypto.getRandomValues(new Uint8Array(16));
// 16 bytes = 128 bits of unpredictability, suitable for a session token,
// an AES key, or a nonce.

Everything in this module depends on this silently. A symmetric key (lesson 4) generated from a predictable source is a key an attacker can guess directly. A nonce or IV that repeats — because the generator that produced it has a short predictable cycle — can break the confidentiality of an entire AEAD scheme (lesson 4) outright. A salt (lesson 3) that's guessable defeats the entire point of salting. An ephemeral DH private value (lesson 7) that an attacker can narrow down lets them compute the shared secret directly, skipping the discrete-logarithm problem entirely. Real-world breaks bear this out again and again: biased or flawed RNGs in embedded devices that let attackers factor "random" RSA keys, nonce reuse in signature schemes that directly leaked private keys, low-entropy seeds at boot time on cloud instances that produced guessable keys across thousands of machines. The primitive here isn't glamorous, but weak randomness has broken more real systems than broken math ever has.

The synthesis: the TLS handshake is this whole module

Here's the payoff for having done all seven other lessons. The TLS handshake isn't a separate, exotic protocol — it's every primitive from this module, called in a specific order, each doing the one job it's suited for.

Walk it primitive by primitive:

• Secure randomness (lesson 8) generates every random value before anything else happens — the ephemeral ECDHE private values, session nonces, everything downstream depends on these being unpredictable.
• Key exchange (lesson 7) — ECDHE lets client and server derive an identical shared secret in full view of any eavesdropper, and because the keys are ephemeral, the session gets forward secrecy: a future compromise of the server's long-term key cannot decrypt this recorded session later.
• Public-key cryptography and certificates (lesson 5) give the server a key pair and a certificate binding its public key to its domain, issued by a CA the client already trusts.
• Digital signatures (lesson 6) are what CertificateVerify actually is: the server signs a hash of the handshake transcript — which includes both ECDHE key shares — with its private key, so an attacker who tried to substitute their own key share during a man-in-the-middle attempt cannot produce a valid signature over a transcript containing it. This is exactly the authentication gap lesson 7 said key exchange needed, closed.
• Hash functions (lesson 2) turn the raw shared secret from the key exchange into the actual symmetric keys used for the session, and underlie the signature in CertificateVerify itself (sign the hash, not the raw transcript — lesson 6).
• MACs (lesson 6) protect the handshake transcript itself: the Finished messages on both sides are authentication tags over everything exchanged so far, so any tampering with the earlier plaintext parts of the handshake is caught before a single byte of real data flows.
• Symmetric AEAD encryption (lesson 4) takes over the instant the handshake completes — AES-GCM protects every byte of actual application data, fast enough for bulk traffic, bundling confidentiality and integrity into every record.

Every family from lesson 1's map appears exactly once, each doing the one job it's good at, in an order that makes the whole thing work in a single round trip. Nothing about TLS is a new idea at this point — it's this module's table of contents, executed.

The module, end to end

Zooming out one more level: this module started by insisting that "encrypt it" is not a security strategy, and that confidentiality, integrity, and authenticity are three separate, precisely delivered guarantees. Hash functions gave a one-way fingerprint for integrity. Password hashing showed why a fast hash breaks under a stolen-database attack, and what slow, salted key derivation fixes. Symmetric encryption gave fast, authenticated bulk confidentiality. Public-key cryptography solved the problem of two strangers needing keys without a pre-shared secret. MACs and signatures added authenticity and, where it matters, non-repudiation. Key exchange showed how two strangers derive a shared secret over an open channel, and why that exchange needs binding to a verified identity. And randomness, here, turned out to be the quiet dependency underneath every one of those keys the whole time.

None of these primitives is exotic once you've seen the guarantee it delivers and the mistake it prevents. What made cryptography feel opaque at the start of lesson 1 was never the individual pieces — it was not having the map. You have it now, and the TLS lesson in the networking track is this exact map, seen from the wire instead of from the primitives — worth rereading now that every piece in it has a name and a reason.

That's also where this module rejoins the wider curriculum. TLS sits underneath what happens when you fetch, which sits underneath every request this site's networking track has walked through — cryptography was never a side topic to that track, just the box it deferred opening until now.