Encryption: From Secret Keys to TLS

Encryption: From Secret Keys to TLS

What you'll learn

• Contrast symmetric and asymmetric encryption — and retell the classic car-keys analogy that separates them
• Tell the DES → 3DES → AES story as the lesson it really is: ciphers age one way
• Explain key agreement (the Diffie-Hellman idea) with a clean story and no hand-waving
• Follow a TLS 1.3 handshake at high level, and read a certificate's chain of trust
• Say what Let's Encrypt changed about the web — and what Kerberos does inside organizations

Scrambling by rule: what encryption is

This lesson builds on Chapter 15 of Dr. Tahseen Al-Doori's Network Essentials, whose cryptography teaching begins exactly where every good one does: with a scramble simple enough to do in your head. Take a word — say NET — and shift every letter two places forward in the alphabet: PGV. That is encryption: applying an algorithm (shift letters forward) with a key (two) to turn readable plaintext into unreadable ciphertext. Undoing it — shift two back — is decryption, and it works only if you know both the method and the key. This toy shift cipher would not resist a bored child for long, but it already contains the whole anatomy: algorithm plus key, scramble and unscramble. Real ciphers differ in strength, not in shape — and encryption is what the confidentiality of lesson 1's data states is made of.

Symmetric encryption: one key, both directions

When the same key encrypts and decrypts — as with our shift-by-two — the scheme is symmetric. A classic analogy from Dr. Al-Doori's course compares it to a shared car: two people hold identical keys to one vehicle, and either can lock or unlock it at will. The car is the data; the matching keys are the shared secret; and — the analogy's quiet warning — you would never leave a key hanging in the door for passers-by, because anyone holding that key holds everything.

Symmetric ciphers are the workhorses of encryption: fast, efficient, ideal for bulk data — whole disks, whole video streams, whole conversations. The current standard is AES (Advanced Encryption Standard, current) — adopted in 2001, typically with 128- or 256-bit keys, so central that modern CPUs carry dedicated instructions to accelerate it. When lesson 1 said "encrypt the disk," it meant AES; when Module 6 configured WPA3, AES was doing the lifting.

But symmetric encryption smuggles in a hard problem. The key must be shared — both ends need it — yet it must never travel where an eavesdropper could copy it. Installing it separately at each end works for two offices and a courier; it collapses on an Internet where your browser talks to servers it has never met and will never meet again. This is the key distribution problem, and holding it in mind makes the rest of this lesson feel inevitable.

How ciphers age: the DES → 3DES → AES story

Before solving key distribution, a story the book started — this course finishes it, because its ending carries this module's most repeatable lesson.

DES (Data Encryption Standard) was the US-standard symmetric cipher of the late 1970s, with a 56-bit key. Is 56 bits a lot? The book teaches the arithmetic beautifully, and it deserves preserving: every added key bit doubles the number of possible keys. Thirty-two bits give about 4.3 billion possibilities (Module 4 taught you exactly why); each further doubling compounds, and 2^56 lands around 72 quadrillion. In 1977 that was a wall. But attackers' budgets compound too: computing power kept doubling on its own schedule, and by 1998 a purpose-built machine cracked a DES key by brute force in days — the wall had become a fence. The stopgap was 3DES (Triple DES): run DES three times with multiple keys. The book presents DES's 56 bits alongside 3DES at 168 and calls 3DES the best choice for high-level security — and here is the kind correction with its dates: true advice in its day, wrong advice now. 3DES was slow, its effective strength sat well below its nominal 168 bits, and research kept eroding it; NIST formally disallowed 3DES for encryption after the end of 2023 and withdrew its specification. AES — chosen by open international competition, standardized in 2001 — is the successor in every current protocol: DES (obsolete), 3DES (obsolete — retired by NIST), AES (current).

The repeatable lesson: ciphers age in one direction. Attacks only improve; computers only accelerate; no cipher recovers strength. "Best available" is a timestamped claim, and part of a professional's job is knowing today's date. You will watch this exact pattern replay with VPN protocols in lesson 5.

Asymmetric encryption: a key pair, split powers

Now the escape from key distribution. Asymmetric encryption uses a key pair — two keys, mathematically linked, generated together: what one encrypts, only the other decrypts. One is published to the world (the public key); its partner never leaves your machine (the private key). Anyone can encrypt a message to you with your public key — and only you can read it, because only your private key undoes it. Nothing secret ever had to be pre-shared.

The book extends its car analogy to cover the split, and the upgrade is worth retelling: imagine the shared car gains an electronic door lock. The engine key is still the old symmetric kind — both drivers hold copies. But the door now opens only to each driver's personal electronic fob, unique per person and never duplicated. You could hand engine keys to strangers without fear: without a door fob, an engine key starts nothing. Separate keys, separate powers — the asymmetric idea in a parking lot.

The pair does a second job that matters just as much, and it is worth stating carefully because a popular shortcut gets it wrong. Your private key can sign: it runs a signing operation over your message (in practice, over a hash of it) and produces a short digital signature. Anyone holding your public key can then verify that signature — confirming the message came from the holder of the private key and has not been altered since.

Notice what signing is not. You will often hear it described as "encrypting with the private key." That picture happens to work for one algorithm family (RSA) and fails for the ones the modern web actually leans on — ECDSA and Ed25519 have signing and verification operations but no encryption operation at all. So keep the vocabulary precise: private key signs, public key verifies. And note what a signature gives you: integrity and authenticity — proof of who and unaltered. It gives you no confidentiality whatsoever; a signed message is still readable by everyone. Secrecy comes from encryption, which is a separate job.

Why not encrypt everything asymmetrically and retire key distribution forever? Cost: asymmetric operations are dramatically slower — fine for small payloads, hopeless for gigabytes. So every serious protocol is a hybrid: asymmetric techniques establish a small shared secret, then fast symmetric AES carries the actual data. Keep that sentence; it is the skeleton key to TLS below.

Agreeing on a secret in public: the key-agreement idea

The subtlest piece is how two strangers establish that shared secret while an eavesdropper reads every message between them. The mathematics is Diffie-Hellman key agreement, and the book — which rightly calls this family of ideas foundational to modern cryptography — offers a walk-through that, in compressing the story, lets the roles of the keys blur into one another (its own note concedes the summary does not do the algorithm justice). So here is the clean version this course teaches, told with paint.

Two people, Aya and Basil, want a secret color that only they know — negotiated entirely by public courier.

1. They openly agree on a common starting paint — say, yellow. The eavesdropper sees this; it is public by design.
2. Each privately picks a secret color and tells no one — Aya red, Basil blue. These never travel anywhere.
3. Each mixes their secret into the common yellow and sends the mixture across: Aya ships orange, Basil ships green. The eavesdropper sees both mixtures.
4. Each now mixes their own secret into the mixture they received. Aya adds red to green; Basil adds blue to orange. Both arrive at the same final color — yellow + red + blue — a shared secret neither ever transmitted.

The eavesdropper holds yellow, orange and green — but paint does not un-mix: recovering "red" from "orange minus yellow" is impractical, and without a secret ingredient the final color is out of reach. Diffie-Hellman is this story with numbers: the common paint is a set of public parameters, the secret colors are large private values, the mixtures are the public values exchanged, and "mixing" is mathematics easy to perform and infeasible to reverse. Three properties to hold onto, because they are exactly where compressed retellings go wrong: the shared secret is derived at each end, never sent; the private values are never encrypted and transmitted — they simply never leave home; and the wire carries only material that is safe to reveal. The agreed secret then becomes the symmetric session key — the hybrid model's opening move. Modern protocols run the agreement with fresh values per conversation (ephemeral Diffie-Hellman), buying a bonus called forward secrecy: even a private key stolen next year cannot decrypt conversations recorded today.

TLS 1.3: the handshake that runs the web

Now assemble everything into the protocol securing most Internet traffic: TLS (Transport Layer Security — successor to the SSL you may still hear it miscalled). When your browser opens an https:// page, a handshake runs before any page data flows. In TLS 1.3 (current), at high level:

1. Client hello. Your browser sends the cipher suites it supports and its key-agreement share — its "mixture," in paint terms, sent optimistically up front.
2. Server hello. The server replies with its own key-agreement share and its chosen cipher — the last thing to cross the wire in the clear.
3. Both derive the keys. Each side completes the key agreement; identical session keys now exist at both ends, never having crossed the wire.
4. Identity is proven — under encryption. Now protected by those fresh keys, the server sends its certificate and a digital signature only its private key could produce; the browser checks the certificate against its chain of trust (next section). Encrypting the certificate is a TLS 1.3 improvement in its own right: an eavesdropper no longer learns which certificate — and often which site — you were served.
5. Encrypted data flows, carried by a symmetric AEAD cipher under the agreed keys — an AES-based suite (AES-GCM or AES-CCM) or ChaCha20-Poly1305, which many phones and low-power devices prefer because it is fast without dedicated AES hardware.

One round trip, then ciphertext. Three notes worth keeping straight. Versions: TLS 1.3 (2018, RFC 8446) is the current standard, 1.2 the maintained floor, everything older deprecated. Key exchange: TLS 1.3 removed the old RSA key-transport style, in which the client encrypted a secret to the server's public key and forward secrecy was lost if that key later leaked. The handshake above — certificate-authenticated ephemeral (EC)DHE — is what the public web runs, and it is the one to learn. The standard does define two further modes for resumed or pre-shared-key sessions (PSK alone, and PSK combined with (EC)DHE), so "every TLS 1.3 connection performs a fresh Diffie-Hellman" would be too strong a claim: a resumed session may skip it. What is safe to say is that the ordinary certificate-authenticated handshake to a public website uses ephemeral key agreement, which is why forward secrecy is now the norm rather than an option.

Certificates: why you trust a server you've never met

The handshake encrypts brilliantly — but encrypted-to-whom? Key agreement with an impostor yields a perfectly private conversation with the wrong party. Identity is the missing piece, and it is solved by PKI (public key infrastructure), exactly as the book describes: trusted third parties vouching for public keys.

A certificate is a signed statement binding a name to a public key: "this domain is served by the holder of this key — signed, a certificate authority (CA)." Inside one: the subject (the domain), the public key, the issuer, a validity window, and the issuer's signature. Trust flows down a chain: your operating system and browser ship with a short list of root CAs trusted unconditionally; roots sign intermediate CAs; intermediates sign the leaf certificates servers actually present. Your browser walks the chain upward — leaf, intermediate, root — verifying each signature (asymmetric proof, exactly as above) until it reaches a root it already knows. Any broken link — expired, revoked, wrong name, unknown root — and you get the full-page warning instead of the padlock.

The book's era priced certificates as commercial products from vendors like Verisign and Entrust — modest fees, real friction, a web where HTTPS was for banks and checkouts. The 2026 update is one of the happiest in this course: Let's Encrypt (from 2015) issues certificates free, and the ACME protocol automates issuance and renewal entirely — servers fetch and renew their own short-lived certificates with no human in the loop. Encrypted connections went from special-occasion to default; the padlock is now so universal that browsers instead warn about its absence. You will hold real chains in your hands in this lesson's lab.

Kerberos: the three-sentence pointer

One more name from Chapter 15, properly a bridge to the next lesson. Kerberos is a symmetric-key authentication system for inside organizations: sign in once, receive a cryptographic ticket from a central authority, and present that ticket to file servers, printers and applications without retyping a password at each — single sign-on, with passwords that stop crossing the network. It remains the backbone of Windows domain logins today, and it returns next lesson, where authentication takes center stage.

From the textbook to 2026

Chapter 15's pedagogy holds: the shift-cipher on-ramp, the car-keys analogy, symmetric versus asymmetric, key-agreement as the foundation, PKI as trust outsourced to authorities — all preserved above. Three renovations were needed: the cipher roster (DES/3DES praised then, formally retired since — AES everywhere now); the key-agreement walk-through (retold cleanly, with each key's role kept distinct); and the certificate economy (from priced product to free automated infrastructure via Let's Encrypt/ACME, with TLS 1.3 as the current handshake). The deep structure — hybrid encryption, chains of trust — the book had exactly right.

Watch: Encryption — Symmetric vs Asymmetric

Why this video earns its place. Ed Harmoush's Practical Networking channel is one of the most respected TLS-teaching sources online, and this lesson from his Practical TLS course draws the symmetric/asymmetric distinction with the visual patience text cannot match — keys moving between parties, the same-key and paired-key models side by side, and the reasoning that leads straight to hybrid encryption. You have just read that whole argument; watching it move will set it.

As you watch, notice:

• The same-key model and its distribution problem — the shared car and its courier, animated.
• What one key of a pair can undo and the other cannot — the door fob and engine key, made precise.
• Why asymmetric operations are reserved for small payloads — the cost argument behind every hybrid design.
• The hybrid conclusion — asymmetric to establish, symmetric to carry — which is TLS's skeleton, as the handshake section showed.
• The course context: it is a TLS-course lesson, so framing leans toward TLS throughout — convenient, since that is precisely where this module applies it. Any incidental protocol-version remarks reflect its recording era; the current state (TLS 1.3 dominant, RSA key exchange retired from it) is in the sections above.

The video reinforces visually what you just learned — the lesson is complete without it.

Lab: Reading a real certificate chain

Every HTTPS page you visit presents the chain this lesson described. Time to inspect one — no tools to install; your browser has carried a certificate viewer all along.

Objective. Inspect two real sites' certificate chains; record issuer, validity window, key type and chain structure; recognize what normal looks like.

Setup. Any desktop browser (steps below for Chrome and Firefox). A notes file with a five-row table per site: Subject · Issuer · Valid from/to · Key type · Chain (leaf → intermediate → root).

Steps.

1. Visit a major site (your bank, a large retailer) over https://.
2. Open the certificate viewer. Chrome: click the icon at the left of the address bar → Connection is secure → Certificate is valid (the viewer opens with General and Details tabs). Firefox: click the padlock → Connection secure → More information → View Certificate. (Browser menus shift between versions — if a step is missing, the viewer is also reachable via the page-information or developer-tools security panel; searching the browser's own settings for "certificate" finds it.)
3. Record the subject (which domain is this certificate for? — the viewer may list alternative names too: one certificate can cover several hostnames).
4. Record the issuer — the CA vouching for the site — and the validity window. Note its length; you will compare in step 7.
5. Record the key type — typically ECDSA with the P-256 curve, or RSA at 2048 bits. Both are current practice; ECDSA is the newer, smaller-key style.
6. Walk the chain in the viewer: leaf (the site) → intermediate CA → root. Note the root's name — then reflect that your trust in this site is really trust in that root, pre-installed in your browser's store.
7. Repeat for a small site — a personal blog, a small business. There is a good chance its issuer is Let's Encrypt: note the validity window. Let's Encrypt certificates run about 90 days — a length only automation makes livable — and commercial certificates used to run about a year. Since 15 March 2026 the CA/Browser Forum caps any publicly trusted certificate at 200 days, falling to 100 days in 2027 and 47 days in 2029, so expect both of your certificates to be short-lived; the gap between them is closing.
8. Write two sentences: what differed between the two chains, and what was identical in shape.

Expected result. Two completed tables; two chains, both ending at a root your browser already trusted; a visible contrast in issuer and validity length between the commercial and automated worlds.

Verify. You can explain each recorded field to a colleague — and answer their "so why do you trust this site?" with the chain, not with the padlock icon.

Questions.

1. Your notes show the leaf's issuer is not in your browser's root store, yet the connection shows secure. Reconcile.
2. Both certificates are short-lived — the Let's Encrypt one under three months, the commercial one now capped at 200 days. Why are short lifetimes a security feature, what makes them practical, and why did the industry make them mandatory rather than optional?
3. On a workplace machine, the issuer for every site — bank included — shows your employer's own name. What are you looking at?

(Answers: 1 — trust is a chain, not a lookup: the leaf's issuer is an intermediate CA, itself signed by a trusted root; the browser walks leaf → intermediate → root and needs only the chain's top to be pre-trusted. 2 — a shorter life shrinks the window in which a stolen or mis-issued certificate stays usable and forces fresh validation often; ACME automation makes renewal free and unattended, so the short life costs nothing. 3 — corporate TLS interception: the company's gateway decrypts and re-encrypts traffic for inspection, presenting certificates signed by a company CA installed on your machine. The mechanism is chain-of-trust working exactly as designed — with an extra root your employer added; know that it means your employer's gateway, not just your browser, can read that traffic.)

If it goes wrong.

• No padlock or certificate option at all. The page is plain HTTP — no TLS, nothing to inspect. Try another site (increasingly hard to find, which is itself this lesson's point).
• The viewer's menu path doesn't match. Versions move furniture; use the browser's page-information panel or search its settings for "certificate."
• A security-product name (or your antivirus) appears as issuer at home. Some antivirus suites intercept TLS locally the same way corporate gateways do — same explanation as question 3, one machine smaller.
• A full-page certificate warning appears during unrelated browsing. Do not click through it; that warning is the chain-walk failing — the protection working. Note which check failed (expired? name mismatch? unknown issuer?) and be glad you saw one in the wild.

Reset/cleanup. Nothing changed on your machine. Keep the two tables; the capstone's security review asks you to check certificates on your own design's services.

Check yourself

1. A startup wants to encrypt nightly 200 GB database backups and asks whether to use "RSA, since asymmetric is the strong kind." Set them straight — what does each family actually do best, and what design should they use?

2. A vendor proposal, dusted off from an old template, specifies 3DES "for maximum security." Draft the two-sentence correction, dates included, in a tone your grandmother would approve of.

3. In the paint story, list what the eavesdropper possesses at the end — then name the two things they lack, and match each paint element to its cryptographic role.

4. Read this authored certificate summary and answer below:

   codeCopy

   Subject:     shop.harborlane.example
   Issuer:      R11 (Let's Encrypt)
   Valid from:  2026-06-14
   Valid to:    2026-09-12
   Key type:    ECDSA P-256
   

   Who is vouching for the site? What does the validity length suggest about how this certificate is managed? What breaks on the day after expiry if renewal fails?

5. TLS 1.3 removed the option of the client encrypting a secret to the server's long-term public key, requiring ephemeral key agreement instead. What property did that buy, and what recorded-traffic scenario does it protect against?

6. Why does a Windows domain use Kerberos tickets rather than sending your password to each file server you open?

Answers

1. Backwards on both counts: asymmetric encryption is not "stronger," it is slower — suited to small payloads like establishing keys and signing, hopeless for bulk. Bulk data is symmetric AES territory. The right design is the hybrid every real protocol uses: agree or share a key via asymmetric techniques (or install it securely once, for a fixed backup pipeline), then AES for the 200 GB.
2. "3DES was respectable advice when that template was written, but NIST disallowed it for encryption after the end of 2023 and withdrew its specification; AES has been the standard since 2001. Updating the spec to AES brings it in line with every current protocol." Correct, dated, and nobody bruised.
3. The eavesdropper holds the common paint (public parameters) and both transmitted mixtures (public key-agreement values). They lack the two private colors (the secret values, which never traveled) — and therefore the final blend (the shared secret, derived at each end and never sent), which becomes the symmetric session key.
4. Let's Encrypt (via its R11 intermediate) vouches. The roughly 90-day window signals ACME automation — no human renews certificates that often by hand. On failure-day-plus-one, browsers refuse the connection with a full-page expiry warning: the chain-walk fails on the validity check, and visitors are turned away at the door.
5. Forward secrecy: session keys derive from ephemeral values discarded after each conversation, so even the server's long-term private key, stolen later, cannot decrypt traffic an adversary recorded earlier. It protects against record-now-decrypt-later collection.
6. Kerberos issues a ticket after one sign-in; the ticket — not the password — is presented to each service. Passwords stop crossing the network repeatedly and stop being handled by every server, shrinking both interception and mishandling exposure. Single sign-on is the convenience; the security is in what no longer travels.

Key terms

• Encryption / decryption — transforming plaintext to ciphertext by algorithm plus key, and back.
• Symmetric encryption — one shared key both ways; fast, bulk-capable. Standard: AES (current).
• DES / 3DES — the retired generations (obsolete): DES's 56 bits fell to compute; 3DES disallowed by NIST after 2023.
• Key distribution problem — the shared key must reach both ends without ever being exposed; the reason asymmetric crypto exists.
• Asymmetric encryption — a linked key pair with split powers: public key published, private key never leaves home.
• Digital signature — produced by a signing operation with the private key and checked by a verification operation with the public key; proves authorship and integrity, provides no confidentiality. Not "encryption in reverse".
• Diffie-Hellman key agreement — deriving a shared secret from exchanged public values plus never-transmitted private ones; the paint-mixing mathematics.
• Forward secrecy — fresh ephemeral agreement per session, so later key theft cannot unlock recorded traffic.
• Hybrid encryption — asymmetric to establish keys, symmetric to carry data; the design of every serious protocol.
• TLS / handshake — the web's security layer and its opening negotiation; TLS 1.3 (current) agrees keys and proves identity in one round trip.
• Certificate / CA / chain of trust — a signed name-to-key binding; the authority that signs it; the leaf → intermediate → root path ending in your browser's root store.
• Let's Encrypt / ACME — free certificates and the automation protocol that made HTTPS the default web (current).
• Kerberos — symmetric-key ticket-based single sign-on inside organizations; Windows domains' backbone.

Summary

• Encryption is algorithm plus key; symmetric schemes (AES today) share one key and carry the world's bulk data; their weakness is getting that key to both ends unseen.
• Ciphers age one way: DES's 56 bits fell to compute, 3DES bridged and was retired (disallowed after 2023), AES reigns — "best available" always carries a date.
• Asymmetric key pairs split powers: public key encrypts and verifies, private key decrypts and signs — signing is its own operation, not "encrypting backwards", and it proves authorship without hiding anything. Slow, so real systems are hybrids.
• Key agreement lets strangers derive a shared secret in public — private values never travel, the secret is computed at each end, and ephemeral use adds forward secrecy.
• TLS 1.3 runs the hybrid play in one round trip: shares exchanged, keys derived, identity proven by certificate — then AES-family ciphers carry the data.
• Certificates chain leaf → intermediate → root; Let's Encrypt and ACME made them free and automatic, turning HTTPS from exception to default.
• Kerberos applies symmetric tickets to in-house single sign-on — your bridge to next lesson, where identity takes the stage.

Next lesson

Encryption keeps conversations private, but the harder question is who's talking: authentication. AAA and the CIA triad, the three factors, the quiet death of forced password expiry, passkeys — and which access-control model fits which office.

Sources and further study

• Al-Doori, T., Network Essentials, Chapter 15 — the shift-cipher on-ramp, car-keys analogy, key-agreement and PKI foundations this lesson extends and refreshes.
• Cloudflare Learning Center, "What happens in a TLS handshake?" — https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/ — a clear step-through consistent with this lesson's high-level walk.
• Let's Encrypt, "How It Works" — https://letsencrypt.org/how-it-works/ — the ACME automation story from the source.
• NIST SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths — https://csrc.nist.gov/pubs/sp/800/131/a/r2/final — the table that deprecates three-key 3DES for encryption through 2023 and disallows it after.
• NIST SP 800-67 Rev. 2 (withdrawn 1 January 2024) — https://csrc.nist.gov/pubs/sp/800/67/r2/final — the 3DES specification itself, and its withdrawal notice.
• Practical Networking, Cryptography series — https://www.practicalnetworking.net/series/cryptography/ — the written companion to this lesson's video, by its author.