When you pushed to GitHub, the URL said https — and your repo
crossed the public internet unread by every router along the
way. The page you are reading right now is served the same way,
and the padlock in your address bar is the thing this lesson
explains. Today: how a secret crosses an open network twice, why
two keys are better than one, and the one math fact protecting
everything you own.
In this lesson you will be able to answer“how do I keep a message secret in transit?”
Break It Down~10 min
A message has to cross a network anybody can listen to, and arrive readable by exactly one person. "Keep it secret" is a wish; the work is the five decisions underneath it.
First, before anything else: cut that into parts small enough that you could look each one up on its own.
The split is the whole lesson, because "keep it secret" is a wish and these five are decisions. Three of them are choices you make before a single byte moves — which lock, how many bits, what the certificate has to prove — and they are the three the exam asks about. The last one is the one everybody skips: knowing what the mechanism does NOT cover is what stops you trusting a green padlock further than it can carry you.
The test: could you answer this part out loud, in one sentence, with no computer in front of you? "Use encryption" points at nothing. "Find out whose public key this is" points at a certificate you can open and read field by field.
Your turn
Pick two of the parts above and say in one line what each one actually does.
Your own course site is served over HTTPS, and the subject of its certificate is not the address you typed. What is the browser actually matching against the host name — and does that certificate tell you anything about whether the site is honest?
TLS protects the channel, not the endpoints. Your game sends a high score to a leaderboard over HTTPS: name two things an attacker can still do even though the padlock is green.
Concept Lab~15 min
Symmetric — one shared key. The Caesar
cipher you probably did in elementary school: shift letters by
a key (3: CAT → FDW). Same key encrypts and decrypts. Fast,
simple, and cursed by one problem: to agree on the key, you must
already have a secure channel. The internet never had one, and
that is the whole reason symmetric encryption could not be the
answer on its own.
Asymmetric — two keys, a public pair. In
the 1970s, math (huge prime numbers) delivered the miracle: you
publish a PUBLIC key anyone can use to lock messages to you,
and keep a PRIVATE key that is the only thing that unlocks
them. Publishing the lock does not reveal the key — and that is
not a slogan, it is the shape of the pair. One half can only
lock and the other half can only open, so publishing the locking
half costs you nothing. That is why "public key encryption" is
not a contradiction. RSA-2048: the public number is 617 digits
long and was built by multiplying two primes of about 309 digits
each. Multiplying them takes a microsecond; pulling them back
apart would take the world's computers longer than your
lifetime. The exam wants the IDEA, not the factoring.
Symmetric (AES)
Asymmetric (RSA)
Keys
One shared secret
Public + private pair
Speed
Very fast
Slow
Perfect at
Bulk data — the bytes you actually send
Proving identity and handing over a key — the handshake
TLS — the handshake (https). The web uses
BOTH: asymmetric to establish trust, symmetric for the actual
conversation. When you see the lock icon:
1. Browser → github.com: "hello"
2. Server → browser: certificate + its PUBLIC key
3. Browser checks the certificate against trusted authorities
4. Browser generates a random SESSION key, encrypts it with the
server's public key, sends it
5. Server decrypts it with its private key — the ONLY one who can
6. Both switch to fast symmetric encryption with the shared key
Step 3 is what "certificate" means — a third party vouches
that this public key really belongs to github.com. Without it,
anyone on your wifi could impersonate the site and hand you
THEIR key (a man-in-the-middle attack).
Four sentences the exam writes its wrong answers from.
"Public key encryption" is not a contradiction. The
pair is not one secret written down twice. One half can only lock; only
the other half opens. So publishing the locking half gives nothing away —
and the public key cannot decrypt what it encrypted. That single
fact is a whole exam question.
A certificate asserts exactly one thing: that the
public key inside it belongs to the name inside it, according to the
authority that signed it. It does not assert that the site is honest,
careful, or run by the company you think it is. A green padlock says your
bytes are going to the machine named in the certificate. It says nothing
else, and it is not a safety rating.
TLS protects the channel, not the endpoints. The
routers in between cannot read your push — but the server at the far end
reads every byte of it, and so does anything downstream of that server.
Nor is the connection invisible: somebody watching still sees which
machine you contacted, when, and how much you sent.
A hash is not encryption. No key, no way back — a
fingerprint rather than a lockbox. That is why a stolen password database
is a different size of disaster from a stolen key, and why the fix is a
salt rather than a longer key.
Socratic
Why does TLS not simply use asymmetric encryption for
everything (hint: your 2 MB project push at RSA speed)?
The exam phrasing: "explain how symmetric and
asymmetric encryption are EACH used in secure
transactions" — write the one-sentence version now.
Build Lab~20 min
Step 1 — caesar by hand. Encrypt "BOSS"
with key 3 on paper (ERVV). Pass to a partner who decrypts.
Then: which letter appeared twice in the ciphertext — and why
does that PATTERN (frequency analysis) break Caesar without
knowing the key at all? Weak ciphers die to the STATISTICS of
language, not to brute force.
Step 2 — read a real certificate. You do not
have to go far for one: the page you are reading now is served
over HTTPS, from aramansell.github.io. Click the
padlock in the address bar and open the certificate. Then read
its fields and say what each one is for: the subject,
the issuer, the valid dates, and the public
key info. Two of them will surprise you. The subject is not the
address you typed — it reads *.github.io, a single
wildcard certificate covering every GitHub Pages site — and the
browser accepts it because the certificate's list of names
matches the host you asked for. And the lifetime is short: the
day this page was last checked the certificate ran from
2 August to 31 October and was issued by Let's Encrypt, which
are values you should expect to differ from yours. Read your
own; do not copy mine.
Then go and look at two that are deliberately broken.
self-signed.badssl.com
presents a certificate signed by nobody at all, and
expired.badssl.com
presents one whose dates have run out. Read the browser's
refusal on each and find the field it names: that field is
step 3 of the handshake above, failing in front of you. Do not
click through either one — a certificate warning is the browser
telling you step 3 did not pass.
Step 3 — your git connection.git remote -v in your project. Is it an https or an
ssh URL? Both are encrypted. SSH is the asymmetric idea with a
different protocol: your ssh keypair IS your public/private
pair (~/.ssh/id_ed25519.pub vs the private file).
If you set up GitHub Desktop, it did https + TLS. Either way,
your pushes have been unread to every router
(9.8) since day one.
Checkpoint — before moving on, you must be able to:
Explain symmetric vs asymmetric with a use case for each
Narrate the TLS handshake's six steps and where certificates fit
Read a real certificate and name what its fields prove
Explain why hashing is not encryption, and what a salt buys
Name the parts of keeping a message secret, in the order they are decided, and say where each one is written down
Say what a certificate proves and what it does not, and why the public key cannot undo its own lock
Explain why TLS protects the channel and not the endpoints
Reference Docs
Need a deeper explanation? These pages cover the same concepts: